The substance lost on the way to a decision

There is a particular morning that arrives at the end of large transformations. The budget is spent, the platform is in production, and the capability the whole programme was meant to unlock is either absent or shows up at a fraction of the scale that justified the investment. Someone asks how this happened. The honest answer is uncomfortable, because no one made an obviously bad call. Every step was reasonable. The failure was assembled out of sensible decisions, and the moment it entered was one nobody flagged as risky: the moment a hard technical question was made simple enough for the room to decide.

Strategic technology decisions carry an awkward property. The people accountable for them sit at a level where the detail that determines the outcome is not visible, and often cannot be made visible without years of context. This is not a fault of executives. It is the shape of the problem. A choice worth hundreds of millions can turn on a distinction an engineer needs a decade to feel, and that engineer is three layers below the signature.

Filtering is mercy, and it has a cost

What organizations do with that gap is filter. The technical reality is summarized for architects, the architects' view is summarized for a steering committee, the committee's view becomes a recommendation, and the recommendation is reduced to a score. Each step is an act of mercy toward the next audience, and each one trades fidelity for legibility. By the time the decision is made it rests on an artifact, usually a weighted comparison spreadsheet, built specifically so that people without the underlying knowledge could act on it.

The spreadsheet is not the villain. The problem is that the one distinction that actually mattered did not survive the journey into it.

In a companion piece I described that distinction in full: a state machine is not a process engine. Two platforms looked equivalent on every line of a feature comparison. One was a true process engine, the other a state machine, and they were not the same category of tool at all. Both ticked "supports subprocesses." For one that meant a coordinated hierarchy the engine manages. For the other it meant rebuilding that coordination by hand and carrying the coupling forever.

The expert who was right became the person who was difficult

There is almost always someone in the building who knows. An expert said, early and plainly, that the two tools were not comparable, and that the cheaper one would cap the very throughput the transformation existed to deliver. The reason a warning like that rarely lands is not that it was unclear. It is that institutions have learned to distrust the inconvenient expert.

The specialist who says "it is more complicated than the scorecard allows" sounds like someone defending their own complexity, slowing the process, or building a fiefdom. The analyst who produces a clean ranking sounds like progress. So the organization rewards the legible answer over the correct one, and the expert who turned out to be right is remembered as the person who was hard to work with. Distrust of expertise is not usually loud. It shows up as a quiet preference for the answer that fits on a slide.

A footnote becomes an avalanche

The mechanism that gets waved through looks trivial. A subprocess that does not truly wait for its children. A status check standing in for real instance tracking. On a slide it is a footnote. In production it becomes an avalanche. Every coordinated workflow has to be hand-built and hand-maintained. Every new process inherits the coupling. The team's capacity bleeds into compensating for the platform instead of building on it. The throughput curve the business case promised flattens out, and the strategic goal that justified the spend recedes from reach.

None of this is visible on the morning the decision is made. All of it is visible on the morning the budget is gone.

What the score could not hold

The lesson is not "involve engineers earlier," which everyone already says and few practice in a way that changes the outcome. The lesson is about the irreducible part of a problem, the part that cannot be simplified without being destroyed. You cannot make every decision legible to every decision-maker. Some decisions are only safe in the hands of people who hold the full complexity, and for those the right move is not a better spreadsheet. It is to choose the right people and then trust them, including when their answer is harder than the one the scorecard offers.

Be precise about who those people are. The trust belongs to proven domain experts, the ones with a track record in the specific field the decision lives in, not to whoever holds the most seniority or sits highest on the chart. Tenure and rank are not judgment in this domain, and the two are easy to confuse in a room that wants a confident voice. If the organization does not have that person, the answer is not to approximate them with a committee. It is to go and find them, and hire them.

This is uncomfortable, because it gives up the comfort of the number. A weighted ranking feels like rigor. It produces a figure, the figure is defensible, the decision looks objective. But objectivity at the wrong resolution is only confidence pointed in the wrong direction. The spreadsheet that reduced two fundamentally different systems to a points total did not take risk out of the decision. It hid the only risk that mattered, and it may still decide whether the transformation it was meant to serve is achievable at all, with the difference measured in hundreds of millions.

So when the difficult morning comes, the post-mortem will not find a villain. It will find a chain of reasonable simplifications, each one helpful, ending in a choice no single person fully made. The way to avoid that morning is not more diligence inside the filters. It is to notice, before deciding, which questions must never be filtered, and to place them in the hands of people you have chosen well enough to trust.