Decision Latency as a Competitive Variable
Decision latency is measurable, structural, and often invisible. Treating it as a first-class variable changes how an organization designs information flow and authority.
Why this matters
Most organizations can describe their systems and their org chart, but not how long it takes them to go from something changing to something being done about it. That interval is rarely instrumented, so it is rarely improved.
Latency is structural before it is technical. Approval chains, information ownership, and the number of people who must be convinced set a floor that no faster tool can cross.
Because it is invisible, latency is usually paid for elsewhere: in duplicated work, in decisions made on stale understanding, and in the recurring judgment that a situation moved faster than the response.
The OODA perspective
OODA treats latency as a design variable with a named owner rather than a symptom of busy people. If no one owns the interval, the interval does not improve.
Authority is part of the measurement. Where a decision must travel to be approved is often the largest single contributor to cycle time, and it is an architectural fact, not a cultural one.
The aim is decision advantage by design: reducing the interval where it is safe to reduce, and making the interval explicit where it exists for legitimate accountability reasons.
Design & engineering implications
- Implication 01
Define the clock before optimizing
Latency cannot be discussed without an agreed start and stop event. Naming those two points is usually the first hard piece of work, and it frequently reveals disagreement about what the decision even is.
- Implication 02
Separate structural latency from technical latency
Time spent waiting for approval and time spent waiting for a query are different problems with different owners. Reporting them together hides whichever one dominates.
- Implication 03
Map authority alongside data flow
An architecture diagram that shows systems but not approval boundaries will consistently underestimate cycle time. Both belong in the same view.
- Implication 04
Watch the tail, not the average
Consequential situations tend to land in the slow tail of the distribution. A design tuned to the median can still fail every case that mattered.
Questions under active investigation
- How should the start of a decision cycle be defined when the triggering signal is only recognized in hindsight?
- Which approval boundaries genuinely protect accountability, and which are latency without a corresponding safeguard?
- How should latency be reported so it drives design change rather than becoming a performance metric people manage around?
Where this goes next
Latency is where the framework becomes measurable, which is why it is treated as an engineering target rather than an observation. The OAIA stages define where the intervals sit, and a program conversation is where the clock is defined for a specific environment.