A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. — Alfred Korzybski, Science and Sanity (1933)
Ask a team what they're building and you'll get a confident answer. Ask them what the organisation will be able to do when they're done — that it couldn't do before — and the room goes quiet. That silence is the gap between activity and capability, and it's where a lot of good pushes quietly go to waste.
Projects end. Capabilities don't.
Here's the distinction that changed how I plan. A project is transient: it has a team, a budget, an end date, and then it's gone. A capability is durable: it's a thing your organisation can do — onboard a customer, forecast demand, answer a question from its own data — and it persists long after the project that built it has been archived and the Slack channel muted.
Strategy people have a whole discipline for this — capability-based planning, with roots in enterprise architecture — and the core move is almost embarrassingly simple: describe the organisation as a map of what it can do, rather than a list of what it's working on. Then point your investment at the capabilities that matter and let projects be the vehicles, not the destination.
If that sounds familiar, it should. It's waypoints, not milestones, one level up. Milestones track the vehicle. Waypoints track the journey. Capabilities are the terrain the journey crosses.
Why the map earns its keep
It survives reorgs. Team names, product names and org charts churn. "We can settle a claim end-to-end without a human touch" is stable language across all of it. When your plan is written in capability terms, a restructure doesn't invalidate it.
It exposes the real gaps. Lay the map out and heat-map it — where are we strong, where are we duct tape and heroics? The uncomfortable colours usually cluster somewhere nobody's roadmap was pointing. That's information you can't get from a backlog, because backlogs are lists of what you already decided to do.
It makes "why this push?" answerable. Every push should be able to complete the sentence: "after this, we will be able to ___." If the blank stays blank, you're not pushing toward anything — you're just busy. Structure the work so each increment leaves a capability measurably better than it found it, and give the work a shape that matches.
The failure mode: map worship
A warning from the field, because every good tool has one. Capability maps attract a certain kind of meeting. The map becomes an artifact to be curated, versioned, argued about at level three of decomposition, laminated. Six months in, nobody has shipped anything but the map has a style guide.
The map is for choosing. One page, coarse boxes, honest colours. If drawing it takes longer than a couple of working sessions, you're building furniture, not navigating. The moment the map stops changing which pushes you fund and which you decline, it has stopped earning its keep — roll it up and get back on the trail.
Starting small
You don't need an enterprise architecture function to do this. Take one page. Write the eight to twelve things your part of the organisation must be able to do well for the strategy to be real. Colour each one green, amber or red — gut feel is fine, the argument the colours provoke is the actual product. Then look at your current pushes and draw the lines. Pushes with no line to the map are candidates for knowing when to roll 'em. Red capabilities with no push pointing at them are your next conversation.
The route matters — of course it does. But routes are easy to argue about and cheap to redraw. It's the map that tells you whether you're arguing about the right terrain.
References
- Korzybski, A. (1933). Science and Sanity. International Non-Aristotelian Library. — Source of the epigraph, and of ninety years of people misquoting "the map is not the territory" at each other in meetings.
- The Open Group. (2023). TOGAF Series Guide: Business Capability Planning (G233). — Capabilities as the bridge from strategy to implementation, straight from the people who laminate maps for a living.
- The Open Group. (2016). Capability-Based Planning: The Link Between Strategy and Enterprise Architecture (White Paper W16C). — The genuinely short version.
- Cheng, S. (2015). "Translating Strategy into Implementation via Capability-Based Planning" (MSc thesis, University of Twente). — The "shorter, very readable take" turns out to be a 155-page thesis, which says everything about enterprise architecture's idea of brevity.
