Executive Summary

• Who this is for: CTOs, VP Engineering, Engineering Managers, Technology Directors
• Problem it solves: Org redesigns that look structurally sound on paper reproduce the same load failures in practice — because they are designed from job descriptions, not from where the actual load falls
• Key outcome: A structured model that uses incident and on-call data to reveal real ownership distribution and drive org design decisions grounded in operational truth
• Time to implement: 30–60 days to build an Incident Ownership Architecture and act on its findings
• Business impact: Org changes that target real structural gaps, reduced key-person dependency, and engineering leadership decisions that cannot be undone by the first resignation

The Timetable Planner and the Control Room Log

A railway network publishes a timetable.

The timetable is precise.

Platform allocations. Crew assignments. Connection windows. Dwell times.

Every train has an owner.

Every crew has a route.

The network, on paper, is fully staffed.

Then the control room shift ends.

And the outgoing supervisor hands over the delay log.

Not the timetable.

The log.

The log shows something the timetable does not.

Platform 3 requested supervisor escalation 29 times last month.

Not because 29 incidents occurred at Platform 3.

Because Platform 3's assigned supervisor was covering Platform 7 every time something went wrong there.

The timetable said Platform 7 had coverage.

The log said Platform 7 had been borrowing it from Platform 3 for six months.

The timetable planner sees a fully allocated network.

The control room supervisor sees a structural dependency that one resignation will expose.

Same organisation.

Completely different picture.

This is exactly the situation most engineering organisations are in when they redesign their structures.

The org chart says Team A owns Service X.

The on-call log shows Team B has resolved 70% of Service X incidents for the past three quarters.

The org chart says the platform team is a shared service.

The on-call log shows one senior engineer on the platform team is personally resolving every critical incident regardless of which team owns the component.

The org chart was designed from intent.

The on-call log is the result of reality.

Most engineering leaders redesign from the first document.

Almost none redesign from the second.

The Org Chart Is a Staffing Hypothesis

Every org chart is a hypothesis.

It says: if we assign these people to these domains, ownership will work this way.

The hypothesis was reasonable when it was formed.

Teams were smaller. Systems were newer. The failure modes were unknown.

Six months later, the systems have grown.

Teams have shifted.

Informal dependencies have calcified into operational necessity.

And the hypothesis — never tested, never updated — has drifted away from operational truth.

On-call data does not drift.

Every incident is a data point.

Every escalation is a signal.

Every paged engineer is a vote on where load actually concentrates — regardless of what the org chart intended.

The on-call log is not a problem register.

It is the most accurate org chart the organisation has.

And almost nobody reads it that way.

What On-Call Data Is Actually Measuring

When an incident fires and an engineer gets paged, four things are being recorded simultaneously.

Where the load actually lands.

Who is trusted to resolve it.

Which team boundaries are being crossed to get it resolved.

And which senior engineer holds it all together when everything else fails.

None of these are visible in a headcount spreadsheet.

None of them appear in a team charter.

None of them survive an annual performance review.

But they are all in the on-call log.

Waiting for someone to read them structurally.

Incident Ownership Architecture (IOA)

Incident Ownership Architecture (IOA) is a structured method for reading on-call and incident data as an org design signal.

Its purpose is not to improve incident response.

Its purpose is to surface the gap between the organisation that was designed and the organisation that is actually operating.

IOA maps four signal types.

Each represents a structural condition that on-call data will expose — if someone is looking for it.

Signal 1: Load Concentration

One engineer or one team is consistently absorbing incidents that span far beyond their documented ownership.

The on-call schedule says they cover one domain.

The incident log shows they are resolving across three.

This is not a capability problem.

It is a structural gap — a place where the org design created ownership on paper but did not build the redundancy or authority to sustain it in practice.

Load Concentration looks like a reliable team.

It is actually a single point of structural failure.

Signal 2: Silent Dependency

A team is consistently paged for a system they do not officially own.

The ownership is documented elsewhere.

But when incidents occur, the documented owner either cannot resolve them or does not respond with sufficient speed.

So a different team absorbs the load.

Silently. Without recognition. Without authority.

This is a Silent Dependency.

It does not appear in the RACI.

It does not appear in the architecture diagram.

It appears in the on-call log — in the form of a team that has been resolving incidents for a system it has no formal mandate over.

