Decision Latency: The Operating Metric Most Founders Never Measure

Measure how long a decision waits, and you'll find the cost nobody put on the P&L.

Founders generally know decisions are slow. What they lack is a number that makes it manageable. Without one, "we need to decide faster" is a wish.

Definition and formula

Decision latency is the elapsed time between the moment a decision becomes necessary and the moment an executable decision exists.

As a formula:

Decision latency = date decided − date the need was identified

Two things matter in that definition. First, the start is when the need was identified, not when it reached an agenda — there are usually days between those. Second, the end is an executable decision, meaning one with an owner and a next step. "We decided to look into it" is not a decision.

Instrumenting it without new software

Most teams assume this needs tooling. It does not. One column wherever you already record decisions is enough.

If you record decisions nowhere, start here: for four weeks, log every decision involving more than one person in a spreadsheet, with two dates — when the topic first came up, and when it was settled.

Four weeks is enough to see the pattern. It does not need to be complete. It needs to be consistent.

Healthy ranges by decision class

A single number for everything is meaningless. A hiring decision should not move at the speed of a decision about email copy.

The last column matters more than the third. The exact number depends on your business; what is universal is that an operational decision suspended for a month is no longer a decision — it is a default that nobody chose.

Three causes, and which is most common

Missing owner. Nobody knows whose call it is. The most common cause and the easiest to fix.

Missing data. The required information genuinely does not exist. Less common than claimed — usually the data exists and nobody has assembled it.

Missing authority. The owner is clear but lacks permission and waits for approval. This cause becomes dominant in organisations of 15 to 50 people.

Telling them apart takes one question. Ask whoever is waiting: "what exactly are you waiting for in order to decide?" The answer almost always names one of the three.

Cutting it: the pre-authorised decision list

The most effective tool I have seen is not sophisticated. It is a list of decisions people may make without asking, with a stated ceiling.

• Spend below a named amount, within their own area of responsibility.
• Any reversible change that can be undone within 48 hours.
• Any customer response that fits inside existing policy.

More important than the list is the sentence after it: "If it is not on the list and it is reversible, decide and tell us." That one sentence usually produces the largest latency reduction in the shortest time.

What decision latency hides

The visible cost of delay is a result arriving later. The hidden cost is larger and takes three forms.

Options expire. The candidate accepts elsewhere. The partnership window closes. A decision that took six weeks is often no longer the same decision, because one of the options has left the table.

The team starts guessing. When a decision hangs, work does not stop; people substitute their own assumption and proceed. When the decision finally arrives, some of that work gets discarded.

Decision-seeking behaviour changes. This is the worst one. Once a team learns decisions take six weeks, it stops bringing the small ones and decides alone — which is good — or stops deciding at all and lets the topic drop, which is not.

When high latency is correct

Two cases where high latency is a sign of health rather than illness.

First, genuinely irreversible decisions with a large blast radius. A platform migration or a pricing model change should be slow. If those move fast, the problem runs in the opposite direction.

Second, when the delay comes from actively gathering data rather than passively waiting. One question separates them: is anyone working on this decision today? If yes, that is investment. If no, that is suspension.

Which is why it is worth logging a second column beside latency: how many of those days someone was actively working the decision. The ratio between the two gives the honest picture.

A worked example: forty-two days for a one-hour change

A services company noticed its signup form had an extra field lowering completion. Marketing raised it in a weekly meeting.

The change shipped forty-two days later. The technical work took under an hour.

Reconstructing the path: nine days to reach the engineering team, eighteen days sitting in a prioritisation queue because nobody knew how important it was, and fifteen days waiting on legal approval to remove a field with no legal requirement behind it.

None of those three steps was unreasonable. Nobody was slow. The path took forty-two days.

After defining a pre-authorised list — which included "any reversible change to site forms" — the next equivalent change shipped in two days.

Limits of this metric

Low latency is not automatically good. A team making structural decisions in two days is probably not thinking enough.

And like any metric, it gets gamed once it becomes a target: people record later start dates, or mark half-decisions as settled. Which is why it has to be read alongside quality, not instead of it.

Is this the same as execution speed?

No. Execution starts after the decision. There are teams with fast execution and high decision latency — and they always feel like they are running without moving.

Who should own this metric?

Whoever the most decisions route through, usually the founder. Handing it to someone else produces reporting rather than repair.

My first number was bad. Is that normal?

Yes. Nearly every first measurement is worse than expected, because until now only the fast decisions were visible. Suspended ones are recorded in nobody's memory.

Closing

Every suspended decision carries a daily cost that appears in no report. The only way to see it is to count the days.

If you want to find where decision latency comes from in your organisation, founder performance architecture builds exactly this layer.