Reorgs: Choosing Communication Paths, Not Drawing Boxes

From the field: 140 calls and an empty channel

We announced the reorg on Monday 6 October, and it started on 13 October. 22 engineers moved from four teams split by layer to four teams split by customer flow. The old structure: Core Backend (7), Web (5), Mobile (6), Data (4). The new one: Account Opening (5), Orders (6), Money Transfers (6), Reporting and Support (5).

On Saturday 1 November at 02:00, the monthly statement job ran and stopped halfway because a dependency timed out. The alert fired and went to #core-backend-alerts. The channel was not archived, but only two people were still in it. Both were now in the Orders team, and both had muted it. Nobody looked on Saturday or Sunday. On Monday morning, support came to us with 140 calls. The statements reached 18,400 customers at 16:20 that day, about 62 hours late. The compliance team’s first question was “did we miss the deadline?” We had not. But that was luck, not a plan.

That morning I asked two teams: “Who owns the statement job?” Account Opening said “Reporting, because it is a report.” Reporting said “Account Opening, because it belongs to the account.” Both answers were reasonable. The job was one of six jobs in the old Core Backend team’s core-batch repo. When we drew the new structure, we gave each repo to the team that owned its “main service”. That repo had no main service, so it went to nobody.

The mistake was mine. I had planned the reorg as a distribution of people: who goes to which team, who reports to whom. I had not planned it as a distribution of work. The org chart had 22 names, and every one of them was in a box. The only thing outside the boxes was a job that ran at 02:00.

What a reorg changes: the other side of Conway

Conway’s law says, in short, that systems copy the communication structure of the organisation that builds them. People usually mention it when they create teams. When you change an existing structure, the other side of the law matters more: the code remembers the old communication structure. A team that worked by layer for four years leaves behind code split by layer. You can move people overnight. You cannot move the code overnight.

This is also where I should explain why we did the reorg. In the last quarter, 21 of the 30 finished items touched at least two teams, and 9 touched three. A task like “add a field to the withdrawal screen” travelled between Web, Mobile and Core Backend. The average wait between teams was 4.5 days. Nobody was slow. Every piece of work simply had to fit into three teams’ calendars at the same time.

What a reorg really does is this: it chooses which conversations are cheap and which are expensive. A conversation inside a team is cheap. It happens in the daily, at the desk, in one message. A conversation between teams is expensive. It needs a meeting, a ticket, a wait. When you draw the boxes, you are answering one question: for the next two years, which people should be able to work without waiting for each other?

Our answer was “the people who change one customer flow from start to finish”. The cost of that answer showed up quickly: core-api. In the old structure it belonged to one team. In the new one, all four teams wrote to it. In the first month we had three conflicting releases and one rollback. The fix was not to split the service, at least not yet. We gave it one owner (the Orders team). Other teams open pull requests, the owner reviews them and ships the release. Shared code does not mean shared ownership.

The ownership map: before the org chart

For two days after the incident, four people did only one thing: they built a list of everything running in the company and who owned it. Services, scheduled jobs, queues, dashboards, external integrations. 41 components in total. 9 had no owner, and 5 had two. 6 of the 9 ownerless ones were scheduled jobs. That is not an accident. A cron job talks to nobody. It just runs, so nobody remembers it.

This is the difference between what an org chart shows and what an ownership map shows:

We did not put the map on a wiki page. We put it in the repo. Each component is one record, and CI checks the file on every pull request. There are two rules: a component without an owner cannot be deployed, and CI warns if nobody from the owning team is in the alert channel. This is the statement job’s record today:

# lives in the repo root; CI checks it on every PR
- component  : statement-job
  type       : cron (1st of every month, 02:00)
  team       : reporting-support         # one team, never two
  oncall     : reporting-oncall
  alerts     : "#reporting-alerts"        # CI: is anyone from the team in it?
  old_owner  : core-backend              # second line, 30 days
  second_line: until 2025-12-05
  external   : none
  note       : "dependency timeout 30 s; load is 3x on the 1st"

By then, new services created through the golden path already had an ownership record (the sixth step I described in the platform team post). The problems came from older components, created before that step existed. The real job of the map is not to record new things. It is to record the old ones.

The announcement: a map, not a slide

We announced the reorg on 6 October in a 45-minute meeting. One slide: four boxes with names inside. We left 15 minutes for questions. The questions were not about the boxes: “What happens to the payment integration I wrote?” “Who releases the mobile app now?” “Who owns statement-job?” The last one was asked again on Slack the same afternoon and stayed unanswered for two days. Three weeks later we got the answer, in the form of 140 calls.

In a reorg announcement, people ask “what happens to my work?” more than “which box am I in?”. If I did it again today, the order would be:

1. The map first. Before the announcement, every component has a new owner in writing.
2. One-to-one talks first with the people most affected. People whose work changes the most should not learn about it from a slide.
3. The map is part of the announcement. Boxes on the slide, and an attached table: “where your services are going”.
4. The reason, with a number. “21 of 30 items touch two teams” convinces people more than “we will be more agile”.

The transition: put it in the calendar

“From 13 October we are in the new structure” gives you a date, not a process. Knowledge travels in people’s heads, and heads do not empty in one day. After the incident, we wrote the transition down:

The “first independent deploy” rule helped most. A handover session is a conversation. The new team says “got it”, but nobody knows if they really did. When they ship a change without asking the old owner, you know. 36 of the 41 components passed that bar in the first 30 days. For the other 5, we extended the second line by 15 days.

How it breaks

• Only people move. The boxes change, but code ownership, the on-call list and alert routing stay where they were. The new structure exists on paper; the old one runs in production.
• “Shared” components. Something two teams own together is, in practice, something both teams leave for later. Ownership goes to one team. Contributions can be open to everyone.
• A transition with no transition period. The next day, the old owner is deep in their new work and answers questions with “it is not ours any more”. Not bad intent, just the natural result of new priorities.
• Fixing a reorg with another reorg. If the problem in the first structure was ownership, new boxes move the problem, they do not solve it. Without at least a year between two reorgs, nobody can tell whether the new structure is good or bad.

What to track

One thing got worse, and the table is not complete without it. When five web developers were spread across four teams, the user interface stopped being consistent: in six weeks, two different date pickers went live. We gave the shared component library one owner (Reporting and Support) and set up a weekly half-hour meeting for the web developers. Splitting by layer had one good side, and the reorg took it away. Getting it back needed separate work.

Checklist

Conclusion

That Monday morning, nobody had done their job badly. The alert fired, support called, and both teams gave a reasonable answer. The only thing missing was the statement job being on anyone’s list. I planned the reorg with boxes, so whatever did not fit in a box was left out of the plan.

In a reorg you are not drawing boxes. You are drawing communication paths. You choose who can talk to whom cheaply, and over time the code takes the shape of those conversations. That is why you distribute the work first, and the people second.

When a reorg ends, everyone has a new team. The real question is whether everything has a new owner.