the station / sector 02
Reversibility
How to tell where you areTime yourself undoing the last change you shipped. Not describing how you would undo it — actually doing it, on a Tuesday, without waking anyone. If the answer involves a build, you are at the bad end; if it involves a database migration, you are further down than you think.
How fast you can put things back, and how much of a decision it is.
This is the second axis to move, and it pairs with feedback latency for the same reason: together they set the price of being wrong. Short feedback tells you quickly, cheap reversal means the discovery costs little. A team with both can take risks that look reckless from outside and are not. A team with neither develops elaborate process instead, because process is what you build when mistakes are expensive.
The trap is that reversibility is usually discussed as a deployment property, and the slowest part is almost never the deploy. It is the schema change nobody can undo, the message that already went out, the cache that has been poisoned for six hours.
This sector covers undoing any loss, not only a bad deploy. That widening is deliberate: a team can hold a one-command code rollback and still have no tested path back from a deleted table, a corrupted index, or a restore that has never been attempted. The slowest and least reversible part of most systems is the data, and a recovery path nobody has exercised is a hypothesis rather than a control.