The Advantage Is In Choosing What to Change First: A Leadership Advice

Summary: Most business transformations fail before the first system goes live. The failure point is almost always the same: the wrong problem was selected, the wrong sequence was chosen, or the business was less understood than leadership assumed. This article lays out what genuine transformation sequencing requires and why getting that order right matters more than the technology you choose.

Most business transformations do not fail at go-live. They fail in the weeks before the brief gets written. This is mostly because the problem is selected too quickly, the sequence is assumed rather than designed, and the business is believed to be understood when it is only partially known.

Twenty ix years of leading enterprise transformation has shown me that the quality of the outcome is almost always set before the build begins, and that the gap between what a business intends to change and what measurably changes because of the work it funds is where most transformation investment quietly disappears.

The Failure in Transformation Projects That Almost Nobody Talks About Honestly

Bain's analysis of enterprise transformation programs found that 88% of business transformations fail to achieve their original ambitions. That figure has not meaningfully improved despite a decade of increasing investment, more sophisticated tooling, and near-universal adoption of agile methodologies. The reason it has not improved is that the fundamental error is not in the execution. It is in what happened before execution began.

The pattern I see most consistently is this. A business identifies pain points like declining customer retention, process overhead that is consuming too much operational resource, a product losing competitive ground. Leadership connects these to a technology investment. The investment is funded, staffed, and built well; the system launches. But the numbers do not move in the way the brief anticipated. This pattern is frequently seen in organizations navigating complex digital change initiatives across the enterprise.

What almost always turns out to be true is that the system addressed the symptom rather than the cause. Retention wasn’t falling because the product experience was broken but because onboarding was creating expectations the product could not meet. The operational overhead was not in the process that was automated but, in the handoff, either side of it. The product was losing ground not to a more technically capable competitor but to one that responded to customer feedback faster.

So, if you are planning a transformation program and the problem statement in your brief describes a technology gap rather than a business outcome gap, the brief needs to be rewritten before the program begins. The technology decision is downstream of the business diagnosis. Reversing that order is where most programs go wrong.

Getting the Diagnosis Right Before the Build Begins

Research consistently shows that transformation failures are rarely caused by the technology itself. They occur because of unclear goals, weak leadership alignment, and a gap between the outcomes that were promised and what the operational reality of the business can support.

The questions that reveal the most in early transformation conversations are not the strategic ones. They are the operational ones:

• What does your team do when this process breaks down today?
• Who makes the call when there is a conflict between these two business units?
• What would have to be true about this workflow for your customers to notice a difference within ninety days?

Those answers tell you more about where to begin than any process map of the current state. And they frequently reveal that the problem described in the brief is not quite the problem the business needs solved.

Knowing what you need to change is not the same as knowing what needs to be different when the change is complete. The gap between those two statements is where most transformation briefs quietly go wrong, and where the most expensive rework originates.

Understanding Your Business Is Not a Precondition. It Is the Work.

Every leader I have worked with over twenty-six years believed, at the start of a transformation program, that they understood their business well. Most were right about the parts of it that regularly surfaced at leadership level. Most had genuine blind spots about the parts that did not.

This is a structural feature of how information moves through organizations. The data that reaches senior leadership is filtered, summarized, and often smoothed of the operational friction that would matter most to a transformation decision. The team running a particular workflow knows things about it that will not appear in a process map. The customer using a product feature understands its failure modes in ways that user research does not reliably capture.

Understanding a business in the way that makes transformation possible means going further than standard pre-project discovery. It means understanding the gap between how the business presents itself to leadership and how it is experienced by the people running it day to day. That gap is almost always where the most important transformation opportunity lives, and it is the last place most discovery processes look.

Building software with niche capabilities that genuinely changes how a business operates starts with that operational understanding, not with a technology selection. The technology decision is only as good as the diagnosis it is responding to.

What Tech-Forward Actually Demands Before a Line of Code Gets Written

Being tech-forward is not about early adoption, it’s about having the organizational discipline to apply technology decisions to correctly identified business problems, in the right order, with the right resources, and with a measurable definition of success in place before any work begins.

