The Difference Between a Technology Problem and a Technology Decision Problem

Here is the question I ask at the start of almost every engagement:

“What decision, made differently, would have changed this outcome?”

Most people find the question uncomfortable. They expect me to ask about the technology — which system, which vendor, which architecture. The question about decisions feels like a sidestep.

It isn’t. It’s the only diagnostic that leads somewhere useful.

The Symptom vs. The Cause

Consider a typical technology failure: an ERP implementation that went eighteen months past its original deadline, cost three times the initial budget, and launched with significant capability gaps that forced the operations team to maintain parallel processes in spreadsheets for two years afterward.

The standard post-mortem produces the standard conclusions: the scope was underestimated, the vendor overpromised, the customizations multiplied beyond control, the testing window was compressed. All of this is accurate. None of it is the root cause.

The root cause is that no one in the organization had clear, documented authority over the decisions that accumulated into scope creep. Configuration choices that should have been rejected as out-of-scope got made because operations leaders were uncomfortable pushing back on the vendor in steering meetings. Architecture decisions that conflicted with the organization’s operational reality got approved because the person with authority to reject them didn’t have enough operational context to recognize the conflict.

The system didn’t fail. The decision system that governed the implementation failed. And because the organization was focused on the symptoms, the decision system remained unchanged — ready to produce the same failure the next time.

How to Tell the Difference

A technology problem has a technical solution. The database is misconfigured. The integration is broken. The algorithm produces wrong results under edge conditions. These are real problems, and they have real fixes.

A technology decision problem has a structural solution. Something — usually multiple things — went wrong in how a decision was made. Who made it. What information they had. What authority they held. What accountability was attached to the outcome. The fix is structural: change the decision system so the failure doesn’t reproduce.

The diagnostic test is simple: if you fix the immediate technical problem without changing the decision structure, will the same failure recur?

In most cases, the honest answer is yes. The next ERP will fail for the same reasons as the last one. The next platform migration will surface the same misalignment between IT and operations. The next AI implementation will run aground on the same undefined requirements and organizational resistance.

The technology changes. The decision system doesn’t. The failures repeat.

The Three Decision Failures

In practice, most technology decision failures come in three forms.

Ownership diffusion. The decision nominally belongs to a group — a steering committee, a cross-functional team, a vendor/client pairing — but in practice no individual is accountable for it. When the decision produces a bad outcome, the accountability diffuses in the same way the decision did. Nothing changes.

Context mismatch. The decision is made by someone with the wrong information. Technical decisions get made by people who don’t understand the operational consequences. Operational decisions get made by people who don’t understand the technical constraints. The gap between the two is where the failure lives.

Governance discontinuity. Governance structures are built for a project and then abandoned when the project ends. The technology continues to evolve. The decisions continue to accumulate. Without the governance structure to make them deliberately, they get made by default — by inertia, by whoever has the loudest voice in the moment, by the vendor who has the most to gain.

What Changes When You Fix the Decision System

The practical difference between an organization with a functional technology decision system and one without is most visible in how they handle failure.

In organizations with functional governance, a failed deployment produces a clear sequence: the failure is captured, the decision that caused it is identified, the owner is named, and the decision process is modified so the same failure can’t recur. The organization learns.

In organizations with broken governance, the failure produces the same post-mortem every time — scope, vendor, timeline, budget — without ever reaching the decision that mattered. Nothing structural changes. The organization doesn’t learn.

The value of the decision system isn’t in preventing every failure. Some failures are unavoidable given incomplete information. The value is in the compound learning that accumulates over time when failures are attributed to their structural causes and the structure is modified accordingly.

That’s what it means to make high-quality technology decisions consistently as an organization scales. Not to be right every time — but to build the structural capacity to learn, adapt, and improve the decision process itself.

That’s the work I do. And it starts with the question: “What decision, made differently, would have changed this outcome?”