By Decision Desk
Every engineering team eventually has the same argument. One group says "we need more design review, we keep shipping things we regret." Another says "we need less process, it takes three weeks to change a config value." Both are usually right, about different decisions.
The fix isn't more process or less. It's matching the process to how hard the decision is to undo. That idea has a well-known framing, and it's worth being precise about how to apply it to engineering work.
One-way doors and two-way doors
Amazon's 2015 shareholder letter described two types of decisions. Type 1 decisions are "one-way doors": consequential and nearly irreversible, so they deserve slow, careful deliberation. Type 2 decisions are "two-way doors": if you walk through and don't like it, you walk back. Those should be made quickly, by small groups or individuals.
The letter's warning was about a specific failure: as organizations grow, they start using the heavyweight Type 1 process for everything, including the Type 2 decisions. The result is slowness, risk aversion, and not enough experimentation.
Engineering teams make the opposite mistake just as often. They treat a one-way door like a two-way door because the change looks small. It's a single PR, it's behind a flag, "we can always roll back." Then they discover the rollback only covers the deploy, not the data, the contract, or the three teams that started depending on it.
So the rule is ceremony proportional to irreversibility: the harder a decision is to reverse, the more review and documentation it gets. The easier it is to reverse, the faster and lighter you go.
Operational rollback isn't architectural reversal
This distinction does most of the work, and it's where teams misclassify.
Operational rollback is what your deploy tooling gives you: revert the commit, flip the flag, drain traffic. It takes minutes.
Architectural reversal is what it costs to make the decision not have happened:
- Data written in a new format has to be migrated back, or read by two code paths forever.
- A public API field that clients now parse can't be removed without a coordinated release or a version bump.
- A vendor contract has a term. A protocol choice has a whole ecosystem of clients.
- Another team built a feature assuming your event shape. Now it's their roadmap too.
A feature flag can make operational rollback instant while architectural reversal still takes a quarter. When someone says "it's reversible, it's behind a flag," the follow-up question is: what does the flag not undo?
Signals that you're looking at a one-way door
You don't need a scoring model to spot Type 1 decisions. These questions catch most of them:
- Does it touch data you can't regenerate, personal or regulated data, money, or security boundaries? Mistakes here tend to be permanent, even when the code change is small.
- Could you fully undo it within a sprint, with no data migration, dual-write, or coordinated client release? If not, it's a one-way door.
- Does it create something others will build against for a year or more? Public or cross-team APIs, event schemas, storage formats, protocols, vendor commitments.
- Would undoing it require another team to change their code or plans? Reversal cost scales with the number of teams involved.
If none of these are true, you're almost certainly looking at a Type 2 decision, and the best thing you can do is decide quickly.
What "ceremony" means at each level
"More process" is vague. Here's a concrete version that works for small and mid-sized teams:
| No record needed | Type 2 | Type 1 | |
|---|---|---|---|
| Record | PR description | One-page decision record | Full record, 2–4 pages |
| Alternatives | — | Status quo + one alternative, one line each | Status quo + at least two real alternatives with tradeoffs |
| Review | Normal code review | One reviewer, async, same day | Named reviewer from each affected team; security or data owner when relevant; 3–5 day window |
| Done when | PR merges | Reviewer agrees | Blockers cleared: honest rollback story, named owners, data/security addressed |
| Revisit | — | Optional date | Explicit triggers: a metric, a date, or an event |
The "no record needed" column matters. If your process demands a document for renaming a private function, people will route around the process for everything. Letting trivial choices go undocumented is what makes the Type 2 record feel cheap enough to actually write.
Three examples
Flipping a feature flag default from off to on. Usually Type 2. Operational rollback is instant, and if no data format or contract changes, architectural reversal is instant too. Write one page, get one reviewer (ideally from support or product, since customers will notice), and set a date to remove the flag. It becomes Type 1 if the new code path writes data the old path can't read, or changes consent or tracking defaults.
Choosing the primary datastore for a new service. Almost always Type 1. Switching later means a backfill and a dual-write period, and if the data feeds invoices or audits, the first signal (data you can't regenerate, money) applies as well. Full record, reviewers from whoever will operate it, and a real comparison of alternatives.
A breaking change to a public API. Type 1. Once clients migrate, the change is permanent. What's interesting is that you can often split out a reversible first step: add the new fields to the existing version as optional and additive, which is Type 2, while the breaking version goes through full review.
The trick that makes Type 1 faster
People resist Type 1 process because it's slow, and sometimes the cost of delay is real. The answer isn't to skip the record. It's to ask one question before the review starts:
Can we split out a reversible first step?
Shadow-write to the new store while the old one stays authoritative. Ship the new endpoint behind a flag to one internal client. Take a 30-day vendor trial instead of a 3-year contract. Each of these turns part of a one-way door into a two-way door, lets you gather evidence, and shrinks the irreversible part to something smaller and better informed.
When you genuinely can't split it and time matters, shrink the review window, not the record: a 48-hour async review with a decision date written on the page.
When you're not sure
Two rules handle most of the ambiguity:
- When unsure, go heavier. Downgrading a Type 1 to Type 2 after a five-minute conversation costs five minutes. Discovering in production that a "quick change" was a one-way door costs a migration.
- Classify the slice, not the project. A large project usually contains one or two irreversible choices, like a schema or a contract, surrounded by many reversible ones. Give the irreversible slice full ceremony and let the rest move fast.
Precedent is the subtle one. A reversible choice that every team will copy without thinking, like the default logging library or the default test runner, is still Type 2. But it deserves a record, because "why is this the default?" is exactly the question people will ask.
The payoff
When ceremony tracks irreversibility, a few things change:
- Engineers stop asking "do we need an ADR for this?" because there's a two-minute answer.
- Review time concentrates on the handful of decisions that can actually hurt you.
- The decision log fills up with useful short records instead of a few abandoned long ones.
- New engineers can read why the system looks the way it does, for the decisions that matter.
None of this needs tooling. It needs a shared definition of which door you're walking through.
If you want to try this on a real decision, we put together a free one-page Decision Classifier: 7 yes/no questions that end in Type 1, Type 2, or "no record needed," a minimal ADR stub, and three worked examples (API versioning, database choice, feature flag default). It's here: https://decisiondeskeng.gumroad.com/l/vbowoo
Top comments (0)