Most Decisions Live in the Gray Zone
The Type 1 / Type 2 framework is a mental model, not a rigid classification system. In practice, decisions exist on a spectrum of reversibility. Treating the framework as a strict binary creates its own problems — teams argue about which "type" a decision is instead of just assessing the actual reversal cost.
The Assessment Questions:
When you encounter a decision and aren't sure where it falls, run through these four questions:
- What is the literal reversal mechanism? Can you
git revert? Toggle a feature flag? Or does reversal require a data migration, a new hire, or a contract renegotiation? - How long does reversal take? Seconds (config change) → hours (rollback deployment) → days (rewrite a service) → months (re-platform) → years (change cloud provider).
- Who is affected by a wrong choice? Just your team? All internal engineers? External customers? Paying enterprise clients with SLAs?
- Does the decision compound over time? Some choices become harder to reverse the longer you live with them. Choosing a message queue is moderately reversible on day one. After 50 services depend on it, it's effectively irreversible.
The Compounding Effect
This fourth question is the most overlooked and the most important. Many decisions start as Type 2 and become Type 1 through accumulated dependency. When you adopt a new internal library, the first service using it can easily switch away. After 200 services depend on it, you've created a de facto standard that's nearly impossible to change.
Consider a concrete example: your team adopts a custom internal HTTP client wrapper to standardize retry logic. On day one, one service uses it — trivially reversible. After six months, 40 services import it, your observability tooling instruments it specifically, and your on-call runbooks reference its error codes. The wrapper is now load-bearing infrastructure. Changing it requires coordinating 40 teams, updating runbooks, and re-validating observability. What started as a Type 2 decision has compounded into a Type 1 reality.
Senior engineers watch for this compounding effect and make deliberate choices about when to "lock in" versus when to keep options open. A useful heuristic: when a third team adopts something, treat it as a Type 1 decision going forward, even if it wasn't one originally.
Key Point: In architecture reviews and interviews, don't just classify a decision — explain why you classified it that way by walking through the reversal mechanism, the time horizon, the blast radius, and the compounding risk. This demonstrates systems thinking, not just framework memorization.