The Alignment We Can Never Reach
We have been trying to finish something that can only be continued.
Executive Summary
For the better part of a decade the industry has treated the distance between what the business wants and what its technology delivers as a problem to be solved — a condition of alignment to be reached through the right model, the right steering committee, the right annual planning round. This essay argues that alignment, understood as a destination, is a structural illusion. The two domains it sets out to join run on different clocks, answer to different masters, and speak to each other through documents that begin to decay the moment they are signed. What we routinely diagnose as a failure of effort, or of goodwill, or of executive sponsorship, is more often a failure of category: we have been trying to finish something that can only be continued.
The seduction is understandable. A gap invites a bridge; a misalignment invites a realignment; and the alignment models of the last decade gave us a vocabulary that made the whole enterprise feel tractable. But the very neatness of the picture is what betrays it. The moment the laminated matrix leaves the workshop, three forces begin pulling business and technology back out of step — a difference in tempo, a difference in accountability, and the short half-life of the artefacts through which the two sides communicate.
The practical consequence is not despair but a change of posture. Organisations that treat alignment as a state to be certified once a year build the machinery of certification — the matrix, the sign-off, the RAG report — and then wonder why the machinery keeps telling them they are aligned while the delivery floor tells them they are not. Organisations that treat alignment as a standing negotiation build something different: thinner artefacts refreshed more often, shared accountability for outcomes rather than split accountability for inputs, and governance that meets the clockspeed of the business rather than the clockspeed of the budget cycle.
This is an argument for humility about a word we have oversold, and for the specific practices that humility recommends.
The Laminated Matrix
The workshop runs for two days and produces, as workshops of this kind reliably do, a matrix. Down one axis, the corporation’s strategic objectives — grow the mid-market, integrate the acquisition, take cost out of the back office. Across the other, the technology initiatives meant to serve them — the ERP consolidation, the data warehouse, the new front-office system, the intranet rebuild. Coloured dots mark where an initiative supports an objective. There is much satisfaction in the room when every objective turns out to have at least one dot beneath it. The matrix is laminated. It is pinned to the wall of the programme office. For a fortnight it is the most quoted document in the building.
By the following quarter it is quietly wrong. The acquisition has completed faster than expected and changed the integration priority. Two of the initiatives have been merged to save money; one has been paused because a vendor slipped. A new regulatory reporting obligation has arrived that no dot anticipated. The matrix on the wall still shows a tidy constellation of alignment. The business it describes has moved on.
Nobody re-laminates the matrix. That is the tell. We build the artefact as though alignment were a photograph to be taken once and framed, when the thing we are actually inside is a film that never stops running.
The failure is rarely that an organisation cannot achieve alignment. It is that alignment, once achieved, does not stay. We keep building instruments to certify a state, when the reality we inhabit is a process.
The Seduction of a Solved Problem
It would be unfair to treat the alignment orthodoxy as a straw man, because at its best it is genuinely intelligent. The strategic alignment thinking that has shaped a generation of CIO thinking made a real contribution: it insisted that technology strategy and business strategy are not two conversations but one, that infrastructure decisions have strategic consequences, and that the fit between external positioning and internal capability has to be managed in both directions. Anyone who lived through the era when IT was simply told what to build and blamed when it broke should be grateful for that correction. The models gave the CIO a language in which to claim a seat at the table, and the language mattered.
The strongest version of the case runs like this. Yes, the world changes — but that is exactly why you need a shared model of how technology serves the business, so that when the world changes you can re-plot your position quickly and deliberately rather than lurching. The matrix is not meant to be permanent; it is meant to be a common reference that makes re-planning fast. Abandon it and you are back to the bad old days of ungoverned, disconnected spending. This is a serious objection and it deserves a serious answer, because it is half right.
It is right that a shared reference is valuable and that the absence of one is worse than an imperfect one. Where it goes wrong is in its optimism about cost — the cost of keeping the reference true. The alignment models were built, largely, by people who study strategy, and they underweight the brute mechanics of the delivery floor: the speed at which a large systems-integration programme can actually turn, the tenacity of the incentives that pull business and IT apart, and the rate at which any written translation of intent goes stale. The orthodoxy is not wrong about the destination. It is wrong about whether there is a destination at all.
The Clockspeed Problem
Business strategy and technology capability move at different tempos, and the gap between those tempos is the first structural force pulling them apart.
A commercial strategy can turn in a quarter. A competitor moves, a market softens, an acquisition closes, and the leadership team re-points the organisation with a memo and a town hall. The cost of changing the statement of intent is close to zero. The cost of changing the capability is enormous. An ERP backbone commissioned to serve last year’s operating model cannot be re-pointed with a memo. It embodies a set of process decisions — how an order is taken, how a cost is allocated, how a ledger closes — that took eighteen months and a systems integrator’s small army to encode, and that will take comparable time and money to change.
So the business changes its mind at the speed of a slide deck and the technology changes its shape at the speed of a programme plan, and alignment is asked to hold a fixed relationship between two things travelling at different speeds. It cannot. By the time the capability catches up to the intent it was built for, the intent has moved again. This is not a symptom of a badly run IT function; a superbly run IT function experiences it just as sharply, sometimes more so, because it commits harder and therefore turns slower.
“The business changes its mind at the speed of a slide deck; the technology changes its shape at the speed of a programme plan. Alignment is asked to hold a fixed relationship between two things travelling at different speeds.”
The honest response to a clockspeed mismatch is not to demand that the slow thing move faster — the physics of a large integrated system will not allow it — nor to slow the fast thing down. It is to design the relationship so that it degrades gracefully: to build capability that assumes it will be re-pointed, and to make the re-pointing a planned event rather than a crisis.
Two Ledgers, Two Masters
The second force is quieter and more corrosive, because it operates through the incentive structure rather than through any visible decision.
Consider how the two sides are actually measured. The business unit leader is rewarded for the outcome — revenue booked, cost removed, the market share taken. The technology function, in most organisations of this era, is measured for the output and the input — the system delivered, the project on budget, the service level met, the unit cost of a desktop driven down. These are different ledgers. A programme can score perfectly on the technology ledger — delivered, on time, within budget, meeting every specified requirement — while contributing nothing to the business ledger, because the requirement it met so faithfully was the wrong requirement, or was right when it was written and wrong by the time it shipped.
I have watched a large front-office implementation be declared a triumph by the delivery organisation and a disappointment by the sales director in the same week, and both were telling the truth. The system did everything the specification asked. The specification asked for the wrong things, because it had been frozen eleven months earlier to protect the delivery timeline — and freezing the specification was, from the delivery ledger’s point of view, exactly the disciplined thing to do. Each side optimised its own ledger impeccably. The organisation still lost.
Alignment models tend to assume that a shared strategic picture will pull these ledgers together. It rarely does, because the ledgers are wired into how people are paid, promoted, and protected, and a laminated matrix on a wall is no match for a bonus scheme. So long as the business is accountable for outcomes and technology is accountable for outputs, the two will drift apart under load, and they will drift fastest exactly when the pressure is highest and each side retreats to defending its own ledger.
| Alignment as a state | Alignment as a standing condition |
|---|---|
| Certified once a year in a planning round | Re-negotiated continuously as intent moves |
| Owned by a steering committee | Owned jointly, at the level of outcomes |
| Measured by a matrix of dots | Measured by whether outcomes actually move |
| Artefact: the laminated plan | Artefact: the thin, frequently refreshed intent |
| Fails silently — the plan stays green | Fails loudly — the outcome is visibly off |
The Half-Life of a Blueprint
The third force is the one the models most consistently ignore: the artefacts through which business and technology communicate have a short and unforgiving half-life.
Intent has to be translated to travel. A strategy becomes a set of requirements; requirements become a functional specification; a specification becomes a technical design; a design becomes a build. At every step, meaning is compressed, encoded, and handed across a boundary — often a contractual boundary, when a systems integrator sits in the chain. Each translation is faithful on the day it is made. But each translation is also a snapshot, and the thing it photographed keeps moving. The requirements document is a photograph of what the business wanted in March. The technical design is a photograph of the requirements as understood in June. By the time the system is in test, the organisation is navigating by a stack of photographs, each one slightly out of date, the errors compounding down the chain.
This is why the thickest programmes are so often the most misaligned. A hundred-page requirements catalogue feels like rigour, and it is treated as an asset — the more complete, the safer. But completeness is precisely what dates fastest. A document that specifies everything is wrong about everything the moment the world turns, and its very heft makes it expensive to revise, so it is revised late, or not at all, and the delivery proceeds against a beautifully detailed account of a world that no longer exists.
The organisations that suffer least from this are not the ones with the best documents. They are the ones with the thinnest documents refreshed the most often — those who have understood, if only tacitly, that an artefact’s value lies not in its completeness but in its currency.
The Paradox That Should Have Warned Us
We have had a warning in plain sight for years, and we have mostly declined to read it. Economists spent the 1990s puzzling over why the vast sums poured into information technology were so hard to find in the productivity statistics. The debate ran in several directions — mismeasurement, lags, the difficulty of counting quality — but one strand of it points directly at our subject. Technology delivers value only when the organisation around it changes to exploit it, and that surrounding change is slower, harder, and less funded than the technology itself. An ERP system installed on top of unchanged processes is a very expensive way to do the old thing. The value was never in the alignment of the system to the strategy; it was in the alignment of the organisation to the new capability, and that second alignment is the one the matrix never captures.
Seen this way, the productivity paradox and the alignment illusion are the same phenomenon viewed from two ends. We kept measuring whether the technology fit the plan, and kept failing to measure whether the organisation had actually reorganised itself around what the technology made possible. The dots on the matrix connected initiatives to objectives. They said nothing about whether the humans had changed how they worked — and that, not the wiring diagram, is where alignment either lives or dies.
Alignment as a Verb
If alignment is a standing condition rather than a state, the practical programme changes in three concrete ways.
- Refresh the intent on the business’s clock, not the budget’s. The single point of shared reference — call it the intent, not the plan — should be deliberately thin and revisited on a short cycle: quarterly at the outside, and out of cycle whenever a material commercial decision lands. Its job is not to be complete but to be current. A one-page statement of the handful of outcomes that matter this quarter, honestly re-cut, is worth more than a forty-initiative matrix cut once a year.
- Move accountability to the outcome, jointly. As long as the business owns outcomes and technology owns outputs, the ledgers will diverge. The correction is to make a named business leader and a named technology leader jointly accountable for the same outcome — not the system delivered, but the cost actually removed or the revenue actually booked. Joint accountability for a shared number does more to hold alignment than any amount of shared documentation, because it re-wires the incentive that was pulling the two apart.
- Prefer thin, current artefacts to thick, complete ones. Every translation in the chain from strategy to build is a place where currency is lost. Shorten the chain, lighten each document, and refresh it often. Treat a requirements catalogue’s age, not merely its completeness, as a first-class risk. A specification frozen to protect a timeline is a decision to ship something that will be wrong on arrival; sometimes that trade is worth making, but it should be made with open eyes, not disguised as discipline.
None of this is free, and it is fair to name the cost. Thin artefacts refreshed often demand more of senior people’s attention than a matrix signed once and forgotten. Joint accountability is uncomfortable and politically hard to install. Governance that meets the business’s clock is more governance, more often. The alignment-as-state model was popular partly because it was cheap — it promised that a fixed annual ritual could stand in for continuous attention. That promise was the illusion. Continuous conditions require continuous attention, and there is no artefact that will buy an organisation out of paying it.
A Different Kind of Honesty
There is a version of this argument that curdles into cynicism — alignment is impossible, so stop trying — and it should be resisted, because it is not what the structural view implies. The structural view does not say the effort is wasted. It says the effort has been mislabelled. We have been selling a state and delivering, at best, a process, and the disappointment that follows is the disappointment of a promise mis-made rather than of work poorly done.
The more honest promise is smaller and more durable. Business and technology can be brought into step, repeatedly, for a while, at the cost of continuous negotiation — and the organisations that do this well are not the ones with the best models but the ones with the most stamina for the negotiation. They have stopped waiting for the year when everything will finally line up. They have accepted that the matrix will always be a little out of date, that the ledgers will always pull apart under load, that the documents will always be photographs of a world already moving. And having accepted it, they have built the modest, unglamorous machinery — the thin plan, the shared number, the short cycle — that lets them re-align faster than they fall out of step.
That is not a solved problem. It is a well-run one. In this domain, that is the most any of us should promise, and rather more than most of us deliver.