Despite the purportedly never-ending, never-slowing, never-reversing march of progress, most businesses still associate digital with pain. After 25 years of conditioning, it’s hard to argue that they shouldn’t—tech may have changed, but organizational trauma sure hasn’t. In this article, we unpack the most common organization-wide digital ailments and their generalized treatments.

You’ve done so much to make tech projects work better. Let’s go down the list:

Alignment. You changed development methods, introduced new management operating systems, and accepted Emerging Technology as your savior.

Perspective. You hired new vendors, purged and replaced leaders, and created reqs for positions you didn’t know existed.

Resources. You’ve added and added beyond the point of diminishing returns for throngs of contractors, fancy hardware, and spreadsheet-replacing (replicating?) SaaS tools.

Efficiency. Ironically, you’ve paid through the nose for cost-effectiveness, having rebuilt multiple keystone applications, opened the taps on IaaS, and executed circular technology migrations. On top of that, you’ve outsourced, insourced, re-sourced, and de-sourced to mixed results.

Strategy. You self-disrupted, innovated toward market adjacencies, productized your services, and servitized your product line. That business model canvas made it look easy!

It was supposed to be digital diet and exercise, but you’ve ultimately fueled the insatiable fire. Digital programs still cost too much, require Herculean rework even before launch, trigger blocking dependencies, and take…sooo…long.

Breathe deep—the doctor's here. We’ll examine the primary org-wide functional and cultural digital problems we witness regularly, highlighting their typical causes, symptoms, prognoses, and treatments.

Functional issues prevent teams from executing at their best. They’ll destroy progress regardless of a company’s culture.

Ambiguous digital strategy

Without a vision and a roadmap, teams don’t have a target. Most programs’ functional horizons become prohibitively short-distance as teams wade deeper into execution.

Cause: doubted, dubious, or misunderstood vision for the software product or product line under development

Symptoms: chronic uncertainty, survival behavior, wasteful activity, moving goalposts, dodging accountability

Prognosis: continued symptoms

Treatment

Three Cs: commitment, communication, and concreteness. You may have noticed that new builds or projects tend to execute better, that’s because new builds contain and require weeks or months worth of defined, known, and often practiced milestones. Upgrades, migrations, and other programs built on pre-existing work face more context and don’t have that luxury.

The downside with new programs is that once complete, this progress won’t last, especially if their product owner only chases feature requests and bugs du jour.

Build vs. buy? Both at once!

It's always the same story, "We tried to build X, and it didn't work, so now we're buying it, but it costs build-level money to implement!" This is how the infinitude of SaaS offerings get their hooks into well-intentioned businesses.

Cause: solutioning hyperfocus, “not invented here” overthinking, easy button underthinking

Symptoms: always-open debate, relitigation, overbuilding before testing, failed tests, problems too close to the deadline

Prognosis: slow progress, massive overexpenditure, mediocre result

Treatment

Continuous externalization. Decisions like build vs. buy quickly get shoved aside by ego, tradition, perspective bias, and politics. Knowing why you're implementing something and who you’re implementing it for relieves every leader, designer, and engineer of the burden of making their best solution and focuses them on the right solution for someone else: your customers. Keep your users/customers in the crosshair at the operational level, and you’ll reduce the personal pressure to perform and increase the professional pressure to be correct.

Prototype=production

This happens when organizations had a successful proof of concept built on a proof of concept budget and think they're done and ready for launch. Very common in IoT/connected product development.

Cause: thinking of digital projects as 100% different, overfaith in prototyped code/hardware readiness

Symptoms: go-to-market disaster, projections wildly off

Prognosis: financial loss, program shut down, heads rolling

Treatment

Build on similarities. Ironically, most OEMs have entire product development processes that would prevent this. Digital may be different, but program managers need to identify what isn’t different and apply their tried and true.

Non-standard practices/sole-sourced methods

Those who write requirements/request digital outcomes and those who fulfill them adapt to each other over time. When enough time passes, they stop behaving in an industry-standard way. This can be an advantage if in-house methods meet and exceed accepted standards, but that’s rarely the case.

Cause: lack of rigor around fundamentals, failure to make implicit knowledge explicit

Symptoms: “not invented here” behavior, slow resource onboarding, limited success with externalized projects

Prognosis: outsiders blamed, practitioners keep coming back to themselves as the solution

Treatment

Multiple possible, from a large systemic change, to minimally-invasive external guidance toward better practices, to the introduction of a project that requires technical skill outside the current team’s domain that would force contributors to rise to the challenge…or not.

