Amazon's one-way-door, two-way-door framing is good enough that half the engineering leaders I know now use it without knowing where it came from. A one-way door is a decision you can't easily reverse — shut down a product line, sign a five-year contract. A two-way door is one you can walk back through: pick a library, choose a naming convention, try a process for a sprint. The advice that follows is sound: move fast through two-way doors, slow down for one-way ones.
The trouble starts when you use the framework on a decision and ask "can this be reversed" without asking the second question, which is "reversed by whom, and at whose cost." Those are different questions, and the gap between them is where most bad two-way-door calls live.
The door that's only two-way for the person opening it
A platform team picks a message queue. In the abstract, this is textbook two-way-door territory — messaging infrastructure gets swapped out all the time, it's an implementation detail, nobody's roadmap depends on the specific product name. The platform team makes the call in an afternoon, ships it, moves on.
Eighteen months later, four product teams have built retry logic, idempotency assumptions and monitoring dashboards around that specific queue's specific failure modes. Reversing the choice now means four teams re-testing their integrations, not one team swapping a dependency. The door was two-way for the person who opened it and one-way for everyone standing on the other side of it, and nobody asked which side those four teams were on before the door got picked.
Reversal cost isn't a property of the decision. It's a property of who has to pay it, and that's rarely the person making the call.
This is the pattern worth watching for: any decision where the person deciding is not the person who absorbs the cost of undoing it. Team topology decisions, shared library choices, API contracts between two systems owned by two different teams — every one of these looks locally reversible and is organisationally sticky, because reversal cost accumulates on the far side of a boundary the decider can't see across.
Why the heuristic fails quietly
The reason this is dangerous rather than merely imperfect is that it fails without triggering anyone's caution. A genuinely one-way door — the kind that shuts down a product or signs a binding contract — gets treated with appropriate weight, because it looks serious. Everyone slows down, brings in stakeholders, writes the memo. It's the decisions that look like two-way doors, that get made in an afternoon by one person with good intentions, that quietly accumulate the largest total reversal cost across an organisation, precisely because nobody applied the brakes.
I've started asking a different question before reaching for "reversible or not": who else has to change something if we change our minds. If the answer is "just us, in this repo, this sprint" — genuine two-way door, move fast, don't overthink it. If the answer touches another team's dashboards, another team's on-call runbook, or a contract another team is building against, the door has a second hinge you don't control, and the decision deserves the weight of a one-way door even though nothing about it looks permanent from where you're standing.
What this changes in practice
It doesn't mean slowing everything down — that just recreates the paralysis the two-way-door framing was invented to cure. It means adding one question to the reversibility check rather than replacing it: not just "can we undo this," but "whose afternoon does undoing this cost, and did we ask them."
For decisions that stay inside a team's own boundary, the original heuristic is exactly right and should stay fast. For decisions that cross a boundary — team, system, contract — the honest move is to treat reversal cost as a property of the whole organisation's graph, not of the one node making the call. That's a harder question to answer quickly, which is precisely why it's the one worth asking before the door closes rather than after four other teams have already walked through it.