Silent Dependencies are the informal contracts that keep engineering organisations running.

They also become the structural crises that follow key departures.

Signal 3: Ownership Drift

Incidents are consistently resolved by someone other than the documented owner.

Not because the documented owner is absent.

Because the operational reality of the system has drifted away from the ownership model that was defined when the system was smaller.

The team that owns the service on the diagram has not owned the production behaviour for months.

Another team has. Quietly. Without the org design being updated to reflect it.

This is Ownership Drift.

It generates confusion in postmortems — because two teams have different mental models of who is responsible.

It generates risk at every team restructure — because the org chart does not show who actually holds the system.

Signal 4: Escalation Fossil

Every critical incident, regardless of domain, traces back to the same person.

They are not the on-call engineer.

They are not the service owner.

They are the person who gets called when everything else has stalled.

Their name appears in postmortems across three teams.

Their phone was the last escalation point in seven of the last ten severity-1 incidents.

This is an Escalation Fossil.

The term is precise.

The fossil is the remains of a structural decision that was never made — the decision to build the knowledge, authority, and redundancy that would have made this person's informal role unnecessary.

When an Escalation Fossil leaves, the organisation does not lose a team member.

It loses the structural load-bearing element that the org design was never brave enough to name.

The Two-Layer Map

The output of an IOA analysis is a two-layer view of the same organisation.

Top layer: The official org design.

Documented owners. Team charters. Defined escalation paths. Architecture diagrams.

Bottom layer: The incident load map.

Who was paged. How often. What system. What resolution path actually taken. Which names appear across multiple domains.

The gap between the two layers is not a performance issue.

It is an org design issue.

Every row in the bottom layer where the official and actual picture diverge is a structural finding.

What Breaks When Nobody Reads the Log

When engineering leaders redesign org structures without reading the incident load data:

Org changes reproduce the same bottlenecks under new names.

A restructure creates two new teams from one old team.

The incident load distribution does not change.

The same engineers still absorb the cross-boundary load.

The same informal dependencies still operate invisibly.

The new org chart looks cleaner.

The on-call log looks identical to the one before the restructure.

Silent Dependencies become invisible succession risks.

The engineer who has been resolving another team's incidents for eighteen months moves to a different role.

Nobody modelled the load they were carrying.

Nobody mapped the systems they were informally supporting.

The first incident after they leave surfaces a gap that the org chart never showed.

Escalation Fossils become single points of organisational failure.

The most experienced engineer — the one whose phone gets called last — is offered a role elsewhere.

The leadership team is surprised.

They should not be.

The on-call log told them, every month, that this person was holding a structural responsibility the org design had never formally assigned.

When IOA is in place:

Org changes are designed from incident load truth — not from documented intent.

Silent Dependencies are surfaced before the people carrying them depart.

Escalation Fossils are converted into documented roles with named successors before the fossil becomes a vacancy.

The org design reflects the organisation that is operating — not the one that was planned.

Implementation Guide (30–60 Days)

Building an Incident Ownership Architecture requires data access more than process change.

The data already exists.

The structural reading does not.

Phase 1: Extract the Incident Load Picture (Weeks 1–2)

Pull 90 days of on-call and incident data from your incident management tooling.

For each incident, record:

• Service or component that triggered the alert
• Documented owner (from your service catalogue or CMDB)
• First responder (who was actually paged or picked up the incident)
• Resolution owner (who closed it)
• Escalation path (everyone who was pulled in before resolution)
• Time to resolution

Do not analyse yet.

Map the data.

Deliverable: 90-day incident dataset with documented owner, actual responder, resolution owner, and escalation path per incident

Success Metric: At least three incidents where the documented owner and actual resolver are different teams. At least one engineer whose name appears in the escalation path across five or more distinct systems.

Phase 2: Build the Two-Layer Map (Weeks 3–4)

Compare the incident load data against your current org design.

For each team in the official org chart, calculate:

• Incident load they were documented to carry
• Incident load they actually carried (including cross-boundary incidents)
• Systems where they resolved incidents without documented ownership
• Names of engineers who appear as informal escalation points across domains

Map every gap using the four IOA signal types.

Every Load Concentration, Silent Dependency, Ownership Drift, and Escalation Fossil gets named and documented.

