A capability map tells you what the business does. A strategy tells you what it wants. Cross-mapping is the unglamorous grid that proves whether the second is actually funding the first.

By now the gap should feel familiar: strategy lives in narrative, execution lives in tickets, and nothing in between translates one into the other. The capability map gave us a stable middle layer. Cross-mapping is what we do with it — the act of drawing explicit lines between the things that otherwise only touch in hallway conversations.

What cross-mapping is

Cross-mapping is the practice of relating one architecture dimension to another and recording the links. The relationships that close the strategy-to-execution gap are a short chain: strategic objectives map to the capabilities they depend on; capabilities map to the initiatives investing in them; initiatives map back to budgets and teams. Each link is a simple claim — "this objective needs this capability," "this initiative improves this capability" — but assembled, the chain answers a question most portfolios cannot: is our money actually pointed at our strategy?

The grid that ends the argument

Picture a grid. Down the side, your strategic objectives. Across the top, your capabilities. Put a mark where an objective depends on a capability. Now overlay a second fact: which of those capabilities have funded initiatives against them. Two patterns jump out immediately, and both are the kind of thing leadership teams argue about for hours without data.

The first is the empty column that should be full — a capability several objectives depend on, with no initiative funding it. This is the strategically critical, chronically underfunded capability, and it is the single most common and most expensive blind spot in a portfolio. The second is the busy column no objective points to — heavy investment in a capability that no current strategic objective needs. Sometimes that is keeping-the-lights-on work, which is fine. Sometimes it is a project with momentum and no mandate, which is not. Either way, you can now see it and decide on purpose.

From a snapshot to a question you can re-ask

A cross-map's real value is not the first picture; it is that you can re-ask the same question whenever the world moves. When a new objective appears, you trace it to capabilities and check whether they are funded. When a project is proposed, you ask which capability it improves and which objective that serves — and if it cannot answer, that is information. When the market shifts mid-year, you do not wait for the next offsite to find out whether you are still set up for it. The grid turns a once-a-year reconciliation into something you can check on a Tuesday.

How to start without boiling the ocean

You do not cross-map the entire enterprise. You start with one strategy. Take this year's objectives — there are rarely more than a handful that matter — and for each, list the capabilities it genuinely depends on. Then pull your funded initiatives and tag which capability each one actually improves. The first time a leadership team does this honestly, the exercise takes an afternoon and the result is uncomfortable: objectives with no investment behind them, and investment with no objective in front of it. That discomfort is the gap, finally rendered as a grid instead of a feeling.

A worked example: the column that was empty

A retailer cross-mapped its five annual objectives against its capability map for the first time. Four of the five lit up with funded initiatives — predictably, since those were the objectives with vocal sponsors. The fifth, "make returns effortless," traced to three capabilities: reverse logistics, refund processing, and returns analytics. All three columns were empty. Not underfunded — empty. The objective had been declared at the offsite, repeated in the all-hands, printed on the wall, and never once attached to a single line of budget. Everyone assumed someone else owned it. The cross-map was the first artifact in the company that could hold the objective and the funding in the same view, and the moment it did, the omission was obvious.

That is the quiet power of the grid: it does not need to be clever, only honest. An empty column under a stated objective is not an opinion to be debated; it is a fact to be explained. Most of the value of cross-mapping is simply forcing that fact into a room where it cannot be talked around.

What cross-mapping is not

Two artifacts get mistaken for cross-mapping and quietly replace it. The first is the status report — the red-amber-green dashboard that tells you each initiative is on track or not. That measures whether projects are healthy; it says nothing about whether the projects, however green, add up to the strategy. You can run a portfolio of immaculately green initiatives straight past your objectives. The second is the responsibility matrix — the grid of who is accountable for what. That captures ownership, not dependency; it tells you who to call, not whether the work serves the plan. Cross-mapping answers the question both of those skip: does what we are funding actually connect to what we said matters? Keep it distinct from the dashboard and the org tools, or it will be absorbed into them and lose the one thing it uniquely shows.

Keeping it honest over time

A cross-map is most useful as a living link, and living links rot in a predictable direction: toward flattery. Under pressure to demonstrate alignment, teams start drawing a line from every initiative to the nearest impressive objective, until the grid is reassuringly full and completely meaningless. The discipline that prevents this is a single rule — a link is only real if someone can state the mechanism. Not "this project supports growth" but "this project improves the onboarding capability the growth objective depends on, and here is how we'll know it moved." If the mechanism cannot be stated, the line comes off the grid. A smaller, true cross-map beats a fuller, flattering one every time, because the empty cells are the entire point.

There is a payoff for that discipline beyond honesty. A cross-map whose links each carry a stated mechanism becomes a model you can reason with when the world changes. Kill an initiative and you can see which capability loses its only investment and which objective therefore quietly goes unsupported. Add an objective mid-year and you can trace, in minutes, whether the capabilities it needs are funded or whether you have just made a promise with no budget behind it. The flattering version can do none of this, because its lines mean nothing; the honest version turns every portfolio change into a question you can actually answer.

The mechanics are not the hard part — a cross-map can live in a spreadsheet before it ever lives in a tool. The hard part is the discipline of keeping the links honest: resisting the urge to draw a line from every project to the nearest impressive objective so the grid looks full. A cross-map that flatters the portfolio is worse than none, because it launders the gap instead of exposing it. Drawn honestly, it is the most direct answer business architecture has to its founding question — and the reason the discipline exists at all.

Business architecture exists because strategy is too abstract and operations are too concrete, and the gap between them is where most transformations die.

A CEO says: “We’re becoming a customer-centric organization.” What does that mean in terms of capabilities? Which capabilities need to be built, bought, or rewired? Which processes change? Which information flows differently? Which roles get redefined?

This is the translation problem. Strategy is written in the language of intent. Operations is written in the language of execution. Without translation, intent and execution diverge for years before anyone notices.

Business architects are translators. The skill is not modeling — it’s holding both languages in mind simultaneously and finding the words that travel between them. If your business architecture function isn’t doing translation, it’s doing decoration.

Cross-mapping is relating one set of architecture elements to another and recording the connections — most usefully, linking strategic objectives to the capabilities they depend on, and capabilities to the initiatives that invest in them. Each connection is a simple, checkable claim.

Its purpose is traceability: the ability to follow a line from a strategic ambition through the capabilities it requires to the work and money behind them — and back again. That two-way trace is what lets you spot a critical capability with no funding, or a well-funded initiative with no strategic rationale.

A cross-map is not a project plan or a roadmap; it does not say when things happen. It says what depends on what, so that planning and funding decisions can be made against the whole picture rather than one project at a time. It is the connective tissue, not the schedule.

A steering committee convenes,
To discuss what the dashboard all means.
Three hours, no decisions,
Just polite revisions —
And a follow-up meeting, by means.