What the fog is made of
"Fog of war" is a phrase we hear a lot for this situation, and "fog" is both apt and inadequate, because it suggests a single condition that either lifts or doesn't.
What obstructs these decisions is a set of separable issues with different sources and different remedies. Here is what we find in C suites on a regular basis.
Yields to structure.
- 01
Pressure to act arrives from outside and inside at once, and both versions come pre-loaded with position. Competitive pressure to "adopt before we get left behind" outstrips any actionable assessment of what should be adopted and how. Meanwhile internal opinion splits along predictable lines, some factions pushing to modernize and others for the status quo.
- 02
Part of the decision was made before it arrived. A platform is already bought. A vendor relationship has an owner. A commitment exists in public, and a prior initiative has to be seen as having worked. None of that shows up in an options analysis, and all of it narrows the real option set before the first slide goes up.
Yields to targeted investigation guided by the proper questions and assumptions.
- 03
The documented operation and the real one are two different things. The process that runs the business lives in workarounds, exception handling, and a few people's heads, and none of it is written down anywhere you can go read it.
- 04
Nobody has the whole map of the terrain, which consists of internal operational reality and current technological trends and market conditions. Smart internal people hold fragments of it. Vendors may hold other scraps. You need to assemble the most important fragments, the ones in the critical path. And it's not always easy to know which those are.
- 05
Almost everything you know about your own operation arrived through people with a stake in how it gets described. Not through dishonesty, mostly, but through ordinary self-presentation, compounded at every level it passes through on the way up. The practical consequence is that confidence in the description tends to increase with distance from the work.
- 06
Technological capability is hard to assess in advance, because a demo tests in isolation while complexity changes things. Production tests the organization around it: the exceptions, the handoffs, the people who have to trust the output enough to change what they do. What fails is rarely the capability.
- 07
Most of the confident information arriving from outside the building comes from someone with something to sell. Biased vendor advice pushes executives toward suboptimal platforms, tech sprawl, and fragmentation. Peer signal is no help either: what comparable companies announce publicly bears almost no relationship to what is running in production at those companies.
Yields only to shortening the loop.
- 08
The subject of the evaluation changes faster than the evaluation does. What the technology can do, what it costs, which vendors will still be here, and what competitors have put into production all move on a shorter cycle than a careful assessment takes. A thorough twelve-month evaluation returns a verdict on a world that has already been replaced, and the more thorough it is, the more true that is.
- 09
Whatever gets decided, there's no control group to assess the decision against. And there was usually never a baseline either, because nobody measured what the current process costs or how often it fails, so there's nothing to compare against afterward. The call gets graded on whatever the operation looks like a year and a half later, by people reconstructing causation from memory.
Yields to choosing moves you can walk back.
- 10
The cost of a wrong call isn't only money. It's spent change tolerance and spent credibility, and neither one can be bought back. Political capital goes with the misstep, the company becomes more change-averse, and the pressures keep building.
A single decision is hard enough. A sequence is infinitely more complex.
- 11
There's an optimal order of operations, many suboptimal sequences, and some disastrous ones as well. It's difficult to tell which is which, and extremely improbable that you land on the optimal order immediately.
Tiers of answer
Executives need to make expensive resource allocation decisions under extreme uncertainty. Unknowns sort into three tiers of accessibility.
Cheap answers
- One conversation with the person who does the work
- One sample export covering a real month
- One question about who signs when the output is wrong
These get skipped constantly, not because anyone decides to skip them, but because they are too small to appear on a plan, or they get lost in the other two categories.
If cheap answers are in the critical path, get answers to them ASAP and your world of uncertainty shrinks immediately.
Expensive answers
- Reconciling two systems that disagree about what a part is
- Establishing the current human error rate on a process nobody has ever measured
Expensive answers are sometimes worth answering. Pursuing one is itself a funded decision with its own order-of-operations question attached.
It should be argued on those terms rather than filed under discovery and waved through.
Near-impossible answers
- What the technology will be able to do in eighteen months
- Whether a key person will remain with the company
- What moves your competitors will make next quarter
Don't invest in trying to answer unanswerables. Identify them early on and set them aside.
You can develop mitigation strategies, but analysis can turn against itself and drag the overall project down.
Errors with answer tiers
Organizations tend to spend most of their study budget on the third category, where it cannot succeed, treat the second as though it were free, and never systematically mine the first.
Identify your critical "Category 1s" and answer them.
Triage your Category 2s and decide on a case by case basis.
Draw a circle around your Category 3s and don't overinvest in them.
For each thing you do not know, ask whether knowing it would change what you do next.
If the answer is no, it is context, not a blocker. A large share of what stalls these decisions turns out to be context.
Cost to resolve is only half the sort. The other half is how much leverage an answer provides.
An expensive answer that unblocks four initiatives is more valuable than a cheap one that changes nothing. Prioritize exploration of unknowns that multiple other questions depend on.
The "on paper" version vs reality
The documented process and the running process are different objects.
Every workaround is a repair made by someone competent at the exact point where the official process fails, and it encodes three things worth more than most process documentation:
This is why walking the exception path teaches more in a week than reading the process library teaches in a month.
The exceptions are where the real constraints are recorded. Anything built against the documented version of a process meets the real version in production and loses.
That nobody holds the whole map is not a staffing failure anyone can hire their way out of, and the remedy is not convening more people. It is knowing, for the specific decision in front of you, which part of the map is missing and what that particular ignorance costs. That question is answerable.
Three questions worth asking
Under these conditions most of the standard decision apparatus stops working. You cannot put meaningful probabilities on outcomes when the inputs are this soft, and doing it anyway produces theater.
What kind of wrong does this produce and what type of currency does it spend?
Not how likely you are to be wrong. What type of cost. Money spent badly is often recoverable. Change tolerance and political capital are often more expensive, which means a small initiative that fails visibly can cost more than a large one that fails quietly. Sort candidate moves by the currency they can lose, and the ranking changes.
Change its error shape, by making it advisory instead of authoritative.
How fast will you know?
Feedback latency is the most underrated variable in the whole problem. A decision that reports back in six weeks is worth more than a better decision that reports back in three quarters, because by the third quarter the sponsor has moved, the team has turned over, and nobody can reconstruct what caused what. An organization with long feedback loops is crippled, regardless of how capable the people in it are.
Shorten its feedback loop, by instrumenting the process before changing it, or by choosing the one site or product line where the answer arrives in weeks.
What does it cost to find out, and what does it cost to get back out?
The price of the test is a separate quantity from the price of the decision, and almost nobody prices it separately. Neither is the same as the cost of reversal.
Lower its exit cost, by renting instead of buying, or running in parallel instead of cutting over.
Error shape, feedback speed, and exit cost are design variables, not facts about the situation.
The same objective can be pursued in ways that have entirely different error shapes, feedback speeds, and exit costs. We almost never see them treated that way on purpose, so the choice gets made by default.
Reversibility is a social property, not a technical one.
The rollback is usually the easy part. What does not roll back is the trust spent asking a floor supervisor to work a new way, and the appetite consumed by a visible attempt that went sideways. A change that is trivial to undo in the system can be permanent in the organization.
Judge the decision, not the outcome
Whatever standard an organization uses has to be one it can apply at the time of the decision rather than after the fact.
Under uncertainty this deep, good decisions produce bad outcomes at a steady rate.
An organization that grades on outcomes teaches everyone who works in it that the safest available move is not to decide, which is the mechanism behind the change-averse spiral described above.
Nobody chooses that. It gets installed one post-mortem at a time.
The counter is to define, in advance, what a well-made decision looks like independent of how it turns out:
If the outcome is poor and the record shows the decision was well made, you have a defensible position instead of a search for someone to blame. This is also the only real protection for the credibility and political capital budget.
Buy the answer that matters
Each move has a cost, and each buys information.
Ask what information a move buys, and whether it is on the critical path.
If it succeeds, does the plan change?
If it fails, does the plan change?
Often, organizations are buying information they already have, or that is non-critical.
A technology pilot is a common move that answers whether a capability functions, which is worth knowing when capability is the critical question (and it usually is not).
See Addendum D for other common failure modes.
Uncertainty in dynamic systems, and sequencing decisions
A sequence is a route through a constraint graph, chosen under uncertainty and paid for out of accounts that deplete.
Everything prior in this article models the complexity of making a single decision under uncertainty. But in reality, decisions need to be made in clusters. A portfolio of decisions is much thornier than a single decision. The portfolio question is about sequencing, and sequencing requires more advanced logic from go / no-go.
A yes/no scores candidates one at a time. That is a legitimate thing to explore, but it cannot answer what to do in what order, because it has no representation of prerequisites, dependencies, adjacencies, or how much scarce capacity two apparently unrelated initiatives share.
The initiative everyone agrees is the most valuable is, more often than not, the one furthest down a chain of dependencies nobody has built.
It gets funded, it stalls the moment execution exposes the blockers, and the review that follows re-ranks it lower without saying so, as though the idea had gotten worse rather than the order having been wrong.
Order of operations also determines what accumulates. Each capability leaves behind things the next one either inherits or duplicates. A move that leaves a reusable foundation beats one that leaves an orphan, and a yes/no rubric cannot see this.
Point solutions almost always reduce legibility, which is the mechanism behind sprawl, and the reason the fifth purchase is harder to place than the first. This is the primary argument behind Talbot West steering clients toward compounding capabilities and away from fragmentation, though there are other benefits to the integrated approach as well.
What is actually in the way?
Ordering by what is in the way requires knowing what being in the way looks like, and the answer is less technical than the conversation usually assumes. The binding constraint is almost never whether a given technology can do a given task.
A fact about data
Two systems disagree about what counts as the same customer or the same part, and someone has been reconciling the difference by hand for years.
A fact about authority
A vendor owns the system of record and sets its own terms for who gets access this year, and no amount of internal agreement changes that.
A fact nobody has said out loud
Nobody has agreed who signs when the output is wrong. Nobody knows what the current error rate is on the process being replaced, which means there will be no way to prove the replacement is better even after it is running.
Each of these costs something different to clear, and each has its own way of being found out. Most of those discovery tests are small; discovering which constraint binds a given initiative is most of the diagnosis, and it is the part that almost never gets done before the funding decision. Which constraint binds is also the highest-leverage thing you do not know, because it is the answer that reorders everything else. That is why finding it out is worth funding ahead of the initiative it gates. The full set, with the test for each, is in Addendum C.
