Draw the Escalation Map, Not the Org Chart

Take the organisation chart.

Now put it aside.

On a blank page, draw only what happened the last twenty times somebody could not resolve something themselves.

A client wanted an exception.

Two teams disagreed.

A price needed approval.

A deadline became unrealistic.

A manager was unsure whether they had authority.

Finance found something that did not reconcile.

A customer complaint became serious enough that somebody wanted cover.

Draw an arrow from the person who first encountered the problem to the person they approached next.

Then keep drawing.

The result may look nothing like the organisation chart.

That second picture is worth studying.

Because the org chart describes the organisation when work proceeds as expected.

The escalation map describes the organisation when it does not.

And that is often where the real operating structure becomes visible.

The org chart is a map of formal relationships

Organisation charts answer useful questions.

Who reports to whom?

Where does a function sit?

Who leads a team?

How many management layers exist?

Where does accountability broadly belong?

They matter.

But they describe a relatively stable world.

Escalations live somewhere else.

They appear when the ordinary system reaches its edge.

The process does not cover this case.

Two legitimate priorities conflict.

Someone has responsibility but not enough authority.

A customer request falls between commercial and delivery ownership.

The information required to decide sits elsewhere.

An employee knows the answer but does not trust that they are allowed to act on it.

At that point, reporting lines become much less interesting.

The question becomes:

Where does uncertainty go?

That is what the escalation map reveals.

Start with arrows, not boxes

Most organisational design begins with boxes.

CEO.

Operations.

Sales.

Finance.

Account Management.

Delivery.

Then lines are drawn between them.

An escalation map should be built in the opposite direction.

Start with actual events.

Where did the issue begin?

Who encountered it first?

Who did they approach?

Did that person decide?

Did the issue move again?

How long did it wait at each point?

Where did it eventually stop?

Was the decision later reopened?

Do this often enough and patterns appear.

Not theoretical authority.

Actual authority.

A manager may occupy an impressive box on the org chart while very few consequential decisions stop with them.

Someone without a particularly senior title may quietly resolve half the organisation’s difficult problems.

A finance lead may become an unofficial commercial control point.

A founder may appear only once on the formal reporting structure and twenty-three times on the escalation map.

That difference matters.

Every organisation has an escalation gravity

Some people attract unresolved work.

Not because the organisation formally designed them to.

Because history has taught everybody that problems tend to get resolved there.

It may be the founder.

The longest-serving employee.

A highly trusted project lead.

The one commercial person who remembers why an old client agreement works the way it does.

The finance head who will challenge something everyone else would rather wave through.

The operator who can translate between two departments that barely understand each other.

Over time, unresolved work begins bending toward them.

Call this escalation gravity.

The stronger it becomes, the less the formal structure tells the truth.

An organisation may have three management layers while exceptions routinely jump all three.

Or a team may formally report into one leader while seeking approval from somebody else entirely when the decision actually matters.

This creates a kind of shadow organisation.

Not a sinister one.

Often a highly functional one.

The problem is that it depends on relationships the operating model has never acknowledged.

An escalation is not necessarily a failure

This distinction matters.

A good organisation should escalate some things.

A junior employee should not independently accept an unusual legal exposure because “empowerment.”

A project lead should not quietly absorb a commercially significant scope change merely to avoid involving somebody senior.

A manager should escalate when a decision exceeds their authority, risk tolerance or available information.

That is healthy.

The objective is not:

No escalations.

The objective is:

The right things escalate, through the right path, with enough information to produce a timely decision.

An escalation becomes interesting when one of three things happens.

It occurs too often.

It travels too far.

Or it repeatedly arrives somewhere the formal operating model says it should not need to go.

That is when escalation stops being an exception and starts becoming diagnostic evidence.

Follow what jumps a layer

One of the most useful marks on an escalation map is the jump.

A team member bypasses their manager and goes to the founder.

A salesperson skips the commercial lead and asks Finance.

An account manager takes a delivery disagreement directly to leadership.

A client bypasses the account owner and messages the founder personally.

The instinctive reaction is often behavioural:

Why did they go around the manager?

Sometimes that is the right question.

Sometimes the more useful question is:

Why did the person believe the intermediate layer could not resolve it?

Perhaps authority is unclear.

Perhaps the manager has authority on paper but decisions are routinely overturned.

Perhaps they lack information.

Perhaps the founder has historically invited direct escalation.

Perhaps everyone knows that involving the formal owner merely adds another meeting before the same issue travels upward.

The jump is not automatically insubordination.

It may be the organisation routing around a weak node.

Now look for sideways movement

Not every revealing escalation moves upward.

Some move sideways.

Sales asks Delivery whether a promise is possible.

Delivery asks Finance whether an exception is commercially acceptable.

Account Management asks Operations to resolve a problem neither function formally owns.

One department repeatedly borrows judgment from another.

That can be healthy collaboration.

But repeated sideways escalation can also expose a missing piece of operating architecture.

Perhaps the issue lives between two roles rather than inside either one.

Neither function is failing.

The boundary is.

This is one reason adding clearer job descriptions sometimes changes remarkably little.

The job descriptions may define each box perfectly.

The recurring problem lives in the white space between them.

The escalation map makes the white space visible.

Watch for the boomerang

There is another pattern worth marking.

A decision travels upward.

A senior person makes the call.

The decision travels back down.

Then, a few days later, it returns upward again.

That is an escalation boomerang.

Usually one of two things has happened.

