Decision Latency: The Real Cost Of Finding Out Late

The definition, and why it needs a name

Decision latency is the elapsed time between something becoming true about your business and a decision changing because of it. Not the time to notice, and not the time to report — the time until behaviour differs.

Naming it matters because the alternative framings all point at the wrong fix. Better reporting attacks one segment. Better dashboards attack a different one. More discipline attacks a third. Each of those can be improved substantially while the total stays almost unchanged, which is the experience most founders have had at least once.

This is not Brian's coinage and it is not from OPERATE. It is a way of decomposing a problem the framework already names — the founder who finds out about everything too late — into segments that can be measured separately. The idea it serves is his: stop reacting, start recognizing. The decomposition is just the instrument.

The useful property of the framing is that latency is additive. A business with excellent dashboards and no capture has infinite latency on anything unrecorded, and a business with perfect capture and a dashboard nobody opens has latency bounded by human curiosity. Optimizing one segment while another is unbounded produces no change in the total, which is precisely why the improvements feel like they did nothing.

The anatomy: four segments, four different owners

Segment one is event to record. Something happens — a client goes quiet, a date slips, a workflow stops — and either the business captures it or the event is unavailable forever. Transactions capture themselves because a system had to process them; behaviours do not. This segment is usually infinite in founder-led businesses, and infinite is not a number people think to measure.

Segment two is record to signal. The data exists somewhere and something has to turn it into a statement: a threshold crossed, a count, a comparison against a baseline. This is the only segment the software market competes on, which is why it is the only one most businesses have invested in.

Segment three is signal to human. The statement exists and has to reach a person. This is where dashboards fail, and they fail structurally rather than through poor design: a dashboard requires the act of going to look, and a busy founder's week does not reliably contain that act. Latency here is measured in however long it takes for someone to be curious.

Segment four is human to decision. The person has the information and either acts or does not. This segment is dominated by whether a defined action exists — a signal that arrives with no attached decision produces a feeling of unease and no change in behaviour, which is a latency of infinity dressed as awareness.

Why the wrong segment gets optimized

The market is the main reason. Segment two is where the products are, so it is where the attention goes and where the vocabulary comes from. When a founder decides to fix their visibility, the available purchases all operate on data that already exists.

The second reason is that segments one and three do not look like data problems. Capture is a change to how work is done, which reads as a process question. Delivery is a change to where information lands, which reads as a communication question. Neither shows up when you go looking for a reporting fix.

The third is that infinite latency is invisible. A slow number is annoying and gets complained about; a number that does not exist generates nothing at all. So the segments that get measured are the ones that already produce something, and the segment producing nothing stays unexamined indefinitely.

The fourth is the most human. Segment four requires deciding in advance what you will do when a signal fires, and that decision is uncomfortable, because it commits you. It is far more pleasant to have the information and preserve the option, which is why so many well-instrumented businesses still respond slowly.

How latency compounds into cost

The cost of latency is not proportional to its length, because most business problems have a threshold where the available response changes category. A drifting client in month four is a phone call. The same client in month seven is a lost account. Same problem, same business, and the price is set entirely by where in the curve you found out.

The same shape holds across the board. A project slipping by two days is a conversation; four weeks is a relationship event. An automation broken for a day is nothing; broken for a quarter is every client in that quarter. Latency does not degrade outcomes smoothly, it moves them across a boundary.

There is a second-order effect that is easy to miss. High latency forces a business into a reactive posture permanently, and a reactive posture consumes the capacity that would have been used to reduce the latency. Every hour spent on the emergency you found out about late is an hour not spent building the capture that would have caught the next one.

And it distorts what you believe about your business. A founder operating at high latency experiences a world of sudden events — clients who leave without warning, problems that appear from nowhere. That is not what happened. Every one of those announced itself, and the announcement arrived at a business with no instrument pointed at it.

The exit: measure each segment separately

Pick the last three things you found out about too late and reconstruct the timeline for each. When did it become true, when was it first recorded anywhere, when did a signal exist, when did a human see it, when did anything change. You will usually find one segment dominating all the others, and it is rarely the one you assumed.

Fix the dominant segment and ignore the rest, because latency is additive and improving a small segment changes nothing. If capture is missing, no reporting investment helps. If the dashboard is unopened, better data does not reach anyone.

For most founder-led businesses the answer is segments one and three, and both fixes are structural rather than analytical. Capture has to be a byproduct of work rather than an act on top of it — build the systems as you do the work, not instead of the work, or the capture will not survive a busy month. And delivery has to push rather than wait: if the founder has to remember to check it, it is not telemetry, it is homework.

Then close segment four by deciding actions in advance. Each signal gets a defined response and an owner before it ever fires. That is what converts an alert from information into a decision, and it is the cheapest segment to fix because it costs a conversation rather than a build.

Exercise restraint while you do it. A channel that fires forty times a day is muted within a week, and a muted channel has infinite latency with the appearance of instrumentation — which is worse than the position you started from, because now you believe you are covered.