Evaluating architectural decisions and their organisational consequences

Managers rarely design systems, but they need to 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. Architecture and team design are therefore two views of one decision, and the most expensive architectural mistakes are organisational ones that nobody named. The competency is evaluating decisions rather than making them. That means weighing trade-offs and reversibility, spending deliberation on the one-way doors (data models, public contracts, core technology bets) while reversible choices move fast, and asking 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 for two reasons. A manager who rubber-stamps architecture without engaging with it has handed the shape of the organisation to whoever designed the system. And at scale, the platform's runway is a business-continuity question that arrives disguised as an engineering one. The examinations test it through a rewrite proposed on charisma, two teams building the same thing twice, an eighteen-month warning nobody can see, and principal engineers whose deadlock has become an executive problem.

1. Evaluate for trade-offs and reversibility, not elegance. Ask what the decision gives up and whether it can be undone. Scrutiny goes on the irreversible, and the reversible is allowed to 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? The whole posture is to be present in the design room without taking it over.
3. A team boundary and a system boundary are one decision. Design them together. Whichever one you leave undesigned will end up reshaping 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. They are 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. Before a from-scratch proposal is funded, the incremental alternative has to be explored in earnest.
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. It does not become 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

Conway observed in Melvin E. Conway, How Do Committees Invent? (1968) that a system's structure mirrors the communication structure of the organisation that built it. This unit uses the observation to evaluate designs. Any proposed architecture implies a coordination structure, so the manager asks who has to talk to whom because of the design, and whether the organisation is shaped to allow it. The practical corollary, designing the organisation to induce the architecture you want, is the design form covered in SV-6 Organisational design and leading change.

The mirroring hypothesis research

Alan MacCormack, Carliss Baldwin and John Rusnak, Exploring the Duality between Product and Organizational Architectures: The Mirroring Hypothesis (2012) tested Conway's observation empirically across paired software products. Products built by loosely coupled organisations were significantly more modular than functionally equivalent products built by tightly coupled ones. This 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 and not 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), used here to decide where architectural scrutiny goes. Data models, public contracts and core technology bets are one-way doors and 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, because "temporary" choices calcify, so a door is treated as one-way until shown otherwise.

The strangler pattern practice

Martin Fowler, StranglerFigApplication (2004) describes a way to replace a legacy system incrementally. New capability grows around the old system and routes traffic away from it piece by piece, until the old system can be retired. It is the standing alternative to the big-bang rewrite. Because the pattern exists, is well understood and lets reality vote early, a manager can demand that the incremental path be explored before a from-scratch proposal is funded.

Architecture review forums practice

A standing forum where significant designs get early scrutiny from other teams. It is most valuable when it advises, teaches and catches cross-team consequences, and least valuable as a gate every change must pass. Its provenance is ordinary practice. It fails by turning into a bottleneck and a rubber stamp as soon as it reviews everything, so its scope is limited to decisions with cross-team or irreversible consequences.

The three questions

In every significant design review the manager asks, in some form, what the design assumes, what happens when it fails, and who has to coordinate because of it. These are put as questions, not as objections. The answers improve the design; the manager's own design does not replace it.

The reversibility sort

Each design decision is labelled before it is made, as one-way or two-way. The team makes two-way decisions quickly and revisits them if they turn out wrong. One-way decisions get the deliberation, the review forum and the senior involvement. A team that gives every decision the same weight ends up slow on the trivial and careless on the irreversible.

The convergence decision

Sometimes two teams are about to build the same thing, or a cross-cutting choice such as a framework migration, a repository structure or a shared platform is being argued over. The manager then puts a decision in place, with criteria, the evidence required (a bounded pilot, a cost-benefit across every affected team), a named decider and a date. The organisation ends up with one solution or an explicit reason for two, and never with two by accident.

The consumer's protection

If a team wants to rewrite a service that other teams depend on, the manager makes sure those consumers are protected: a stable contract through the transition, a migration plan agreed with the dependent teams, and compatibility guarantees. Whether to rewrite is the owning team's decision. Keeping its consumers stable is the manager's.

The runway review