Black box development

An insular team owns their piece of the process but is uninterested in changing, integrating, or communicating—only growing.

Cause: unsuccessful team integration, engineering leadership insecurity

Symptoms: perpetually-uncertain delivery, undocumented everything, cliquish engineering team

Prognosis: extreme anxiety for upstream and downstream dependents

Treatment

Normally when we see this, it’s a few people in charge of an ancient program or a handful of IT shut-ins—people with a small purview. That’s not always true, and sometimes the team’s very large, loves being indispensable, and recoils from accountability.

Treatment depends entirely on context, specifically the extent to which the black box team is salvageable. Sometimes a quick personnel or practice switch can work, other times you need a full, PIP-like escalating transition plan.

Superproblem: business feels hostage to the black box

Sometimes, comorbid ailments join forces to create a truly devastating malignancy.

Cause: your organization became dependent on a black box leader/team

Symptoms: hot/cold urge to destroy the box/need the box to survive, defensive estimates from the box, capricious changes and outputs from the box, cooperating parts of the system feel disempowered, no new valuable digital IP developed

Prognosis: cost:value ratio plunges below critical, immense frustration and doubt about digital generally and not just the black box team

Treatment

Solve either the black box problem or the sole sourcing problem. The sole sourcing solution (“gently opening the box” as we’ve called it) is less invasive and provides the black box leader with a good character test: open up, or play politics.

Goldfishing

Not to be confused with catfishing, goldfishing is when projects/milestones grow to fit their container. Extremely common in all projects and certainly no stranger to digital.

Cause: capacity- or timeline-based estimation meets a purported blank check

Symptoms: blown budgets and untrustworthy estimates

Prognosis: ever-expanding costs, continued threatmaking/bickering

Treatment

Generalized projectization plus professional estimation. See below for more.

Fox guards the henhouse

This happens when a conflict of interest becomes baked into a business’s engineering processes. The most common example is quality functioning as a subordinate component of the software engineering team instead of being a separate, evaluative entity.

Cause: a choice that was made for convenience in the past and never updated

Symptoms: varies, in the development/QA example above you’ll see delivery trumping quality, short times between build and release, and suffer frequent surprises

Prognosis: lingering bugs, unclear fixes

Treatment

Define and build buy-in for the full professionalization of the subordinate part of the process. In the QA example, a defined release process and specific release responsibilities will help separate it from development.

Roads to nowhere

Few corporate digital offerings ever amount to much. During development, most feel like a distraction from the “real work”.

Cause: FOMO + action bias, underfocus

Symptoms: lots of expenditure over time for minimal results

Prognosis: continued lack of progress, reluctance to try even slam-dunk ideas

Treatment

Build correctly. Most organizations lose faith in digital because of this: they build useless, unjustified products and services, then blame digital tech or people for that decision. Some of our best case studies involve this particular problem, and weirdly, the right organizational treatment plan also happens to be the right way to build a digital product: start with market and customer research, validate your concept, test your prototype, create confidence. You need to nurture a success—don’t race from crawl to run.

Interminable megaprojects

That ERP implementation won't take 5 years and $7M. It's always at least double, and if it ends, it's out of date, and you end up with a system everybody else has.

Cause: underestimated and underplanned large implementation

Symptoms: it’s never done

Prognosis: it isn’t getting done

Treatment

Bites. There’s not a single piece of software where 100% of its functions each take 3 months or more to build. There’s opportunity inside of every program for proof points: integrations, user tests, X to Y migrations, etc. Don’t wait until everything’s supposed to be done!

Cultural issues are self-harming behaviors exhibited by an organization’s digital team.

Heroism

Engineering focuses mostly on problem solving, but problem-solving isn’t strategic unless it’s targeted. This is a very common and well-understood digital disease.

Cause: crises enable engineers to both solve a problem and feel desired/necessary—a solved crisis is a dopamine hit that makes solvers feel accomplished

Symptoms: reactive behavior, celebrating talent for stopping problems instead of creating value, additional resources are somehow always the answer

Prognosis: vacillating overconfidence/aversion, feeling of dependence on individuals instead of the team, paranoia that the only way to succeed is to become heroic instead of professional

Treatment

Team pivot. The first step is to realize when managers promote this behavior and correct for it in favor of conscientious team- and system-level solutions. Begin the transition from cowboy coding to professional development with distinct and declared roles, adhered-to processes, and of course, documentation on items that others might use in the future.

Presentism

