In our previous lesson, we explored the fundamental shift in the software architect's role from a centralized gatekeeper to a distributed enabler. This new model emphasizes empowering teams to make their own decisions to increase development velocity and foster ownership. However, this immediately raises a critical question: If everyone is making decisions, how do we prevent chaos?
This lesson addresses that very question and its corresponding learning outcome: distinguishing between architectural decisions that require centralized authority and those that can be delegated to teams. We will introduce a powerful mental model used by leaders at companies like Amazon to create clear boundaries for decision-making. This framework will help you not only classify decisions but also think strategically about how to design systems and organizations that enable greater autonomy.
The Core Framework: One-Way vs. Two-Way Doors
The most effective way to categorize decisions is by their reversibility. Some decisions are easy to undo, while others set you on a path that is nearly impossible to leave. This concept is famously articulated by Jeff Bezos as "one-way" and "two-way" doors.
To hear the idea from its source, let's watch a short clip of Bezos explaining it.
Jeff Bezos on how to make decisions | Lex Fridman Podcast Clips
Please watch this segment from the "Lex Fridman Podcast Clips" channel featuring Jeff Bezos.
Pay close attention to his definitions. He describes one-way doors as consequential and irreversible decisions that must be made slowly and deliberately. In contrast, two-way doors are reversible and should be made quickly by individuals or small teams deep within the organization. He explicitly notes that one-way door decisions should be elevated to the most senior executives.
As Bezos points out, a common organizational failure is using the heavyweight, "one-way door" process for all decisions. This leads to slowness, risk aversion, and stifles innovation—precisely the problems the modern, enabling architect seeks to solve. Your role is to ensure the right process is applied to the right decision.
To build on this, let's explore a detailed article that applies this framework directly to software engineering.
Decisions: One-way and two-way doors - James Warrick
This article by James Warrick provides a clear breakdown of the one-way vs. two-way door concept in the context of technology choices.
Please read the introduction, which quotes Bezos and sets the stage. Then, read the section that discusses the organizational trap of applying one process to all decisions. Finally, review the concrete examples under the headings for different types of decisions. Notice how the author categorizes choices like cloud providers, database technologies, and software architecture. This provides an excellent practical reference for what might fall into each bucket.
This distinction gives us a clear principle:
- Decisions with irreversible or high-cost consequences (One-Way Doors) require centralized authority.
- Decisions with reversible, low-cost consequences (Two-Way Doors) should be delegated to autonomous teams.
The image below offers a simple visual contrast between the two models of decision-making that correspond to these two types of doors. The hierarchical structure is suited for slow, deliberate, one-way door decisions, while the networked structure is ideal for fast, delegated, two-way door decisions.
Defining the Boundary: The Cost of Change
The "one-way door" concept is powerful, but "reversibility" exists on a spectrum. A decision is rarely truly irreversible; rather, its reversal comes with a cost. This "cost of change" is the critical factor that distinguishes a simple design decision from a significant architectural one.
Software Design Is NOT Software Architecture (& That’s A Good Thing!)
Let's watch a clip from Dave Farley, a respected voice in software engineering, who defines architecture through this lens.
In this video, he quotes Grady Booch's definition of architecture as the significant design decisions where significance is measured by the cost of change. He describes a continuum with cheap-to-change decisions on one end (design) and expensive-to-change decisions on the other (architecture).
This gives us a more formal way to evaluate decisions. When faced with a choice, you should ask: What is the true cost of being wrong? This cost can be measured along several axes:
- Time and Effort: How many person-months would it take to reverse this? Is it a quick refactor within a single service, or a year-long migration project affecting dozens of teams?
- Financial Cost: Does this decision involve significant licensing fees, long-term vendor contracts, or require hiring expensive, specialized talent?
- Organizational Impact: How wide is the blast radius? Does it affect a single team's codebase, or does it change how every team in the organization deploys, monitors, or secures their software?
Let's apply this thinking to the examples from the Warrick article. The choice of PostgreSQL as a primary database was considered a near one-way door because migrating an entire company's data and application logic to a different database technology is a project of enormous time, effort, and risk. In contrast, refactoring the internal code structure of a single application is a two-way door, as modern IDEs and practices make this a low-cost, routine activity.
A Practical Model for Delegation
With this framework in mind, we can map decision authority to the structure of the system itself. The article "Architecting Autonomy at Scale," which we reviewed in the last lesson, provides a useful model for this.
Architecting Autonomy at Scale: Raising Teams without Creating ...
Let's return to this article to see how decision boundaries can be formally defined.
Please read the section titled "Decision boundaries." The author proposes aligning architectural authority with levels of abstraction, using the C4 model as an example.
This approach creates clarity. We can synthesize the one-way/two-way door concept with this C4-aligned model to produce a practical guide for delegation.
| Architectural Scope | Decision Type | Example Decisions | Typical Owner |
|---|---|---|---|
| System Context | One-Way Door | Choice of primary cloud provider (e.g., AWS vs. GCP); selecting the main architectural style (e.g., monolith vs. microservices); compliance standards (e.g., PCI, HIPAA). | Enterprise Architect, CTO, Governance Forum |
| Containers (Services) | Mixed | Communication protocol between services (e.g., REST vs. gRPC); choice of database for a new service; technology stack for a new service. | Solution/Senior Architect, Domain Lead |
| Components | Mostly Two-Way Door | Internal library choices for a service; major refactoring within a service; API design for an internal component. | Team Tech Lead, Development Team |
| Code | Two-Way Door | Class structure; function signatures; variable naming; implementation of an algorithm. | Individual Developer |
This table serves as a starting point. The key is not to follow it rigidly, but to use it as a tool to facilitate conversations about ownership and responsibility.
The Strategic Goal: Make More Doors Two-Way
So far, we have focused on classifying decisions as they are. However, the ultimate goal of an enabling architect is not just to manage one-way doors, but to actively eliminate them. A well-architected system is one where the cost of change is low, allowing more decisions to be delegated safely.
How is this achieved? The Dave Farley video (LINK) gave us the answer:
- Modularity: Designing well-defined components with clear, stable interfaces (APIs) minimizes the blast radius of changes. A change inside one module doesn't unexpectedly break another.
- Automated Testing: A comprehensive and fast test suite provides a safety net, making the impact of any change immediately visible. This dramatically lowers the risk and, therefore, the cost of reversing a decision.
- Refactoring Skills: When teams are skilled at safely restructuring code, what might seem like a scary, high-cost change becomes a routine improvement.
As an architect, your strategic focus shifts to investing in these capabilities. By championing robust testing practices, promoting good modular design through coaching, and providing teams with the tools and time for refactoring, you structurally reduce the number of "one-way door" decisions in your organization. This is the essence of enabling autonomy at scale.
Conclusion
In this lesson, we established a robust framework for determining which architectural decisions can be delegated and which require centralized authority.
Key Takeaways:
- The one-way vs. two-way door model provides a powerful lens for classifying decisions based on their reversibility and cost of change.
- One-way door decisions (architectural) are costly to reverse and require slow, deliberate, centralized approval to mitigate risk.
- Two-way door decisions (design) are cheap to reverse and should be delegated to individuals and teams to maximize velocity and autonomy.
- The architect's role is to ensure the appropriate decision-making process is used for each type and to align authority with the scope of impact (e.g., using the C4 model).
- Strategically, the goal is to make more doors two-way by investing in modularity, automated testing, and team refactoring skills, thus enabling greater autonomy.
Preview of the Next Lesson:
We now have a model for the modern architect's role (enabler) and a framework for distributing decisions (one-way/two-way doors). In the next lesson, we will explore how this all comes together in practice. We will move beyond thinking of architecture as a phase and learn to see it as a continuous activity embedded in the development process, a perspective that is essential for building truly evolutionary systems.