Course page
Log in

You are watching a free preview. Enroll to open all 24 lessons, track progress and ask the course tutor.

Enroll for $89.99

Section 1: Why technical decisions go wrong

Reversible and irreversible decisions

Article 10 min Lesson 2 of 24 Preview

Not every decision deserves the same process. One of the most useful habits in technical leadership is classifying decisions by how hard they are to undo and how much they affect, then choosing a process to match.

Two kinds of doors

A common metaphor describes decisions as doors:

  • Two way doors are reversible. If the choice turns out wrong, you can walk back through at modest cost. Choosing a library for one service, a team's code review rules or a feature flag strategy usually falls here.
  • One way doors are hard or expensive to reverse. Choosing a primary database for many services, a public API contract or a data model used across the company often falls here.

The mistake most organisations make is treating two way doors like one way doors: long reviews and committees for choices that could be tested and reversed in a week. The opposite mistake, treating one way doors casually, is rarer but more costly.

A simple matrix

Combine reversibility with blast radius: how many teams, systems or customers are affected.

  • Reversible, small blast radius: the team decides, maybe with a short note. Speed matters most.
  • Reversible, large blast radius: decide reasonably quickly, but communicate widely and plan how to roll back.
  • Hard to reverse, small blast radius: think carefully within the team, document an ADR.
  • Hard to reverse, large blast radius: a full RFC with wide review, explicit decision owner and clear communication.

Making decisions more reversible

Often you can turn a one way door into a two way door with design choices:

  • Interfaces and abstraction: hide a vendor behind an internal interface so it can be swapped later.
  • Incremental rollout: migrate one service first, learn, then continue.
  • Feature flags: enable new behaviour gradually with a quick off switch.
  • Parallel running: run old and new systems side by side and compare results before switching.

These techniques have their own cost, so use them where reversibility is worth it.

Applying it to the case study

Classify the company's three decisions. The messaging system choice affects many services and is moderately hard to reverse. The monolith approach affects every team and is very hard to reverse once underway. The table migration is hard to reverse but has a smaller blast radius. Each will get a different process in the lessons ahead.

← → switch lessons