Evaluating architectural decisions and their organisational consequences

Managers rarely design systems, but they must be in the room when systems are designed, because architecture has organisational consequences that outlast any release. Systems mirror the communication structures of the organisations that build them, so architecture and team design are two views of one decision, and the most expensive architectural mistakes are the ones that were really organisational mistakes nobody named. The competency is evaluating decisions rather than making them: weighing trade-offs and reversibility, spending deliberation on the one-way doors — data models, public contracts, core technology bets — and letting reversible choices move fast, and contributing the questions a manager is uniquely placed to ask: what does this assume, what happens when it fails, who has to coordinate because of this. It matters because a manager who rubber-stamps architecture they do not engage with has delegated the organisation's shape to whoever designed the system, and because at scale the platform's runway is a business-continuity question that arrives disguised as an engineering one. The examinations test it through the rewrite proposed on charisma, the two teams building the same thing twice, the eighteen-month warning nobody can see, and the principal engineers whose deadlock has become an executive problem.

1. Evaluate for trade-offs and reversibility, not elegance. The question is what this decision gives up, and whether it can be undone. Spend scrutiny on the irreversible and let the reversible move.
2. Ask the questions only a manager will ask. What does this assume? What happens when it fails? Who has to coordinate because of this? Presence in the design room without taking it over is the whole posture.
3. A team boundary and a system boundary are one decision. Design them together, or the one you did not design will reshape the other.
4. Converge deliberately where convergence matters. Across autonomous teams, standards live at the boundaries and cross-cutting decisions are made once, on evidence, by a named process — not left to whoever argues longest or to parallel enthusiasm.
5. Prefer the incremental path to the rewrite. Big-bang rewrites are how organisations re-learn old lessons at premium prices. The incremental alternative is genuinely explored before a from-scratch proposal is funded.
6. Treat platform runway as business risk. A warning that the core platform will not scale past the next eighteen months is a strategic decision to be validated, sized and staged at the executive table, not a backlog item because customers cannot see it.

Architecture has one of the few empirically tested organisational claims in this standard, and the unit grades it as research.

Conway's law practice

The observation in Melvin E. Conway, How Do Committees Invent? (1968) that a system's structure mirrors the communication structure of the organisation that built it. In this unit its use is evaluative: any proposed architecture implies a coordination structure, and the manager's question is who has to talk to whom because of this design, and whether the organisation is shaped to allow it. Its practical corollary, designing the organisation to induce the architecture wanted, is the design form treated in SV-6 Organisational design and leading change.

The mirroring hypothesis research

The empirical test in Alan MacCormack, Carliss Baldwin and John Rusnak, Exploring the Duality between Product and Organizational Architectures: The Mirroring Hypothesis (2012) of Conway's observation across paired software products, finding that products built by loosely coupled organisations were significantly more modular than functionally equivalent products built by tightly coupled ones. It is the evidence that the correlation Conway described is real and large, and it is why this standard treats the team boundary and the system boundary as one decision rather than as a metaphor.

One-way and two-way doors practice

Jeff Bezos's classification in Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016), applied here to the allocation of architectural scrutiny: data models, public contracts and core technology bets are one-way doors that deserve deliberation and senior involvement; most other decisions are reversible and should be made quickly by the people closest to them. Reversibility is often misjudged — "temporary" choices calcify — so a door is treated as one-way until shown otherwise.

The strangler pattern practice

The approach described in Martin Fowler, StranglerFigApplication (2004) for replacing a legacy system incrementally: new capability grows around the old system, routing traffic away from it piece by piece, until the old system can be retired. It is the standing alternative to the big-bang rewrite, and the reason a manager can demand that the incremental path be explored before funding a from-scratch proposal: the pattern exists, it is well understood, and it lets reality vote early.

Architecture review forums practice

A standing forum where significant designs get cross-team scrutiny early. Most valuable when it advises, teaches and catches cross-team consequences; least valuable as a gate every change must pass. Its provenance is ordinary practice; its failure is becoming a bottleneck and a rubber stamp the moment it reviews everything, so it is scoped to decisions with cross-team or irreversible consequences.

The three questions

In every significant design review the manager asks, in some form: what does this assume, what happens when it fails, and who has to coordinate because of this. They are asked as questions and not as objections, and the design is improved by the answers rather than replaced by the manager's.

The reversibility sort

Before a design decision is made, it is labelled: one-way or two-way. Two-way decisions are made by the team, quickly, and revisited if wrong. One-way decisions get the deliberation, the review forum and the senior involvement. A team that treats every decision as equally weighty is slow on the trivial and careless on the irreversible.

The convergence decision