The dark side of a fail-fast culture. In digital, when people focus solely on today, they avoid laying groundwork for others (or themselves) that scales future efforts cheaply.

Cause: muddling through each problem as it comes, professional services mentality

Symptoms: only one team can build things, every new effort is as big as the last

Prognosis: chronic pain, the sufferer will feel the urge to amputate as any change cost increases as time passes

Treatment

Intentionality. Build your list of product audiences and ask "if we build this, what would it mean?" for each. If, for example, some of your new product’s components were built as a documented toolkit others could use, that “toolkit-ization” would not take significantly more work on a 6+ month project, but would pay dividends on the next project.

Emergency hyperfocus

Think of this as metastatic presentism. When things go wrong, workers respond with intense focus on today’s task(s) to the exclusion of all else. Requirements, processes, upstream and downstream stakeholders, schedules, tomorrow’s work on this same project—all context becomes noise, and it all creates fatigue. Obviously, ignoring critical context on a daily basis builds a cycle of recurring crises, normalizing this behavior.

Cause: behavioral conditioning—somehow, doing things properly or conscientiously gets penalized or goes unrewarded (has multiple possible sources)

Symptoms: artifacts not taken seriously, poor or absent documentation, exponential regression over codebase lifespan

Prognosis: digital becomes (or remains) a quagmire

Treatment

Behavioral targeting. Introduce a handful of changes that require new behaviors without reinforcing problematic or causal behavior. Soothing actions like concessions, breaks, and pressure relief feel like rewards and tend to reinforce instead of solve. Change could mean leadership, process, structure, or mission, and your specific context will provide the right targets.

We often recommend that organizations bolster three areas: pre-engineering, management, and quality skills required to control a development project regardless of the source or technology. This breaks codependence with a delivery team, enforces a project mentality, and strengthens pre-development practices at the point where digital initiatives are at their cheapest (pre-engineering).

Product/project process mentality mismatch

Some digital leaders and practitioners approach digital with product development experience and bias, whereas others approach it with a project-oriented professional-services derived mentality. With a strict process, the two are compatible, but without it, you get the worst of both worlds: budget-ignorant, top-down product-based management practices combined with day-at-a-time, project-oriented development myopia.

Cause: mixed perspectives with no method to align around

Symptoms: unestimated efforts, minimal concern for budget at the project level

Prognosis: both over- and under-resourcing, missed budgets

Treatment

Define and implement your way. See Projectization and You-ify development below.

Projectization

In software, the difference between project-oriented digital development and product-oriented digital development is that projects end. Although most OEMS engage in software product development, the right pieces of the project mentality, namely its ceremonies, declared resource allotment, and work-order level management to a budget will reduce both overhead and waste.

Professional estimation

Business leaders need a trusted party who can set realistic cost and time expectations on all types of digital for the business and set reasonable constraints for engineering. Simultaneously, a solid estimator sets realistic software prerequisites, process, timeline, and development expectations with business stakeholders to preclude unrealistic asks.

You-ify the software development process

Old digital, like backoffice digital (IT initiatives) and some front-of-house digital (marketing websites) can be done in isolation with separate processes. However, revenue-generating digital (connected) product development won’t succeed separate from what made its core business successful.

Although it'll never be an exact fit, bending hardware, firmware, and software development into your business’s engineering and quality processes while maintaining accepted design and development standards can and should be done.

Enforce processes and accountability that make you successful

We’ve witnessed development teams take input from a dozen stakeholder groups, then begin work without pushing back or clarifying, then fail to bring any stakeholder along. Similarly, we’ve seen stakeholders provide widely varying degrees of input, control, and effort to equally varying effect. None of this is acceptable or normal.

No business got to where it is by being a complete failure. Leverage your collective, interdepartmental success by establishing what each party needs from other parties, agree on that, and then agree to hold each other accountable to providing it constructively. Setting boundaries can be agonizing but it’s often the first step to health.

Empower a digital control mechanism

Your org doesn’t need to own all of digital to succeed with it. By empowering a separate group with the control mechanisms for digital projects (BA, UX lead, release, architecture, requirements, estimation) and the operationalization mechanisms (release, UAT, product integration, possibly devops), you’ll gain the ability to interface with any digital engineering team, selecting the best fit for the job each time.

---

Next Mile has helped countless find digital health through treatments like those above. If you’d like effective help with an org-level digital challenge, contact us. Know that on the path to any fix, you’ll face new hurdles, but new problems have a way of invigorating teams.