How Organizations Actually Work
There are two organizations in every building, one described in documents and one that gets the work out, and most attempts at change are addressed to the first.
Two organizations, same building
The designed organization has a structure, a set of processes, defined ownership and a stated way that work moves, and it lives in slides, handbooks, system configurations and the answers people give when a senior person asks how something works.
The operating organization is what actually happens, with different paths, different decision points and a different set of people who matter: the message sent before the ticket, the person who gets asked because they always know, the step that gets skipped because it stopped being useful, and the spreadsheet holding the version everyone trusts.
The second one isn't a shadow or a corruption of the first, it's the organization itself, and the first is a description of it that has fallen out of date in places, in ways nobody has audited.
The divergence is uneven, which is what makes it so hard to spot. Some parts of the documented system are perfectly accurate and have been for years. Others were accurate when they were written and drifted after a reorganization, a system migration, or the departure of one person who'd been holding a seam together. The document doesn't tell you which is which, so reading it gives you a mix of fact and archaeology with nothing to mark the difference.
The undesigned version is coherent
It's tempting to read the gap as decay, as if discipline slipped, people cut corners and the process just needs reinforcing, but that reading is almost always wrong and it leads straight to the wrong intervention.
What the gap actually records is adaptation, since every deviation started as somebody solving a real problem the design didn't handle. The skipped step got skipped because it produced nothing. Somebody keeps a private record because the official one couldn't be acted on, and the informal approval happens first because the formal one takes four days and the customer is waiting.
Seen that way, the operating organization is a rational response to conditions, assembled locally, one decision at a time, by people who know more about their own work than anyone above them does. Think of it as a distributed repair of the design, carried out without authority or budget, and without anyone noticing.
Coherent still falls short of optimal, and that distinction matters before this turns into an argument for leaving things alone. Local repairs are made with local information. The person who built the workaround could see their own step and the two on either side of it and nothing past that, so they solved their problem in a way that may have moved cost onto someone three handoffs downstream, who has since built a repair of their own on top of it. What piles up is a structure where every individual piece has a good reason and the assembly as a whole has none.
The repairs outlive their causes, too. A check added after an incident in 2019 is still being performed in 2026 by people who've never heard of the incident, because nothing in the organization is responsible for retiring a repair once the condition it addressed has gone away. Accumulated systems only ever add.
When people resist a change, they're usually defending a repair, and they're the only ones who know what it was repairing.
Why it stays invisible from above
Nobody is hiding any of this, it stays invisible for structural reasons.
Reporting comes out of the designed system, so it describes the designed system. A workaround that happens in a message, a spreadsheet or somebody's memory produces no data, and from a distance the organization appears to be running its documented process exactly. The absence of evidence is the design working as specified.
The people who could describe it have stopped noticing it, too. Ask someone how a request gets through and you'll hear the official answer, because the compensating became automatic years ago, part of the job, and it doesn't register as an event anymore. I've sat with someone while they described a process, then watched them do something quite different an hour later with no sense of contradiction between the two.
There's a third reason, and it's the least comfortable. In many organizations the workaround is technically a deviation from policy, so describing it accurately to a senior visitor carries a small risk and no reward. Nobody lies, they just answer the question that was asked, in the terms it was asked in, and let the rest go unmentioned. The more an organization has punished deviation in the past, the cleaner and less true the answers get.
What this does to change programs
An initiative aimed at the designed organization can succeed completely and leave the operating one untouched.
The process gets redesigned, the system reconfigured, the training delivered, and the people doing the work map the new instructions onto whatever they were already doing, keeping the parts that were load bearing. Compliance is high and behavior is unchanged. Everyone is being reasonable, and the organization has spent a year negotiating with a description of itself.
Afterwards the failure has a recognizable signature. Usage numbers are healthy, the sponsor's report is green, and the operating measure that justified the whole thing hasn't moved. When that combination shows up, the useful question is which repair the new design failed to account for, and where that repair went once the new system arrived, because it went somewhere.
The uncomfortable corollary is that resistance is often the most useful signal you have. When people push back on a redesign, what they're protecting is usually a repair that only they can explain.
A cheap discipline follows from this: when someone objects to a change, treat the objection as a bug report about the design. Ask what breaks, specifically, in a case they've actually seen. Most objections resolve into either a real omission, which you now have for free, or a preference, which becomes obvious under the same question. Either result is worth more than the persuasion campaign that usually gets run instead.
Reading the difference deliberately
If the operating organization is the real one, the practical question is how to see it, given that it doesn't describe itself and the people inside it have stopped noticing it.
Most of it can be recovered in three ways. The first is to follow the work itself, because the path a request takes crosses boundaries no org chart predicts and shows you the people who matter wherever they happen to sit. Another is to look for artifacts: the shared file, the group chat, the saved view, the document called something like "how it really works" sitting in a folder nobody senior opens. And when you do ask questions, ask about the last difficult case, because a specific recent instance gets remembered accurately while a general description gets reconstructed to match the official version.
All of that can be done without authority or a mandate, since what it takes is presence, and being uninteresting enough that the work carries on normally while you watch. Presence is a real constraint on who can do it, and one of the better arguments for having the diagnosis done by someone who works close to the operation.
Every organization already has an operational system
None of this makes documentation worthless or formal process something to abandon. The practical conclusion is narrower and more useful than that.
Every organization is already running an operational system, made of people, workflows, decisions, data and technology arranged in a particular way, and the only open question is whether that arrangement was designed or accumulated. Accumulated arrangements aren't random, but they were optimized locally, under old conditions, by people solving the problem in front of them, and they carry the cost of that forever.
Designing one means starting from the arrangement that exists, whatever the one on the wall says, which makes for a slower beginning and the only one with a chance, because the operating organization is the one that decides whether anything you build survives contact with the work.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
