Every Local Diagnosis Is Correct

Why a structural problem outlives competent people, and what it takes to see one

A problem keeps coming back.

It was fixed in March, and the fix was right. It came back in July under a different description, was fixed by a different team, and that fix was also right. It is back now, and the meeting about it will produce a third correct fix.

Nobody in that meeting is wrong. That is the diagnosis, not a consolation. A structural problem is one where every local diagnosis is correct. Each layer looks at its own evidence, reasons soundly, and produces an answer that is accurate about its layer and useless about the system. An earlier post in this series traced how a single team misreads a problem its reflexes were not built for. This is the same failure one level up, and it needs something no seat in the org chart provides: sight across the layers.

The diagnosis

The loudest layer is never the cause

Money is the most instrumented layer in any company. Margin, burn, cost per unit, the line that bent in Q2 — measured continuously, reported upward, legible to everyone at once. Financial symptoms are the clearest ones you will get, and the furthest from their own cause.

Very little originates in the finance layer. A margin that drifts was usually produced by a commercial model that stopped matching what delivery actually costs, or a handover that quietly moved work onto a team nobody re-budgeted, or an architecture decision from three years ago now paid monthly. Finance is a superb detector and a poor diagnostician, and because it is the layer everyone can read, it attracts all of the remediation.

So the response is financially correct and structurally irrelevant: cut, freeze, renegotiate, defer. It works — for two quarters. Then the number bends again, because the thing producing it was never touched. The temporary relief is the worst part of the loop: each round of correct financial action buys time, and buys conviction that the problem is financial.

Cost optimisation operates on the layer where the signal is loudest, which is reliably the layer that did not cause it.

Why the cause is invisible from inside

Each layer receives its inbox and produces its output — that is what a layer is. Support sees tickets. Delivery sees slipping dates. Engineering sees a fragile module. Finance sees margin drift. Each characterises its own evidence precisely, and none can see that the four descriptions are one thing.

The symptom surfaces wherever the system is thinnest. The cause sits wherever a decision was made — usually several layers up, often years earlier, frequently by someone who has since left. That distance is what lets a problem survive competent people for years.

THE DECISION THAT CAUSED IT
Strategy and ownership
Made once, years ago, often by someone who has since left
Commercial model
The deal still looks like the standard one
Architecture
One module is fragile and everyone knows which
Process and handover
The handover needs one more checking step
Delivery
The dates keep slipping and the estimates were fair
Support
The same tickets keep arriving
WHERE IT SHOWS UP
Every diagnosis on this stack is correct. None of them is the problem. Finance reads the whole stack and reports margin drift, which is why the remediation lands there and nowhere near the cause.

The opening question of any serious engagement is therefore not what is broken. It is how far apart are the symptom and the decision that produced it — and answering that requires standing outside the stack.

When to buy: two doors, and only one is on time

Outside help gets bought through two entirely different doors. Most companies only ever use the late one.

The late door: a symptom. Something has been failing repeatedly — a product, a team, a handover, a month-end. The leak has become routine enough to be budgeted for. This is a legitimate entry and it is always behind: by the time repetition is undeniable, the structure has been producing damage for a year or more, and part of that damage is now load-bearing.

The on-time door: an event. One to two years of growth. A restructure. A merger. A leadership change. Headcount doubled. Nothing is failing — and the shape you are running was designed for a company that no longer exists. The deliverable here is not a repair. It is knowing what breaks first, before you find out by breaking it.

Growth is the strongest trigger on the list precisely because it produces no symptoms. Revenue rising pays for every inefficiency underneath it. Structural decay during growth is invisible not because people are inattentive but because the growth is funding the thing that would otherwise be a complaint. The bill arrives when growth flattens, and by then it is the late door.

ON TIME
Put these on a calendar. Nothing is failing yet.
Twelve to twenty-four months of growth
A restructure completed
A merger or acquisition integrated
Headcount doubled
A leadership change at any layer
No answer to what breaks first at three times the size
ALREADY LATE
Any two of these together. The structure has been paying for a year.
The same issue fixed three times, by three teams, correctly, and still returning
Two departments that do not talk both report it, and blame each other
Every remedy adds a process and nobody has removed one in a year
Whatever breaks, the repair lands on the same team
Decisions do not survive a quarter

The most reliable late signal is also the least noticed: whatever breaks, the repair lands on the same team. When one team keeps absorbing consequences that originate elsewhere, the company has converted a structural defect into a headcount cost and stopped perceiving it as a defect. It now reads as that team is always overloaded, which sounds like a staffing conversation.

Why an event needs a calendar, not a feeling

The frog in the gradually heated pan does not jump. The story is biologically false — real frogs leave — but it survives because the effect it describes is real and has better names.

Shifting baseline: you cannot perceive drift, because your reference point moves with it. Nobody compares the company to how it worked two years ago; everyone compares it to last quarter. Each comparison shows a small, tolerable delta, and the sum of tolerable deltas is never assessed by anyone.

Normalisation of deviance: the tolerance moves too. A deviation that repeatedly fails to cause a disaster becomes the standard — the term was coined in the investigation of the Challenger shuttle accident. The workaround introduced for one client is now how the process works. Nobody decided that. It was never on an agenda.