The original decision resolved the immediate question but not the underlying ambiguity.

Or the person receiving the decision was given an answer without receiving the authority or reasoning required to handle the next variation themselves.

So the organisation buys the same judgment again.

And again.

And again.

This is where escalation volume can become misleading.

Twenty escalations may not represent twenty different problems.

They may represent one unresolved operating question appearing twenty different ways.

That is a much more useful diagnosis.

Repeated escalation is a design input

Suppose pricing exceptions repeatedly reach the founder.

The easy response is:

The team needs to be more commercial.

Perhaps.

But plot the events first.

What kind of exception?

At what value?

For what customers?

Why could the commercial lead not decide?

What information was missing?

What was the founder doing that nobody else could?

Perhaps the founder knows which clients are strategically important.

Perhaps only the founder knows the real margin floor.

Perhaps pricing authority has never been formally transferred.

Perhaps managers technically have authority but have learned that unusual decisions will be revisited later.

Each explanation suggests a different intervention.

Training.

Information.

Thresholds.

Decision rights.

Customer segmentation.

A pricing rule.

A review mechanism.

Or no intervention at all because the escalations are sufficiently rare and consequential that senior involvement remains appropriate.

The map prevents the organisation from prescribing before it understands the route.

The founder can disappear from the org chart and remain everywhere in the system

This matters particularly in founder-led businesses.

A company grows.

Managers are hired.

Departments emerge.

The founder acquires fewer direct reports.

The chart looks more mature.

And yet:

pricing exceptions still arrive;

difficult customer conversations still arrive;

hiring judgment still arrives;

cross-functional disputes still arrive;

large proposals still arrive;

quality concerns still arrive;

anything without an obvious answer still arrives.

Structurally, the founder has delegated.

Operationally, very little has moved.

This is why founder dependency can be difficult to see from the org chart alone.

The boxes show where responsibility has been placed.
The arrows show where judgment still lives.

Those are not always the same thing.

Do not simply shorten every escalation path

There is a tempting response once the map exists.

Flatten it.

Move decisions downward.

Cut approval steps.

Give managers more authority.

Sometimes that is exactly right.

Sometimes it is reckless.

A long escalation path can exist because the risk genuinely warrants it.

An unusual contractual exposure may deserve legal review.

A large pricing exception may deserve senior commercial judgment.

A serious people matter may require leadership involvement.

A high-impact customer failure may need several functions in the room.

The goal is not to make every arrow shorter.

It is to ask whether the length of the path matches the consequence of the decision.

A ₹2,000 operational exception travelling through three management layers is suspicious.

A decision capable of materially changing a client relationship travelling through three layers may be entirely sensible.

Good operating design does not distribute every decision.

It distributes decisions in proportion to context, competence and consequence.

Draw the waits as well as the routes

An escalation map becomes more revealing when time is added.

An issue originates on Monday.

It reaches the project lead that afternoon.

Moves to Operations Tuesday.

Waits until Thursday for Finance.

Reaches the founder Friday.

Decision comes Monday.

Nothing about that sequence appears dramatic on an org chart.

Yet one relatively ordinary issue has spent a week moving through the business.

That delay has a cost.

People hold context.

Work pauses.

Customers wait.

Teams create temporary workarounds.

Someone follows up.

Meetings get scheduled.

The issue accumulates coordination around itself.

This is why decision latency should not be confused with decision difficulty.

Sometimes a decision takes a week because it genuinely requires careful judgment.

Sometimes it takes a week because nobody knows where it belongs.

The escalation map helps distinguish the two.

The return path matters too

Most escalation systems focus on movement upward.

Something goes wrong.

It gets escalated.

A decision is made.

Done.

But there is another question:

What comes back down besides the answer?

If the response is simply:

“Do X.”

then the incident may close while organisational capability remains unchanged.

If the response includes:

“This is the principle.”

“This is the threshold.”

“This is why this case is different.”

“Next time, this decision sits with you unless these conditions apply.”

then escalation becomes a learning mechanism.

That distinction matters enormously.

Otherwise senior leaders can become increasingly efficient at resolving problems while the organisation remains equally dependent on them.

The escalation system works.

The operating system does not improve.

The map should change over time

A useful escalation map is not a governance poster.

It is a temporary picture of where the organisation currently runs out of clarity, authority, information or judgment.

Some arrows should disappear.

Some should move downward.

Some should become shorter.

Some should remain exactly where they are.

And new ones will appear as the organisation encounters different kinds of work.

The interesting measure is not whether escalation exists.

It is whether repeated escalation creates better architecture.

A threshold becomes clearer.

A manager gains authority.

A commercial assumption becomes visible.

A handoff changes.

A recurring exception becomes a rule.

A rule develops an exception path.

Judgment that once belonged to one person begins developing elsewhere.

That is how an organisation becomes more capable without pretending uncertainty can be designed out of it.

The chart shows the organisation. The map shows how it behaves.

Both matter.

The org chart remains useful.

It tells people where they belong and where broad accountability sits.

But when execution repeatedly slows, decisions rise unnecessarily, or the founder somehow remains involved in everything despite no longer directly owning it, another diagram is needed.

Take the recent exceptions.

Draw where they started.

Draw where they travelled.

Draw where they waited.

Draw where they jumped.

Draw where they returned.

Then compare that picture with the organisation chart.

The differences are the interesting part.

Because when normal work stops being normal, the business reveals the structure it actually trusts.

And that structure may be very different from the one hanging on the wall.