Decision latency

Decision latency is the time between the moment a decision is needed and the moment a usable decision becomes available to the work. In SMEs, it is often one of the hidden drivers of lead time, even when everyone believes the delay is operational.

In brief

A process may look slow because work waits. Often it waits for a decision: approval, priority, exception, clarification, trade-off, signature, resource allocation.

Decision latency measures that waiting. It does not ask whether the final decision was good or bad. It asks how long the organisation remained unable to act because the decision was unavailable.

Reducing decision latency is not the same as rushing decisions. It means giving recurring decisions a home: owner, threshold, information and review.

Operational definition

Decision latency has three moments.

The first is the signal: the moment the organisation knows a decision is needed.

The second is decision availability: the moment an authorised decision exists and can be used by the work.

The third is action: the moment the decision is translated into execution.

Decision latency is mainly the delay between the first and second moments.

It is different from decision quality. A slow decision can still be good; a fast decision can be wrong. But when latency is systematic, it becomes a structural cost.

Why it matters for SMEs

SMEs often hide decision latency inside operational delay. A quote is late because it waited for discount approval. A job is late because production waited for priority. A supplier issue remains open because nobody owns the exception.

The founder may not notice the cost because each decision feels small. The system feels it because many small waits accumulate.

As the company grows, decision latency tends to move upward. More issues require judgement, and the founder becomes the default decision point. The operating flow then slows not because people cannot work, but because they cannot act without authorisation.

For investors, decision latency matters because it reveals whether the management system can scale. If every meaningful decision waits for one person, growth increases waiting rather than only volume.

Observable signals

Look for work waiting for approval.

Look for phrases such as “we are waiting for the OK”, “I need to ask”, “let us see what the founder says”, or “nobody has decided yet”.

Look for decisions reopened after they were made.

Look for repeated escalation of the same decision category.

Look for meetings that discuss issues but do not create usable decisions.

Look for customer or supplier delays caused by internal authorisation, not technical work.

Common mistakes

The first mistake is measuring only task duration. If a task takes four hours of work but ten days of elapsed time, the missing measure is often decision latency.

The second mistake is blaming the person who waits. People often wait because the right to decide is unclear.

The third mistake is solving latency by telling people to be faster without changing decision rights.

The fourth mistake is moving every decision into meetings. A meeting can reduce latency only if it has authority and enough information to decide.

Operational example

A company believes its quotation process is slow because sales is overloaded. Mapping shows that actual sales work is fast. The delay is discount approval.

Every quote above a vague “sensitive” threshold moves to the founder. The founder approves most of them, but in scattered moments. Quotes wait two to four days.

The company defines a decision right: the sales manager can approve discounts up to 10% when margin remains above a stated threshold. Decisions are reviewed every two weeks.

Decision latency on those quotes drops from several days to same day. The founder still sees the pattern through review, but no longer sits inside every decision.

Diagnostic questions

For the main flows, where does work wait for a decision?

When did the need for the decision become visible?

When did an authorised decision become available?

Who owned the decision?

Was the threshold clear?

Was the required information available at the decision point?

Could the decision have been reviewed after the fact instead of authorised before the fact?

Practical implications

Start by measuring decision waits in one flow. Record the date and time when the need for decision appeared, the decision owner, the decision moment and the action moment.

Group repeated decision categories. For each recurring category, define owner, threshold, minimum information and review. This turns latency reduction into governance design, not pressure for speed.

Move appropriate decisions from preventive approval to retrospective review. This is often the single highest-leverage move in founder-led SMEs.

MARTRO reading

In MARTRO’s reading, decision latency is where process delay reveals governance architecture. A queue of work may actually be a queue of decisions.

This is why MARTRO reads latency together with decision rights, RACI and bottleneck analysis. When the bottleneck is the founder’s attention, the intervention is rarely more operational speed. It is decision architecture.

When to go deeper

Go deeper when lead time is long but work time is short, when recurring approvals dominate flow time, when meetings do not produce decisions, or when the founder is the default authorisation point.

Natural next steps are decision rights, governance, stop rule and bottleneck analysis.

Frequently asked questions

Is decision latency always bad? No. Some decisions require time. It becomes a problem when waiting is recurring, avoidable and caused by unclear ownership or thresholds.

How is it different from lead time? Lead time is total elapsed time in a flow. Decision latency is the portion caused by waiting for a usable decision.

Can meetings reduce decision latency? Only if the meeting has authority, information and clear decision rules. Otherwise it can add latency.

What is the fastest way to reduce it? Identify recurring decision categories and assign owner, threshold, information and review.

Why does it matter in SMEs? Because many SMEs scale work faster than decision architecture. The founder becomes the bottleneck for decisions that should have been local.