Once or twice a year, at executive scope, the platform's runway is checked against the business's growth assumptions. What breaks first under the planned load? How long does the fix take? What would it cost to start now compared with later? The result 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 how reversible they are, and the manager improves them through questions and restraint. At organisational scope it becomes architecture across autonomous teams, meaning standards at the boundaries, deliberate platform bets and cross-cutting decisions made once on evidence. Here the manager makes sure the organisation converges where convergence matters without personally approving every design. At executive scope the object is technical strategy. That covers bet-the-company decisions, the platform's runway treated as business risk, platform sprawl consolidated on de-politicised criteria, acquired systems integrated by explicit decision, and deadlocks between experts turned into decisions. How Judgment Scales sets out the pattern; 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 as well as 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 instead of gating. org
• Decides a department-wide migration on evidence (a bounded pilot, a cost-benefit across every team, criteria) and 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
• Makes sure a dependent team is protected through another team's rewrite with a stable contract, an agreed migration and compatibility guarantees. org
• Builds a shared platform for proven demand, meaning duplication pain across several teams, and not for speculative demand, 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, and 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 explored properly. 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, with objective criteria, honest migration accounting, clear ownership and respect for the people on the displaced platforms. exec
• Keeps technical coherence across acquisitions through explicit integration decisions instead of hoping for convergence. exec
• Converts a principal-engineer deadlock into a decision: frames the criteria, forces the honest comparison, and 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. Asking questions resolves this, because questions add considerations without removing ownership.

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

Deliberation versus speed. Scrutiny slows decisions down, and the irreversible ones deserve it. The reversibility sort lets the organisation move fast on most decisions and carefully on the few, instead of slowly on all of them.

Incremental versus clean. The strangler path takes longer to reach a clean end state, and it lets reality vote along the way. The rewrite promises a clean end state and usually arrives late, at a premium price, having re-learned the old system's lessons. The judgment is to insist the incremental path is explored honestly, and to fund the rewrite only when that exploration has failed in earnest.

Visible versus invisible risk. Customers see features. They do not see the platform's runway, and the business funds what it sees. At scope, the manager's job is to make the invisible risk visible in business terms before it turns into a visible outage.

In a one-on-one, a principal engineer tells a head of engineering that the core data platform will not scale past roughly eighteen months of the company's planned growth. Fixing it means re-architecting the storage and event layers. The work would run for several quarters, involve four teams and be entirely invisible to customers. The product organisation has a full roadmap, and the board has been shown growth targets that assume the platform will keep working. The principal engineer has raised this twice before with their own manager, who filed it as technical debt.

There are two easy responses. One is to file it again, since nothing is broken and customers cannot see it. The other is to panic and 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 a claim nobody has validated.

The head of engineering handles it as a strategic risk decision. The first step is validation. They ask the principal engineer and two others to produce the evidence within two weeks (the load model, what breaks first, at what growth, and how confident they are) and they read it themselves instead of accepting a summary. The claim holds, with a range of somewhere between fourteen and twenty months. The second step is sizing, and three options are costed. A full re-architecture now would take three quarters and displace two roadmap initiatives. A staged version would replace the event layer first, buying an estimated year of runway, and defer the storage work to a second stage with a checkpoint. A targeted set of mitigations would buy six months and no more. In the third step the decision goes where it belongs, to the executive table. It is framed as business continuity, since the growth plan the board has seen depends on a platform that will not carry it, and it arrives with the three options, their cost 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. Ownership of the event layer will move, so the four teams' boundaries are examined against the new architecture; a team boundary and a system boundary are one decision. The principal engineer is asked to lead the technical design, and an architecture forum reviews the one-way doors.

The head of engineering avoids both of the moves that would have felt like management: leaving the warning in the backlog because it was invisible, and deciding the architecture personally.

• 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

   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 bring in considerations the designers may not see, without taking the design away 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, with criteria, evidence, a decider and a date, so the organisation gets one solution or an explicit reason for two. Abdicating looks like letting parallel enthusiasm decide and then 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, which 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 call made against criteria. Advocacy, seniority and who argues longest do not decide it.
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 has committed to depends on the platform carrying it, so the risk is to business continuity. It is validated, sized into staged options with their roadmap costs, and decided at the executive table. It is neither buried because customers cannot see it nor panic-committed on the back of 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 explored properly 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.