Decision Latency

Everything is “in progress” (but nothing moves)

You can feel decision latency in the language teams start using:

• “We’re just waiting on risk.”
• “Finance want a bit more detail.”
• “Architecture have questions.”
• “We’ll take it back to the forum next week.”

The work is “owned”.
The work is “tracked”.
The work is “prioritised”.

But the work is not moving.

So teams do what humans always do when they’re trapped in a system that won’t move:

They work around it.

They build shadow artefacts.
They pre‑align in side conversations.
They split work into smaller pieces to dodge governance thresholds.
They over‑produce evidence decks to reduce the chance of rejection.

It looks like activity.

It’s actually friction.

And friction is rarely caused by a lack of effort.
It’s usually caused by a lack of clarity.

Decision latency is not just “slow approval”

Decision latency is the elapsed time between:

1. A decision being requested (a real choice that unlocks or constrains work), and
2. A decision being committed (with enough clarity that people can act without fear it will be reversed tomorrow).

That second part matters.

Because most organisations don’t just suffer from slow decisions.

They suffer from decisions that remain negotiable.

The meeting happens.
The decision is “made”.
And then two days later someone asks:

“Have we considered…?”

Or worse:

“Can we just get a bit more information?”

So we loop.

Decision latency becomes a compound problem:

• Time spent waiting for a decision
• Time spent relitigating a decision
• Time spent generating additional information because the inputs were never clear in the first place

This is the second‑guessing tax.

It’s not caused by “bad people” or “over‑cautious governance”.

It’s caused by a structural gap:

We don’t make decision inputs explicit.

The second‑guessing tax (and why it keeps happening)

Second‑guessing is a rational response to uncertainty.

If I can’t see what a decision was based on, I have two choices:

• Trust the person who made it, or
• Re‑open the question and ask for more evidence

In most organisations, trust is uneven and consequences are personal.

So people default to the safer option:

ask for more information.

Not always because it’s needed.
Often because it provides cover.

And here’s the brutal irony:

When decision inputs are unclear, the request for “more information” never ends.

Because no one has said what information would be enough.

So the decision doesn’t become more credible.

It becomes more exhausting.

Decisions are bets (and every bet has a stake)

In an earlier OSM piece, I used the idea of Service Stakes to reframe risk and investment.

At heart, every meaningful decision is a bet under uncertainty.

Not a gamble.
Not a guess.
A bet placed with intent, using what we know, acknowledging what we don’t.

The question is never:

“Is this decision perfect?”

The question is:

“Is this decision credible given the stake?”

Because the stake is what determines how much rigour is appropriate.

Not everything deserves the same ceremony.

A low‑stake decision should be fast, reversible, and cheap to learn from.
A high‑stake decision should be slower, clearer, and explicit about assumptions and consequences.

When organisations don’t name stakes, they default to treating everything as high stakes.

So every decision goes through the same machinery:

• Another forum
• Another deck
• Another set of questions
• Another week of delay

Flow collapses not because the work is hard - but because every decision is treated like a courtroom trial.

The missing artefact: evidence + assumptions

Most organisations record decisions like this:

“Approved.”

Or:

“Proceed, pending review.”

That’s not a decision record.

That’s a mood.

If you want decisions that don’t get second‑guessed, you need a simple rule:

Every decision must carry its inputs.

Not a thousand pages of justification.
Not a consultant’s appendix.
Just enough to make the decision legible.

Specifically:

• What evidence did we use?
• What assumptions did we make?
• What was the stake?
• What would cause us to revisit the decision?

When you make that explicit, something changes:

Second‑guessing becomes less political and more honest.

Instead of “I don’t like this decision”, the conversation becomes:

• “I think assumption B is wrong.”
• “New data has arrived that breaks evidence A.”
• “The stake just changed.”

That’s not re‑opening a decision for sport.

That’s governance doing its actual job.

A simple decision record (that fits on one page)

Here’s a template I’ve found useful:

Decision: What are we choosing?
Service: Which service outcome does this affect?

Stake: What is on the line for real people? (money, time, trust, safety, reputation)
Stake level: Low / Medium / High (and why)

Option chosen: What did we decide to do?
Alternatives: What did we not choose (and why not)?

Evidence used: The information we used to make this decision (links, metrics, incidents, constraints)
Assumptions: What we believe to be true (and how confident we are)

Guardrails: What must remain true while we proceed (constraints, controls, non‑negotiables)
Revisit triggers: What would cause us to re‑decide (thresholds, dates, events)

Decision owner: Who is accountable for keeping this decision coherent over time?
Date: When was it made?

Notice what this does.

It doesn’t pretend certainty.

It creates credible uncertainty:

