Making architecture decisions quickly without creating irreversible technical debt is the challenge facing technical leaders. The difference between reversible and irreversible decisions determines not only your system’s evolution capacity but also your team’s velocity and competitive advantage. Amazon’s Type 1 and Type 2 decision framework provides the classification system that transforms decision-making from art to science, enabling faster choices for reversible decisions while ensuring proper governance for irreversible ones. This framework helps you optimise decision velocity, manage technical debt implications, and recover from wrong choices. Whether evaluating build vs buy decisions or managing the last responsible moment principle, understanding decision reversibility is essential for strategic technical leadership. For a comprehensive overview of all architecture decision frameworks, see our complete guide to software architecture decision frameworks.
What is the difference between reversible and irreversible architecture decisions?
Reversible decisions (Type 2) can be changed or undone with minimal cost and impact, enabling experimentation and rapid iteration. Irreversible decisions (Type 1) have permanent or high-cost consequences that are difficult to reverse, requiring thorough analysis and governance oversight due to their long-term impact on system architecture.
Jeff Bezos famously distinguished between “Type 1” and “Type 2” decisions, where Type 1 are irreversible decisions that he likened to “one-way doors.” As Ben Morris explains, “This is basic risk management: the more consequential and irreversible the decision, the more care you should take in making it.”
The challenge is that apparently reversible decisions can become more consequential than expected. What starts as a simple technology choice can become entrenched through system dependencies, team expertise, and integration complexity.
Key characteristics of reversible decisions:
- Low switching costs and minimal system impact
- Isolated to single teams or components
- Quick feedback loops enable course correction
- Alternative options remain available
Key characteristics of irreversible decisions:
- High reversal costs due to system-wide impact
- Create permanent constraints on future choices
- Affect multiple teams and system boundaries
- Require extensive planning and stakeholder alignment
You can manage risk by making changes smaller and getting feedback more quickly, making it easier to reverse out of decisions that aren’t panning out. Constraints can even enable innovation by creating “guard rails” for engineering teams.
The catch is that it’s not always easy to spot a consequential decision until it’s too late. This is why Amazon’s framework is so valuable – it provides systematic criteria for classification before you’re locked into a path.
How do I classify architecture decisions using the Type 1 and Type 2 framework?
Type 1 decisions are irreversible “one-way doors” requiring careful analysis, while Type 2 decisions are reversible “two-way doors” where speed matters more than perfection. Classification depends on reversal cost, implementation complexity, system impact, and time requirements for changing course once implemented.
The Amazon one-way vs two-way door metaphor provides the foundational framework:
- One-way doors (Type 1): Once you walk through, you can’t easily go back. These require careful consideration, stakeholder alignment, and thorough analysis.
- Two-way doors (Type 2): You can walk through, look around, and return if needed. These benefit from speed over perfection.
Classification criteria include:
Reversal Cost Assessment:
- What’s the financial impact of changing course?
- How much development time would reversal require?
- What opportunity costs result from the switch?
Implementation Complexity:
- How many teams and systems are affected?
- What integration points need modification?
- How deeply embedded will the decision become?
System Impact Scope:
- Does impact remain within team boundaries?
- Are external APIs or contracts affected?
- Will the decision constrain future architectural evolution?
If the impact of a decision is limited to an individual engineering team, then potential problems tend to be smaller and more manageable. As Ben Morris notes, “Again, this is driven by risk management” – architects should only get involved in decisions where the impact will be felt beyond the team’s boundaries.
Practical classification: Assess the blast radius, estimate switching costs, evaluate constraint creation, and consider expertise requirements. To document these decisions effectively, Architecture Decision Records should capture this classification rationale.
When should I apply the last responsible moment principle to architecture decisions?
The last responsible moment principle delays decisions until maximum information is available while still allowing effective implementation. Apply this to Type 2 decisions where additional information significantly reduces risk, but avoid it for Type 1 decisions requiring extensive planning and stakeholder alignment.
Mary and Tom Poppendieck identified the “last responsible moment” as a guiding principle for decision making, defined as that point at which “failing to make a decision eliminates an important alternative.”
When to apply the principle:
For Type 2 decisions, delay when additional information will significantly reduce uncertainty and when alternative options remain viable. Avoid for Type 1 decisions when extensive planning and stakeholder alignment are required or when delay increases overall project risk.
One problem with the “last responsible moment” is that it’s often difficult to recognise when that moment has arrived. It can also become an excuse for procrastination, as there is never a golden moment where the clouds part to reveal the perfect decision.
Too many open decisions create mental clutter that can impede progress. As Ben Morris warns, “There are always trade-offs and there is always uncertainty, so decision making requires a degree of courage.”
Practical implementation strategies:
Define specific information that would change your decision, set deadlines for when that information must be available, and establish fallback options if information isn’t forthcoming.
Don’t let analysis paralysis prevent forward progress – engineering teams thrive on certainty, so rule out options decisively when needed.
How do I evaluate build vs buy decisions through the reversibility lens?
Build vs buy decisions should prioritise reversibility assessment over feature comparison. Custom builds typically create irreversible decisions due to maintenance overhead and switching costs, while third-party solutions often enable reversible decisions through vendor switching and integration flexibility, though lock-in risks must be evaluated.
Build decisions typically create irreversible situations through maintenance overhead, custom expertise dependencies, and architectural constraints. Buy decisions often enable reversible situations through vendor switching, external innovation, and competitive market pressure.
Key evaluation questions from AKF Partners:
- Does this create strategic differentiation? If building will distract from focusing efforts on the next “big thing” then 99% of the time you should find a packaged product, open-source solution, or outsourcing vendor.
- Are we the best company to build this? This helps inform whether you can effectively build it and achieve the value you need.
- Can we build this cost effectively? Many companies miss the key points of how much it costs to maintain a proprietary solution.
- Do competing products exist? More options typically mean more reversible decisions.
As Pete Ferguson notes, “Your job is to create shareholder value – not work on ‘neat things’ – unless your ‘neat thing’ creates shareholder value.”
Assess vendor lock-in by evaluating API dependencies, data portability, integration complexity, and contract flexibility for termination and transition.
A “build” decision is indicated when the answers to all four questions are “Yes”: strategic differentiation, best positioned to build, few competing products, cost effective. Consider buying or outsourcing anytime you answer “No” to any of the four key questions.
Building provides maximum control but longest time-to-value and highest Type 1 decision risk. Buying provides fastest time-to-market with higher reversibility but potentially less control over roadmap and features.
How do architecture decisions create and manage technical debt?
Irreversible decisions create permanent technical debt through system constraints and evolution limitations, while reversible decisions enable debt management through iterative improvement. Understanding debt implications helps prioritise decision thoroughness and plan future refactoring investments based on reversibility potential.
Technical debt results from prioritising speed over quality, where shortcuts seem beneficial short-term but significantly impact reliability.
Type 1 decisions create permanent debt through system-wide constraints, limited evolution paths, and unchangeable dependencies. These include major decomposition decisions that fundamentally alter system architecture. Type 2 decisions enable debt management through iterative improvements, reversible experiments, and addressable shortcuts.
Ward Cunningham warns that unpaid technical debt creates interest that can bring “entire engineering organisations to a stand-still.”
Type 1 decisions require heavy upfront design investment to minimise debt creation and planning for evolutionary capacity within constraints. Type 2 decisions can accept tactical debt for learning and speed, with regular debt assessment and iterative improvement to address shortcuts.
McKinsey reports that “Poor management of tech debt hamstrings companies’ ability to compete,” making debt management important for organisational competitiveness.
What strategies optimise decision velocity without increasing risk?
Decision velocity optimisation focuses on faster execution for Type 2 decisions through reduced governance overhead and increased team autonomy, while maintaining thorough analysis for Type 1 decisions. Implement parallel information gathering, proof of concept development, and delegation frameworks based on reversibility classification.
For Type 2 decisions, reduce governance overhead, increase team autonomy for isolated decisions, enable rapid experimentation with rollback safety nets, and use time-boxing to prevent analysis paralysis. For Type 1 decisions, maintain thorough analysis but parallelise information gathering, use proof of concepts to reduce uncertainty, and establish clear escalation paths.
Enable team autonomy for task-level decisions to increase creativity and efficiency. Define clear decision boundaries, create lightweight approval processes for reversible decisions, and use Architecture Decision Records to document rationale.
Run technical spikes concurrently, gather stakeholder input while analysing options, and prepare rollback strategies during implementation. Establish timeout values, fallback mechanisms, and use feature flags for rapid rollback.
How do I recover from wrong architecture decisions?
Recovery strategies depend on decision reversibility: Type 2 decisions enable quick pivots through rollback strategies and alternative implementation, while Type 1 decisions require systematic recovery planning including strangler fig patterns, gradual migration, and technical debt remediation with longer timelines and resource investment.
Type 2 decisions enable quick pivots using prepared rollback strategies and alternative implementation with minimal system impact. Type 1 decisions require systematic recovery planning with longer timelines, strangler fig patterns for gradual replacement, and migration strategies that minimise business disruption.
Each time you reroute functionality to the new system, you should have a rollback plan. Feature flags enable the facade to switch between systems quickly if problems are found.
Migration patterns for irreversible decision correction:
Strangler Fig Pattern gradually replaces old system functionality by routing traffic selectively to new implementations while maintaining parallel systems during transition.
Establish fallback mechanisms with graceful degradation and implement multiple layers of resilience.
Type 1 decision recovery requires significant investment in development resources and operations overhead.
How do I balance decision thoroughness with organisational agility?
Balance thoroughness with agility by matching analysis depth to decision reversibility: invest heavily in Type 1 decision analysis while accelerating Type 2 decisions through lightweight processes. Implement decision checkpoints for course correction and maintain organisational learning cycles to improve classification accuracy over time. For more detailed guidance on implementing these practices, explore our architecture decision frameworks guide.
Type 1 decisions require heavy investment in upfront analysis, formal architecture review processes, and comprehensive impact assessments. This thorough approach aligns with broader strategic frameworks for architecture governance. Type 2 decisions benefit from lightweight analysis focused on learning opportunities, rapid experimentation with safety nets, and delegated decision authority.
Take a collaborative and inclusive approach to decision making to encourage buy-in. Building a community of natural leaders is vital for establishing consensus.
Implement quarterly reviews for Type 2 decisions, annual reviews for Type 1 decisions, trigger-based evaluation for significant changes, and continuous monitoring of decision impact.
So long as decisions are made on an inclusive basis and reasons are clearly articulated, any conflict around them is usually manageable. As Ben Morris notes, “Some conflict is inevitable, but that shouldn’t make you shy away from making decisions.”
Architecture Decision Records enable teams to grasp decision reasoning and reach consensus more efficiently.
Regular retrospectives, pattern recognition, training programmes, and metrics tracking enable continuous improvement.
The goal is creating an organisational culture that can move fast when safety nets exist (Type 2 decisions) while investing appropriately in decisions with permanent consequences (Type 1 decisions).
FAQ
How long should I spend analysing a Type 1 vs Type 2 decision?
Type 1 decisions warrant weeks to months of analysis given their permanent impact, while Type 2 decisions should be resolved in hours to days to maintain velocity.
What tools help identify if a decision is reversible?
Decision classification matrices, cost estimation frameworks, and Architecture Decision Records help evaluate reversibility based on implementation complexity and switching costs.
Can a Type 2 decision become Type 1 over time?
Yes, decisions can shift from reversible to irreversible as system complexity grows and dependencies increase, requiring periodic re-classification.
How do I convince my team to move faster on reversible decisions?
Demonstrate the cost of analysis paralysis versus quick iteration, provide safety through rollback strategies, and emphasise learning value over perfection.
What happens if I misclassify a decision type?
Misclassification leads to either over-analysis paralysis or insufficient planning risk. Regular review and re-classification help correct course.
Should startups approach decision classification differently than enterprises?
Startups can afford more aggressive Type 2 classification due to lower switching costs, while enterprises need more conservative classification due to scale and complexity.
How do I document decision reversibility for future reference?
Use Architecture Decision Records to capture reversibility assessment, classification rationale, and rollback strategies for future decision-makers.
What role does team experience play in decision classification?
More experienced teams can handle complex Type 2 decisions faster and identify Type 1 decisions more accurately, while newer teams benefit from conservative classification.
How do reversible decisions impact technical architecture evolution?
Reversible decisions enable evolutionary architecture through continuous improvement cycles, while irreversible decisions create permanent constraints.
When should I re-evaluate past architecture decisions?
Implement quarterly reviews for Type 2 decisions and annual reviews for Type 1 decisions, with additional evaluation triggered by significant changes.
