Sit through a reorganization and watch what actually changes.

The boxes move. The names change — competence centres become value streams become domains become platforms, on roughly a five-year cycle, and each generation is faintly embarrassed by the last one. Reporting lines get redrawn. There is a stretch of about three months where nobody is entirely sure who to ask about anything, and people quietly keep using their old contacts.

Then look at what people are actually doing. Claims still get settled. Customers still get onboarded. Releases still ship. The work the organization exists to do turns out to be almost completely unmoved by the exercise, which is either reassuring or expensive depending on what the reorganization cost to run.

That gap, between what changed and what carried on regardless, is what this chapter is about. There is a layer of an organization that survives its own restructuring, survives its systems, and survives most of the people currently staffing it. Very few organizations have ever written it down, which is why they keep rediscovering it — at full price — every time somebody moves the boxes again.

I once helped turn that layer into a card game.

It was for a planning workshop, and it sounds playful, which was the point. Formal documentation rarely gets a room full of people from different silos arguing productively about priorities. A deck of cards on a table does.

What the game did was move the conversation from which system owns this to what are we actually trying to be able to do. That shift — from solutions to capabilities — is usually where the real work of a transformation begins.

Everything below leans on one word, and it is defined in Part I rather than here — What a Capability Is, and Is Not, including the four things it gets confused with and the ten-second test for whether you actually have one. The short form: an enduring business area that owns an outcome, and outlives whatever happens to deliver it this decade.

Organizations that can name their capabilities clearly tend to survive their own technology decisions. Organizations that architect around tools instead rebuild the same understanding from scratch every time the tooling changes — and then wonder why each transformation costs as much as the last one.

Long before a capability shows up in a roadmap, it starts as a model — a way of seeing the organization that isn’t the org chart and isn’t the system diagram. Making one is closer to cartography than to documentation: you’re not describing every feature of the terrain, you’re deciding which features matter enough to draw.

A capability map is one of the most useful models available, because it’s the one artifact a business stakeholder and an engineer can point at and mean the same thing.

It is tempting, especially now, to let the conversation start with the tool, because the tool is concrete and available and somebody is already selling it. The organizations that resist that pull are not more disciplined than the rest. They simply have somewhere else to start from, and the ones that don’t have no choice but to start with what is in front of them.

Where it goes wrong from the other direction is when the map itself starts attracting effort. I have watched a capability map become a project, with a maintainer and a review cycle, at which point it has quietly become a system of its own. The artifact was never the point. The argument it forced into the open was, and that argument tends to outlive the diagram by several years.

Naming a capability is only half the job, though. Someone still has to be able to run it — and that is where the map stops being a diagram and starts deciding how people spend their Tuesdays.

What survives the reorganization is the work itself, and almost nobody writes it down.

What moves this is naming the handful of things the organization must always be able to do, in business terms rather than system names, and then funding and organizing around those rather than around whatever is delivering them this decade. The map is not the point — the argument it forces into the open is, and that argument outlives the diagram by years. Expect the first attempt to produce a list that is too long and too technical; the second one is usually the real one.

Cultivating this: Funding What Doesn’t End, in Part III. An organization’s capabilities shift as slowly as anything in it does, but they do shift, and a map nobody tends drifts out of date exactly when a reorganization or a new system makes it most worth having — which is where Part III picks the thread back up, in the chapter about paying for the things that never finish.