The Crossover Meeting: Where Strategy Stops Being a Document
Post-mortems on failed technology projects almost always start too late. They examine the build, the vendor, the testing, the change management — the things that happened after the money was committed. The decision that actually caused the failure was usually made months earlier, in a room where nobody was writing code and nobody thought they were making a technical decision at all.
Strategy gets set on one day, by one group. Technology gets briefed on another day, to another group. Between those two meetings sits a translation nobody is accountable for, and that gap is where most of the waste is created.
Why a strategy signed off without engineering is an approved rework budget
Consider what a scope document actually is. It is a set of technical commitments — about data, about integration, about what the system will and won’t be able to do next year — written by people who were not asked to think about any of that, and who reasonably assumed the technical questions came later.
By the time engineering sees it, three things have already hardened. The outcome has been described as a feature list rather than a result. The sequence has been set by what seemed logical on a slide rather than by what unlocks what. And a number has been quoted to a board.
None of those are technical mistakes. They are all technical decisions, made without technical input, and they are extremely expensive to unmake. The most common symptom is the cloud migration that moves the servers and leaves every manual step exactly where it was — because nobody in the strategy meeting asked what being cloud-native would make possible, and by the time somebody did, the scope was frozen. Cloud-native is not a tool choice. It’s a strategic assumption about how the business will work.
Why the order of the meeting matters more than its length
The fix is smaller than it sounds. One meeting, before scope freezes, with both halves of the decision in the room, run in a fixed order.
Outcome first. What are we actually buying? Not “a new system” — a result. Fewer interruptions for the person everything routes through. Quotes without an owner in the loop. A month-end that doesn’t consume a week. If the room can’t state the outcome in a sentence, the project doesn’t have one yet.
Capability second. Which capability unlocks that outcome earliest? This is the question that reveals sequence, and sequence is where most of the value hides. Often the thing that unlocks the outcome is not the thing anybody had on the list.
Deliverable last. What is the smallest build that proves the capability is real? Not the full system. The first release that produces evidence somebody outside the project can feel.
Run in that order, the conversation naturally surfaces two more things worth writing down: which manual handoffs should die in the first release, and what single metric will prove belief. Run in the other order — deliverable, then capability, then outcome — you get a feature list with a business case stapled to the front, and the outcome becomes whatever the features happen to produce.
Why this is not the same as more discovery
The objection is predictable and fair: we don’t have time for another workshop, and discovery is how projects get slow.
But discovery isn’t rework. It’s how you avoid it. A crossover meeting is an hour, not a phase, and its output is one page: the outcome, the capability that unlocks it, the smallest proof, the handoffs it kills, the metric. The slower approach reliably produces faster results, because building the right thing in the right order beats building the planned thing efficiently.
There’s a version of this that costs nothing at all: invite an engineer to the strategy conversation. Not to scope, not to estimate — to listen and to ask what would have to be true. The questions engineers ask in that room are almost never the questions the room was expecting, and they are almost always the ones that turn out to matter.
Where capability actually gets built
Capability is built where intention meets implementation. Not in the strategy document, which describes a destination, and not in the backlog, which describes a route — but in the conversation where the two are held against each other and one of them changes.
Most organisations never hold that conversation. They hold two conversations and hope the translation between them was faithful. It rarely is, and the cost of finding out is paid eighteen months later by people who weren’t in either room.