Deliverable: Two-layer org map with official design and incident load picture aligned. IOA signal findings documented per team and per engineer.

Success Metric: At least one Silent Dependency identified between two teams. At least one Escalation Fossil named. At least two teams where documented vs. actual incident load diverges by more than 30%.

Phase 3: Convert Findings Into Structural Decisions (Weeks 5–8)

For each IOA signal finding, assign one of three dispositions:

Redesign now: Load Concentrations and Ownership Drift cases where the gap can be closed within 30 days through explicit ownership reassignment, role formalisation, or team boundary adjustment.

Succession plan: Escalation Fossils and Silent Dependencies where the structural fix requires longer preparation — knowledge externalisation, cross-training, or deliberate redundancy building. Assign a named owner and a 90-day timeline.

Accept and document: Structural gaps that are known, understood, and consciously carried as temporary conditions. Document explicitly with a named risk owner and a review date.

Deliverable: IOA findings register with disposition, structural action, named owner, and resolution timeline per finding

Success Metric: At least two structural decisions made or initiated based on incident load evidence. At least one Escalation Fossil converted into a documented role with a successor in progress.

Evidence from Practice

Organisations that build an Incident Ownership Architecture for the first time consistently find the same pattern.

The gap between documented ownership and actual incident load is wider than anyone expected.

Not because the teams are failing.

Because the systems have grown in directions that the org design did not anticipate — and the informal network adapted faster than the formal structure.

The Escalation Fossil finding produces the most uncomfortable conversations.

Leaders know who this person is.

They have known for months.

But framing it as a structural problem — rather than a personal capability — changes what is possible.

A fossil can be converted into a platform.

Knowledge can be externalised.

Redundancy can be built.

But only when the pattern is named.

The Silent Dependency findings produce the second most important conversations.

Teams discover they have been informally relying on each other for months — sometimes years — without the relationship being reflected in any team mandate, service catalogue, or architecture diagram.

Surfacing the dependency does not create a problem.

It names one that already existed.

Named dependencies can be formalised, supported, or eliminated.

Unnamed ones become the incidents that nobody could explain in the postmortem.

Action Plan

This Week

Ask three questions:

1. In your last five severity-1 incidents — was the resolution owner the same as the documented service owner?
2. Can you name every engineer whose informal escalation load is greater than their documented responsibility?
3. If your most frequently paged engineer left tomorrow, how many systems would lose their informal load-bearing support?

If these answers are unclear, the incident load map has never been read structurally.

Next 30 Days

Pull 90 days of on-call and incident data.

Map it against your current org design.

Look for the four IOA signals: Load Concentration, Silent Dependency, Ownership Drift, Escalation Fossil.

Document every gap.

Name every finding.

Do not redesign yet.

Understand what you are actually running before changing how it is structured.

3–6 Months

Embed an IOA review into every org design decision.

Before any team restructure, any role change, or any ownership reassignment — run the incident load picture first.

Make it a prerequisite.

Structural decisions made without incident load evidence are hypotheses.

Structural decisions made with it are interventions.

Final Thought

The timetable planner designed a fully allocated network.

The control room log showed a network held together by informal borrowing.

Same railway.

Completely different structural picture.

The on-call log is not an incident register.

It is the most accurate picture of how your engineering organisation actually operates.

The organisation that is designed and the organisation that is running are rarely the same.

The on-call log is the only document that knows which one is true.

Turn Your Incident Log Into an Org Design Decision

If your last restructure reproduced the same bottlenecks under new names…
if a key engineer leaving exposed a structural gap nobody had modelled…
or if your on-call load and your org chart tell two different stories —

your org design may be based on intent rather than operational truth.

In a focused 30-minute Incident Ownership Architecture Diagnostic, we will:

• Map your actual incident load against your documented org design
• Identify Load Concentrations, Silent Dependencies, Ownership Drift, and Escalation Fossils in your current structure
• Surface the structural gaps your org chart has never shown
• Define a 30-day plan to convert findings into structural decisions before they become departures

No headcount theater.
No restructure proposals built from job descriptions.
No org design decisions made without reading the log that already has the answer.

→ Book a Technology Leadership Session

or

→ Contact me directly

The org chart shows the organisation you designed.

The on-call log shows the one you are running.