Both mechanisms are strongest during growth, because growth supplies a constant stream of good news that makes every accumulated deviation look survivable. Both are also strongest right after a restructure, for the opposite reason: everyone in the room recently argued for the new shape, so it sits at peak ownership and minimum questionability. The internal capacity to question is at its lowest exactly when the need is at its highest.

That is why the on-time door has to be a scheduled evaluation rather than a judgement call. A judgement call is made by people whose baseline has already moved. You cannot use the drifted instrument to measure the drift.

Why it has to come from outside

You already audit one layer over

Watch what gets bought when those events fire. After a merger, structure, banding and retention risk get reviewed. After two years of growth, someone rebuilds the compensation bands and the org chart. The books are audited annually whether anything is wrong or not. All of this is normal, budgeted, and nobody in the room treats it as an admission of failure.

Now count how often the same company commissions an outside reading of the product — the thing that generates the revenue, carries the customer, and either enables the next stage of growth or caps it. Almost never.

The asymmetry is structural, not a judgement about importance, and it has four causes.

The habit was imposed, not chosen. Financial audit is statutory. People and pay review is driven by employment law and litigation exposure. Both external eyes exist because someone outside the company required them. Nothing requires an architecture review, so no habit formed. The two layers that get examined are the two where examination was never optional.

There is no external standard to be measured against. Nobody says we have an accountant, so we don’t need an auditor — the auditor measures against IFRS, not against the accountant. Everyone says we have a CTO, so we don’t need an outside review, because there is no equivalent standard for the CTO to be measured against. No standard, no benchmark. No benchmark, no audit. No audit, and the only assessment available is self-assessment.

The buyer cannot read the output. A board can read a financial statement and a pay-band report. It cannot read a codebase or a system diagram. So the layer that most needs an outside reading is the one where the commissioning party is least equipped to evaluate the reading it paid for — which makes the purchase feel unverifiable, and unverifiable purchases do not get approved twice.

Technical decay has no line item. Financial risk and people risk are quantified and reported. Structural decay in the product appears on no statement anywhere, so to the people who commission reviews it does not exist. It surfaces later, translated — as margin drift, as slipping delivery, as attrition on the team that has been absorbing it. Which closes the loop from earlier: the finance layer eventually reports the technical cause, in the one format that makes it look like a finance problem.

And when technical help is bought from outside, it is overwhelmingly bought as hands — a vendor to build the thing, an outsourced team, staff augmentation. That is the contractor role we set out earlier, and it is legitimate work. But a company whose entire lived experience of external technical is contractor-shaped generalises from it: external technical means labour, labour means commodity, commodity means negotiate the rate. The category of external technical judgement is rarely rejected. It has usually never appeared on the menu.

You audit the ledger, and not the machine that fills it.

The capacity depletes with tenure

None of this is because your people lack the ability. What the work needs is not expertise — your people have that. It is the freedom to ask why does this exist at all, and that freedom is spent on arrival. Two years in, every structure is partly theirs, so questioning it is self-indictment. Worse, they now know why things are the way they are: the constraint in 2023, the client who insisted, the migration that was supposed to be temporary. Knowing why something is that way is what disqualifies you from asking whether it should be. The reason is cached, so the question never fires.

The question also becomes socially unaffordable. A tenured insider asking why a core system exists is implicating a colleague in the room. An outsider asking the identical sentence is doing due diligence. Same words, different price — and past a certain price, people stop asking without ever deciding to.

And hiring selects against it. There is no title for reads across layers and starts from first questions, no filter that finds it, and an interview process that rewards people who already know your domain — the single property that disqualifies them from this particular work.

This is also why the people who do have it tend to leave once things are stable: the phase they are built for has ended, their own questions have become expensive, and nothing left in the building needs the faculty. Reading that departure as a retention failure produces a compensation review that answers a question nobody asked.

The in-house counter is rotation rather than retention. Move the person who fixed operations onto finance systems, where they own nothing and remember nothing — cheaper than buying the sight back, and the knowledge stays in the building. It also means moving a competent person off something they are currently good at, which is why most companies say they do this and few do.

What cross-layer sight is

The word visionary suggests distance. It is the wrong axis: they see across.

They read every layer’s output as evidence about the same object. A support call, a standup, a churn number, a merge request, a customer’s tone on a renewal — different formats, one system. Not deep expertise in every layer; enough in each to read its output honestly and refuse to discount evidence for arriving in an unfamiliar shape.

They carry a model of effect. Given a change here, they know what surfaces there, and roughly when. That is inference along a causal chain, not prophecy. It is also why their objection so often looks disproportionate to the proposal on the table: they are not responding to the proposal, they are responding to its consequence two layers away, which is already determined and not yet visible to anyone else.

They hold the picture at the altitude where the joins are still legible. Zoom out far enough and everything looks fine. Zoom in far enough and every layer is individually defensible. The whole skill is the middle, and no position on the org chart sits there.

What reads as foresight is mostly reading the present at full depth. If you can trace the chain, the outcome is already contained in the current state — you are not predicting it, you are reporting it early. Which is exactly why it does not land: they are arguing with a future nobody else has been shown.

The number that bent last quarter — which layer measured it, and which layer decided it?

Share this post
Archive
Which Development Method Survives AI
What to run instead, and the price behind each step