The Reorg Tax: Why Every Reorg Quietly Resets Your Architecture Decisions

TL;DR: A reorg can quietly undo months of careful architecture work even when not a single line of code changes. The danger isn’t the new org chart itself — it’s that the people who understood why a system was built a certain way leave, and the people who inherit it only see what it does. The fix is to write the reasoning down before the reorg happens, not after it breaks.

The situation

Ada was a staff engineer on the Ledger team at Northwind Freight, a logistics company that billed customers based on shipment weight, distance, and a dozen fuel-surcharge rules that changed every quarter. Eight months earlier, Ledger had shipped a redesign of how orders turned into invoices, and it had cost them a bruising outage to get there.

Here’s what happened before the redesign: the Orders service and the Billing service both tried to be “helpful” by retrying failed requests. When a network blip made Billing think an invoice request had failed, it would retry. Orders, meanwhile, was also retrying its side of the handshake. The result was that one shipment occasionally generated two invoices. Customers noticed before Northwind did, which is the worst way to find out.

Ada’s team spent weeks tracing the problem and landed on a clear rule: Billing, and only Billing, owns the idempotency key for an invoice. Orders can ask Billing to create an invoice as many times as it wants; Billing will only ever create one, because it checks a stored key before doing anything. That single rule — one team clearly owns the decision of “has this already happened?” — is what’s called an idempotency boundary. It sounds simple once you say it out loud, but getting every team to agree on which service owns that check, and sticking to it under deadline pressure, took real discipline.

They wrote it up, tested it hard, and it worked. No duplicate invoices for eight straight months. The team moved on to other problems, confident the boundary would hold.

The boundary held fine on its own. What it couldn’t survive was everyone who understood it leaving at once.

The turning point

Then came the reorg. Nothing dramatic triggered it — just the normal churn of a growing company reshuffling teams to match a new VP’s view of the org. Billing and Orders were merged into a single “Fulfillment Platform” team. On paper this made sense: fewer handoffs, one roadmap, one backlog. Ada stayed, but her manager moved to a different part of the company, and two of the three engineers who had lived through the original outage left for other teams in the reshuffle. A new engineering manager, Priya, inherited the merged team along with a quarterly goal to “simplify the invoicing flow and cut latency by 30%.”

Priya was good at her job. She read the code. She saw that Orders called Billing, waited for a response, then called it again if the first call timed out — which looked, to someone without the history, like wasteful duplicate work plastered on top of a slow API. Her new team’s design doc proposed removing the “redundant” retry logic and merging the two calls into one combined endpoint to save a network hop.

Nobody on the new team knew this was the exact mechanism that had caused the original outage. The code that enforced the idempotency rule was still there, buried in a function with an unremarkable name. The reason it existed — the actual incident, the postmortem, the hard-won agreement about who owns the check — lived in a handful of Slack threads and one old wiki page that nobody on the new team had a reason to open. The org chart had changed. The tribal knowledge that used to travel with “ask Ada’s team before touching invoicing” had been reset to zero, even though Ada herself hadn’t gone anywhere.

This is the part that’s easy to miss: the reorg didn’t touch a single line of the idempotency code. What it changed was who felt responsible for understanding it before changing it. That’s the real cost of a reorg on a system’s architecture — not the new boxes on the chart, but the invisible context that used to sit next to the code and now doesn’t.

The outcome

Ada caught it in design review, almost by accident — she happened to be looking over Priya’s doc because her own name was still on the calendar invite for “Fulfillment Platform syncs,” a leftover from the old team structure. She recognized the proposed change immediately and pulled up the old postmortem. Priya hadn’t done anything wrong; she simply had never been handed the one document that explained why the “wasteful” retry was load-bearing.

They fixed the design before it shipped, but Ada walked away from that review more unsettled than relieved. If she hadn’t happened to still be on that calendar invite, the change would have gone out, and Northwind would have relearned the double-billing lesson the expensive way — for the second time, with none of the people who knew the first story still in the room.

So the team did something boring but effective: instead of relying on tribal memory, they wrote an architecture decision record, a short document that states a decision, why it was made, and what breaks if you undo it, and put one directly next to the idempotency code, linked from the file itself, not just filed away on a wiki. They also started a habit of walking any new manager who inherits a system through its “load-bearing walls” in the first week, not waiting for someone to try to remodel before explaining which walls are structural.

None of this shows up on the new org chart — it only shows up the next time someone has to change the system.

Why this keeps happening

Reorgs get evaluated on org-chart logic: does this grouping reduce handoffs, does it match the roadmap, does it give this VP a clean set of teams to report on. Almost nobody evaluates a reorg by asking “which systems are about to lose the people who understand their scars?” That question doesn’t show up in a slide deck, so it doesn’t get asked, and the cost shows up months later as a confused engineer re-breaking something that was already fixed once.

Call it the reorg tax: a hidden cost that gets charged to whichever system had its context carried in people’s heads instead of in writing. You don’t pay it the day the org chart changes. You pay it the first time someone touches the system afterward without knowing what they’re standing on.

The defense isn’t to stop reorgs from happening — they’re a normal part of how companies grow, and fighting every one of them is a losing battle. The defense is to treat “why does this work this way” as a first-class artifact of the system itself, written down next to the code it explains, not stored only in the memory of whoever happens to still be around. A good decision record costs an afternoon to write. Relearning a lesson the hard way, after a reorg has already scattered everyone who learned it the first time, costs a lot more than that.