When two teams are about to build the same thing, or a cross-cutting choice — a framework migration, a repository structure, a shared platform — is being argued, the manager installs a decision: the criteria, the evidence required (a bounded pilot, a cost-benefit across every affected team), who decides, and by when. The organisation gets one solution or an explicit reason for two; it does not get an accident.

The consumer's protection

When a team wants to rewrite a service other teams depend on, what the manager ensures is the consumers' protection: a stable contract through the transition, a migration plan agreed with the dependent teams, and compatibility guarantees. The rewrite is the owning team's decision; its consumers' stability is the manager's.

The runway review

At executive scope, once or twice a year, the platform's runway is examined against the business's growth assumptions: what breaks first under the plan's load, how long the fix takes, and what it would cost to start now against later. The output goes to the executive table as a business-continuity decision with staged options.

At team scope the object is one team's design decisions and their reversibility, and the manager improves them through questions and restraint. At organisational scope the object becomes architecture across autonomous teams — standards at the boundaries, deliberate platform bets, cross-cutting decisions made once on evidence — and the manager ensures the organisation converges where convergence matters without personally approving every design. At executive scope the object is the technical strategy: the bet-the-company decisions, the platform's runway treated as business risk, platform sprawl consolidated by de-politicised criteria, acquired systems integrated by explicit decision, and expert deadlocks converted into decisions. The pattern is in How Judgment Scales; designing the organisation to induce the architecture is SV-6 Organisational design and leading change.

• Is present for major design decisions and improves them through questions, without taking them over. team
• Weighs organisational and long-term consequences, not only elegance. team
• Spends scrutiny on the irreversible and lets reversible decisions move. team
• Sees a team boundary and a system boundary as one decision.
• Failure mode — rubber-stamping architecture you do not engage with. team
• Failure mode — over-indexing on elegance while ignoring coordination cost. team
• Failure mode — treating all decisions as equally weighty. team
• Keeps architecture coherent across autonomous teams through standards at the boundaries and a review forum that advises and teaches rather than gates. org
• Decides a department-wide migration on evidence — a bounded pilot, a cost-benefit across every team, criteria — not on advocacy or seniority. org
• Forces one deliberate decision when two teams are building the same thing. org
• Sets the criteria, evidence and decider for a cross-cutting choice such as a monorepo, and makes the department-level call. org
• Ensures a dependent team's protection through another team's rewrite: stable contract, agreed migration, compatibility guarantees. org
• Builds a shared platform for proven demand — duplication pain across several teams — not for a speculative one, with ongoing ownership costed. org
• Failure mode — approving everything, which is a bottleneck, or nothing, which is drift. org
• Failure mode — letting parallel teams build the same thing twice. org
• Failure mode — a review board that gatekeeps instead of teaching. org
• Failure mode — platformising a guess. org
• Treats a principal engineer's eighteen-month platform warning as a strategic risk: validates it, sizes the bet, takes it to the executive table with staged options. exec
• Answers a from-scratch rewrite proposal with deep scepticism expressed as a demand for evidence and for the incremental alternative to be genuinely explored. exec
• Stages bet-the-company technical decisions so reality can vote early, sizes the downside for survivability, and gives the biggest bets the most scrutiny. exec
• Consolidates platform sprawl by de-politicising the decision: objective criteria, honest migration accounting, clear ownership, respect for the displaced platforms' people. exec
• Keeps technical coherence across acquisitions through explicit integration decisions rather than hoped-for convergence. exec
• Converts a principal-engineer deadlock into a decision: frames the criteria, forces the honest comparison, decides or explicitly delegates. exec
• Failure mode — discounting the eighteen-month warning because customers cannot see it. exec
• Failure mode — funding a from-scratch rewrite on architectural charisma. exec
• Failure mode — letting five platforms live because each has a sponsor. exec
• Failure mode — waiting out a principal-engineer stalemate. exec

Presence versus ownership. A manager in the design room improves the design; a manager who decides the design has taken it from the people who will live with it. The questions are the resolution: they add considerations without removing ownership.

Coherence versus autonomy. Standards at every layer produce uniformity that mostly serves dashboards; no standards produce five platforms and duplicated services. The line is the boundary: converge where teams meet, leave the inside to the team.

Deliberation versus speed. Scrutiny slows decisions, and the irreversible ones deserve it. The reversibility sort is what lets the organisation be fast on most decisions and careful on the few, instead of uniformly slow.

Incremental versus clean. The strangler path is slower to a clean end state and lets reality vote; the rewrite promises a clean end state and usually arrives late, at premium price, having re-learned the old system's lessons. The judgment is to demand the incremental path be explored honestly, and to fund the rewrite only when that exploration has genuinely failed.

Visible versus invisible risk. Customers see features and do not see the platform's runway; the business funds what it sees. The manager's job at scope is to make the invisible risk visible in business terms before it becomes a visible outage.

