Walk into almost any modern engineering organisation and you will find the rituals in good order. Stand-ups happen. Sprints close. Retrospectives produce action items that mostly get done. By every visible measure the team is Agile. And yet the thing that was supposed to ship keeps arriving late, wrong, or technically fine but quietly off-target. The diagnosis is rarely the one written on the wall. It is not that the team cannot build. It is that product, architecture and engineering are not describing the same system.
This is the through-line of everything we write about delivery. Organisations do not fail because they cannot build software; they fail because they cannot consistently turn business intent into production outcomes. The scarce capability is the translation layer between strategy, product, architecture, engineering and operations. Agile, for all its merits, optimised one seam of that chain — the cadence of the engineering layer — and left the others to fend for themselves. Hence the modern complaint that has become almost a genre: we are Agile, but we are not aligned.
Method is not the differentiator; clarity of intent is
The evidence that process choice is overrated is older than most of the frameworks competing to own it. The long-running Standish CHAOS body of work has, for decades, attributed project success primarily to executive sponsorship, genuine user involvement and clear, well-defined objectives — not to whichever methodology happened to be in fashion. The framework is downstream of intent. You can run a flawless ceremony around a poorly understood goal and the ceremony will faithfully deliver the wrong thing on time.
Google's DORA programme sharpens this from the operational side. Its 2024 research found that unstable organisational priorities significantly reduce productivity and increase burnout — and, crucially, that this damage is 'highly resistant to mitigation'. It persists even where leadership is strong and documentation is excellent. Read that finding plainly: you cannot out-execute misaligned intent. No amount of engineering discipline downstream compensates for incoherence upstream. DORA's wider framing treats high-performing delivery as a socio-technical system in which performance depends on the alignment between technology, people and organisational goals, with shared purpose ranking above tooling as a predictor of outcomes.
The illusion of alignment
If misalignment is so costly, why is it so common? Because it is nearly invisible from the inside. A widely-cited Harvard Business Review study of more than 500 employees, managers and executives across a dozen companies found that respondents felt strategic agreement of roughly 82 per cent — while their actual descriptions of the strategy aligned only about 23 per cent. People are confident they agree, and they are wrong by a factor of three. This is the illusion of alignment, and product, architecture and engineering live inside it every day. Everyone leaves the kickoff nodding. Each then goes away and builds a faithful implementation of a different sentence.
This is also why most alignment initiatives are theatre. Another offsite, another mission statement, another scaling framework promising to harmonise value streams and programme increments — these increase coordination overhead without improving translation fidelity. They make the 82 per cent feel even more like consensus while the 23 per cent quietly stays put. Being Agile does not produce alignment, and it can mask its absence: independent survey work by Junade Ali and Engprax in 2024 documented Agile ceremony coexisting with poor requirements clarity, the familiar 'water-scrum-fall' in which the structure is relabelled but the Intent Translation never actually happens.
Structure quietly overrules architecture
There is a second mechanism that no methodology repairs. Conway's Law observes that systems come to mirror the communication structures of the organisations that build them. The practical, brutal corollary, well documented in the engineering literature, is that when the intended architecture and the organisational structure are at odds, the organisation wins. Your reporting lines, your team boundaries, your meeting topology — these will be encoded into the system whether or not anyone designed them to be. Thoughtworks' guidance on the Inverse Conway Maneuver follows directly: 'evolve your team and organisational structure to promote your desired architecture' (vendor framing), because aligning teams to the architecture you want is a precondition, not a finishing touch.
So alignment is not one problem. It is at least two that the literature usually treats separately: a strategy-to-IT problem the governance writers own, and a team-structure-to-architecture problem the socio-technical writers own. Nobody owns the middle. And the middle is where delivery actually happens.
Alignment as a three-way translation
Here is the field-note view. Alignment is a translation that must hold across three descriptions of the same system. Product states the intent — what we are trying to change in the world. Architecture is the executable model of that intent — the structural commitments that make it buildable and inspectable. Engineering is the running system — the intent made real. Misalignment is simply these three drifting until they describe different systems: product says one thing, architecture another, engineering builds a third. The discipline of delivery is keeping the translation faithful end to end.
Agile fixed the cadence of the engineering layer and left the seams between product, architecture and engineering un-owned. That is precisely why so many teams are Agile but not aligned.
This drift is not free. A 2024 systematic review by Ori and Szabo, covering 62 studies of business-IT strategy misalignment, catalogued its recurring effects: inefficient operations, redundant technology investment, delayed execution and lost stakeholder trust. The dominant root causes were depressingly consistent — siloed structure and the absence of a coherent, shared strategy. That is the academic confirmation of what every delivery lead already feels: misalignment is common, expensive and structural rather than personal.
Architecture is the under-served middle term
Of the three, architecture is the layer most teams skip and the one that matters most for alignment, because it is where intent becomes inspectable before it becomes code. Product intent is prose; running systems are facts; architecture is the bridge that lets you check, cheaply, whether the system you are about to build is the system you meant. Skip it and the first place product and engineering discover they disagreed is production. The genuine white space here is not more strategy decks or more team-topology diagrams — it is owning the architectural seam in the middle, the place where the two camps of the literature were supposed to meet and never did.
AI raises the stakes, it does not lower them
It is tempting to assume faster tools will paper over the cracks. The opposite is true. AI accelerates execution but does nothing to fix Intent Translation. It makes the engineering layer cheap and fast — which means a product-architecture misalignment now manifests as the wrong system generated three times faster. Cheap generation does not buy alignment; it raises the cost of not having it. And once generation is cheap, the binding constraint moves to acceptance: whether product, architecture and engineering even agree on what 'right' is. If they do not, you have simply industrialised the production of plausible, well-tested, beautifully shipped mistakes.
The action that follows is unglamorous and durable. Stop measuring whether you are Agile and start measuring whether your three descriptions match. Make architecture the explicit, owned translation layer that holds intent and implementation accountable to each other. Treat structure as a design input, not an accident, so that Conway's Law works for you rather than against you. Alignment is not a culture programme; it is a delivery discipline — the discipline of keeping product, architecture and engineering describing one system. For how that middle layer gets built and owned, read our piece on the missing layer between strategy and delivery, and on how architecture decisions quietly determine product success.