We reorg’d to go faster, but things are much slower.

Why did we reorg in the first place? Conway’s law states that orgs tend to produce systems whose structure is a copy of their communication structures. Probably everyone’s familiar with the quote that software orgs tend to ship their org chart in their product.

Common guidance in response to that (most notably Spotify’s squads & tribes) is that org structure should follow user journeys, thereby ensuring systems and user experience are aligned.

This type of change frequently fails with established teams because the systems are still stuck in the old world:

• Knowledge debt: Engineers are thrown into unknown codebase which they have to master, so changes are slower and more error prone.
• On-call attention debt: most engineers are probably still on-call for other systems they haven’t yet handed over to the new team
• Architectural friction: Code and infra organization makes their changes cumbersome - changes frequently have to be coordinated across multiple repos and binaries.

I made the mistake in the past of heavily underestimating these complexities and teams suffered as a result: productivity dropped because virtually everyone was deadlocked by waiting for help from other teams, senior engineers were dissatisfied because they now had responsibilities across two teams.

In hindsight, here’s what I think I should have done differently:

• Start small: start with only one domain that has to be cleaned up. It must be strictly easier for affected engineers to do their job, otherwise the change scope is wrong.
• Run a thought-experiment workshop with the affected teams: look at the next 3-4 most likely items the newly formed team would be doing and see what would be their hardest blockers. Some blockers would be knowledge gaps, others would be code/infra gaps. => Plug most impactful knowledge gaps by borrowing engineers to work side-by-side with people that have the relevant knowledge. => Plug the most impactful code/infra gaps by prioritizing relevant refactors.

Give it time: these changes can easily take a quarter in large orgs with other competing priorities. During that time, don’t reorg: just create space for teams to prepare and raise further blockers they’ll see in their daily work during that quarter.

Therefore, and this is probably the most important takeaway here, don’t reorg until you’re confident the expected productivity benefits outweigh the reorg tax.

It’s probably better to continue running with the original org structure for a while longer and spend the time better understanding what exact problems are you trying to solve for.