A head of engineering is told by a principal engineer, in a one-on-one, that the core data platform will not scale past roughly eighteen months of the company's planned growth. The fix is a re-architecture of the storage and event layers: multi-quarter, involving four teams, and entirely invisible to customers. The product organisation has a full roadmap, the board has been shown growth targets that assume the platform simply works, and the principal engineer has raised this twice before to their own manager, who filed it as technical debt.

The two easy responses are to file it again, because nothing is broken and customers cannot see it, or to panic-commit the organisation to a re-architecture on the strength of one conversation. The first accepts an existential risk by default; the second bets four teams on an unvalidated claim.

The head of engineering treats it as a strategic risk decision. First, validation: they ask the principal engineer and two others to produce the evidence — the load model, what breaks first, at what growth, and how confident they are — within two weeks, and they read it themselves rather than accepting a summary. The claim holds, with a range: somewhere between fourteen and twenty months. Second, sizing: three options are costed. A full re-architecture now, over three quarters, at the expense of two roadmap initiatives. A staged version that replaces the event layer first, buying an estimated year of runway, and defers the storage work to a second stage with a checkpoint. Or a targeted set of mitigations that buy six months and no more. Third, the decision is taken where it belongs: to the executive table, framed as business continuity — the growth plan the board has seen depends on a platform that will not carry it — with the three options, their costs to the roadmap, and a recommendation for the staged path.

The executive team chooses the staged path and the two roadmap initiatives it displaces are named explicitly. The head of engineering then does the organisational half of the decision: the four teams' boundaries are examined against the new architecture, because the event layer's ownership will move, and a team boundary and a system boundary are one decision. The principal engineer is asked to lead the technical design, with an architecture forum reviewing the one-way doors.

What the head of engineering does not do is either of the things that would have felt like management: leaving the warning in the backlog because it was invisible, or deciding the architecture themselves.

• SV-6 Organisational design and leading change — designing the organisation to induce the architecture; the inverse of this unit's evaluation.
• TJ-2 Technical debt — technical debt and systemic risk as the accumulated cost of architectural decisions.
• TJ-4 Technical credibility and intervention — knowing which architectural decisions are yours and staying close enough to judge them.
• DE-4 Managing scope, risk, and dependencies across workstreams — the coordination cost and boundary friction an architecture creates.
• SV-4 Engineering economics — the economics of a platform bet and the build, buy or partner decision behind it.

1. Why focus architectural scrutiny on reversibility?
   Answer

   Because deliberation is expensive and most decisions can be undone cheaply. Spending it on the one-way doors — data models, public contracts, core technology bets — and letting the two-way doors move keeps the organisation fast on most decisions and careful on the few that matter.
2. What are the three questions a manager is uniquely placed to ask in a design review?
   Answer

   What does this assume? What happens when it fails? Who has to coordinate because of this? They add considerations the designers may not see, without taking the design from them.
3. Two teams are building duplicate services for the same problem. What exactly is your role, and what would abdicating it look like? org
   Answer

   To force one deliberate decision — criteria, evidence, a decider, a date — so the organisation gets one solution or an explicit reason for two. Abdicating looks like letting parallel enthusiasm decide, and discovering two services in production.
4. What does the mirroring hypothesis add to Conway's law?
   Answer

   Empirical evidence: products built by loosely coupled organisations were measurably more modular than equivalent products built by tightly coupled ones. It turns an observation into a finding, and a metaphor into a design rule.
5. A senior engineer proposes a department-wide framework migration costing three weeks per team; your managers are split. How is it decided? org
   Answer

   On evidence: a bounded pilot, an explicit cost-benefit across all the affected teams, and a criteria-based call. Not on advocacy, seniority, or who argues longest.
6. A principal engineer says the platform dies in eighteen months. What makes your handling of this a strategy question rather than a backlog question? exec
   Answer

   The growth plan the business is committed to depends on the platform carrying it, so the risk is business continuity. It is validated, sized into staged options with their roadmap costs, and decided at the executive table — neither buried because customers cannot see it nor panic-committed on one conversation.
7. A respected architect proposes rewriting a large part of the core systems from scratch. What is the seasoned response? exec
   Answer

   Deep scepticism expressed as a demand for evidence and for the incremental alternative — the strangler path — to be genuinely explored first. Big-bang rewrites are how organisations re-learn old lessons at premium prices.

• Melvin E. Conway, How Do Committees Invent? (1968) — systems mirror the organisations that build them.
• Alan MacCormack, Carliss Baldwin and John Rusnak, Exploring the Duality between Product and Organizational Architectures: The Mirroring Hypothesis (2012) — the mirroring hypothesis tested empirically.
• Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016) — one-way and two-way doors.
• Martin Fowler, StranglerFigApplication (2004) — the strangler pattern for incremental replacement.