We are explicit about what we know, what we’re assuming, and what would change the decision.

That is how you keep decisions valid without demanding perfection.

Where decisions stall (and what they’re missing)

Decision latency usually shows up at the interfaces between three worlds:

• Risk (threat, controls, consequences)
• Finance (cost, benefit, constraints)
• Architecture / security (structure, dependency, feasibility)

These groups are not villains.

They are often the only people in the room who are paid to ask:

“Are we sure?”

The problem is not the question.

The problem is that the service context is usually invisible - so every question creates a new information request.

Risk doesn’t need more paperwork. It needs stake clarity.

When risk asks for more information, it’s often because the stake is undefined.

If the potential consequence is unclear, the safe move is to escalate.

But if the stake is explicit - and proportional - risk can do its job faster:

• “This is a low‑stake decision with a reversal path.”
• “This is a high‑stake decision with customer trust on the line.”

Risk isn’t asking for certainty.

It’s asking for a frame it can stand behind.

Finance isn’t being difficult. It’s being asked to fund fog.

Finance questions often sound like obstruction:

• “Where is the business case?”
• “What’s the return?”
• “How will we know it worked?”

But look closely and you’ll see the same issue:

The spend isn’t connected to a service outcome with a traceable stake.

So finance can’t anchor the decision in reality.

The result is predictable:

More slides.
More modelling.
More debate.

Still no clarity.

Architecture gets dragged into decisions without sightlines

Architecture and security groups frequently become “the brakes” because they’re asked to approve changes without credible context:

• What service is this for?
• What dependencies does it touch?
• What is the blast radius?
• What is the reversal plan?

Without sightlines, architecture can’t make a credible bet.

So they ask for more information.

Again: rational behaviour in a foggy system.

How to measure decision latency (without turning it into theatre)

You don’t need a tool.

You need timestamps and honesty.

Start with four measures:

1. Time‑to‑decision: request date → committed decision date
2. Clarification loops: how many times did we go back for “more information”?
3. Re‑open rate: how often was a decision reversed or re‑litigated?
4. Touch count: how many forums / handoffs did the decision pass through?

Then split time‑to‑decision into two parts:

• Waiting for authority (calendar delay)
• Waiting for information (clarification delay)

That split will tell you where the real problem is.

If most delay is “authority”, you have a decision rights issue.
If most delay is “information”, you have a visibility issue.

And visibility issues are exactly what OSM is designed to address.

How OSM reduces decision latency: sightlines, not ceremonies

OSM is not an “approval framework”.

It’s a way of making services legible enough that decisions can be made credibly and remembered clearly.

When you have an OSM service model - a service graph with stable identifiers and shared relationships - you can create sightlines that reduce second‑guessing:

• What service outcome is affected?
• Which teams and systems are involved (and where are the seams)?
• What does “good” look like for people using the service?
• What are the known risks and controls already attached?
• What does it cost today, and where does cost sit on the service graph?

This is where the Service Intelligence Base (SIB) matters.

Not as a perfect repository.
As a credible one.

A place where evidence, assumptions, and service context can be connected and reused.

So the next time the decision comes up, you are not starting from zero.

You are not re‑writing the story.

You are extending a model that already has memory.

Minimal Viable Truth beats maximal paperwork

One of the fastest ways to kill flow is to demand completeness before you decide.

Completeness is a fantasy.

Credibility is achievable.

A decision can be credible if:

• the stake is clear
• the evidence is explicit
• the assumptions are named
• the revisit triggers are real

That is Minimal Viable Truth for a decision.

And it’s usually enough to move.

Start small: one service, ten decisions

If you want to find decision latency quickly, don’t start with the whole organisation.

Start with one service.

Pick something that matters and routinely feels “stuck”.

Then for the next ten meaningful decisions, do three things:

1. Record time‑to‑decision (request → committed)
2. Capture evidence + assumptions (one page)
3. Name the stake (and keep it proportional)

Within two weeks you will see the pattern.

You will discover where the system is foggy.

And you will discover which decisions keep getting second‑guessed because nobody can see what they were based on.

Then you can redesign the machinery that produces that fog:

• Reduce touch points
• Create stake tiers
• Set clear evidence packs
• Give decisions a memory

Because flow is not just a delivery problem.

It’s a decision problem.

And decisions don’t get faster when people “try harder”.

They get faster when the service becomes visible enough that a bet can be placed credibly - and left in place until the world changes.

The question to take into your next governance meeting

Before you ask for “more information”, ask this:

What stake are we trying to protect - and what specific assumption are we unsure about?

If you can’t answer that, the meeting isn’t governance.

It’s theatre.

And theatre is expensive.