Most organizations that struggle with transformation are not struggling because of a lack of technical ambition. They are struggling because their technical ambition is not matched by the diagnostic capability required to direct it correctly.

Building the right team capability before the transformation program begins is consistently one of the highest-leverage sequencing decisions available. Not just technical depth. The combination of engineering knowledge and business domain understanding that allows a team to see both the implementation and the business consequence of a decision simultaneously. That combination is rarer than most leadership teams expect when they start hiring for a transformation program. This is why many lean on specialist long term engineering partnerships instead of assembling everything from scratch.

If the team responsible for your transformation program does not include people who can hold both the technology decision and the business outcome in the same conversation, the sequencing will drift. Add that capability before the build starts, not after the first sprint review reveals the gap.

Finding the X Point Between Business Reality and Technology Possibility

The concept I return to most consistently in transformation work is what I call the X point. It’s the specific intersection between what a business genuinely is and what technology can meaningfully change about it within the timeframe and resources that are realistically available.

The X point is not found through a framework; it’s found through conversation. It requires a business leader who can speak honestly about where the organization is constrained, not just where it aspires to improve. And it requires a technology partner capable of distinguishing between what is technically possible and what is operationally absorbable.

The most useful thing you can do in the early stages of any transformation program is ask questions that make the X point visible rather than offer frameworks that attempt to locate it systematically. Frameworks are useful once the X point is known, they are not the instrument for finding it.

When you find the X point correctly, the technology selection that follows it is relatively straightforward. When you do not find it, no amount of sophisticated tooling will compensate for the misalignment between what you built and what the business needed.

Why the Arc Cannot Be Treated as a Project

Transformation is no longer a phase that starts, runs, and closes. Organizations today are running cost optimization, growth initiatives, and operational improvement simultaneously and continuously. The arc does not end at go-live.

The enterprises building genuine transformation capability treat each completed cycle as the starting condition for the next. That reframe changes what gets invested in and what gets measured. The most valuable investments in a transformation program are not in the most visible components. They are in the components that create the most options for what comes next. Clean data over comprehensive analytics, modular architecture over maximum feature coverage at launch, team capability over tool sophistication.

These choices look conservative in the moment and compound significantly across the arc of a program. The organizations that make them deliberately are the ones that find subsequent cycles faster, cheaper, and more effective than the first.

What Transformation Looks Like When the Sequence Is Right and How to Build it Right

The clearest indicator that a transformation program has been sequenced correctly is rarely visible at launch. It becomes visible six to twelve months later, when the business has absorbed what was built and the next phase of work can begin without requiring a rebuild of what came before.

When sequencing goes wrong, the signals are specific. It shows up in reporting layers that cannot perform because the data infrastructure underneath it was not cleaned up first. Also, automated process generating poor outputs at higher volume or a new platform being worked around rather than used because the team capability required to use it was not built before the platform went live.

The organizations that build this sequencing discipline consistently are the ones whose technology investments compound in value rather than plateau after the initial deployment period. The challenge is the same one it has always been, now with higher stakes and faster consequences.

1. Can an organization understand itself clearly enough to change the right things?
2. Can it sequence those changes in an order that builds stability rather than cascading dependencies?
3. Can it build the organizational discipline to treat transformation as a continuous operating practice rather than a periodic disruption?

Three capabilities will define transformation success through 2030. The first is diagnostic precision: understanding the actual business problem rather than the most obvious one. The second is sequencing maturity: the organizational ability to identify the right order for change and hold it under pressure. The third is measurement continuity: connecting what gets built to what changes in the business across every cycle of the arc, not just at launch.

Your Takeaway

After twenty-six years of leading enterprise transformation programs, the clearest lesson I can offer is that the quality of the outcome is almost always set before the build begins.Transformation programs that invest in getting the diagnosis right, understanding the business at an operational level before selecting a technology direction, and building the sequencing discipline to create stable foundations for each subsequent cycle consistently outperform programs that begin with technology and work backward. Not marginally. Significantly, across every metric that the business cares about.If you are planning a transformation program and want a partner who will start with the right questions rather than a technology recommendation, reach out to our team and let us begin with the business problem.