The new VP of Engineering arrives. Within 60 days, there’s a reorg. Teams are shuffled. Reporting lines change. A new Slack channel called #reorg-questions appears. Everyone updates their LinkedIn.

Six months later, the same problems exist. The deployment pipeline is still broken. The core product still ships slowly. The best engineers are still leaving. But hey, the org chart looks cleaner.

Most engineering reorgs fail because they solve the wrong problem — they treat organizational structure as the cause of dysfunction when it’s usually a symptom of deeper issues.

The Org Chart Fallacy

Leaders default to reorganizing because it feels like decisive action. You can draw new boxes on a whiteboard, announce changes in an all-hands, and declare victory. It’s visible, it’s dramatic, and it creates the impression that something is being done.

But org charts don’t build software. Information flow builds software. And most reorgs destroy information flow in the name of improving it.

When you move Engineer A from Team X to Team Y, you’re not just moving a person on a diagram. You’re severing relationships that took months to build, destroying context that took months to accumulate, breaking communication patterns that were actually working, and resetting trust to zero. That engineer, who was fully productive on the day before the reorg, will take 3-6 months to become productive in their new context — learning the codebase, the team’s norms, the stakeholders’ expectations, and the unwritten rules that every team accumulates.

Multiply that by 50 engineers in a mid-size reorg, and you’ve just burned 150-300 person-months of productivity. That’s a small company’s entire annual engineering output — evaporated. Not because anyone did anything wrong, but because the organizational change itself has an enormous productivity cost that rarely appears in the planning document.

The Productivity Crater

The timeline of a reorg follows a predictable pattern that most leaders dramatically underestimate:

Weeks 1-2: Shock and uncertainty. Even if the reorg was well-communicated, engineers spend significant mental energy processing what it means for their career, their projects, and their relationships. Productivity drops 30-50% as people attend reorg-related meetings, have side conversations, and worry.

Weeks 3-8: Context building. Engineers in new teams start learning new codebases, new processes, and new people. They’re asking questions constantly — which is valuable learning, but it also pulls experienced team members away from their own work. The team as a whole is less productive than it was before the change.

Months 3-4: Emerging productivity. Engineers start to become productive in their new context. But they’re not yet at the level they were in their previous context, because deep expertise takes time.

Months 5-6: Recovered productivity. The team begins to approach pre-reorg productivity. For complex systems, full recovery may take 9-12 months.

The total cost: 4-6 months of depressed productivity across every affected team. For a 50-person engineering organization with a $250K fully-loaded cost per engineer, that’s $2M-$5M in lost productivity. Reorgs are extraordinarily expensive, and the cost is almost entirely invisible because it shows up as “slower delivery” rather than a line item on a budget.

When Reorgs Actually Work

Reorgs work in exactly two scenarios, and they should be reserved for these cases:

1. The team topology fundamentally doesn’t match the product architecture

If you have three teams building one tightly coupled service, you have a coordination nightmare that no amount of process improvement will fix. You either need one team owning that service, or you need to decompose the service into three independent components that each team can own independently.

Conway’s Law isn’t a suggestion — it’s a natural law of software engineering. Your system architecture will eventually mirror your communication structure, and your communication structure will eventually mirror your system architecture. When the two are misaligned, the friction is constant and escalating.

2. The organization has grown past a phase boundary

Going from 15 to 40 engineers requires structural changes. What worked with four teams and a flat hierarchy — everyone knows everyone, decisions happen in the hallway, the CTO is directly accessible — won’t work with twelve teams and a hundred-person organization. These transitions are real and necessary.

The key phase boundaries are roughly: 15 engineers (needs management layer), 40 engineers (needs director layer), 120 engineers (needs VP layer), and 400+ engineers (needs divisional structure). Each transition requires not just adding hierarchy but fundamentally changing how information flows, how decisions are made, and how teams coordinate.

Everything else — “we need to align teams to customer segments,” “we should create a platform team,” “the frontend and backend teams should merge” — there’s almost always a less destructive solution.

What to Do Instead

Fix the Information Flow

Before reorganizing people, map how information actually flows through your organization today. Not the official channels — the actual channels. Who talks to whom? Where do decisions get stuck? Where does context get lost?

Common information flow problems and their targeted fixes:

• Decisions stuck waiting for approval: Push decision authority down. Define which decisions each level can make autonomously and establish clear escalation criteria.
• Teams that need to coordinate daily but sit in different departments: Create embedded liaisons — place one engineer from Team A into Team B for a quarter. They maintain their reporting line but work alongside the other team, building relationships and shared context.
• Meetings that exist solely because two teams can’t communicate through their code: Define explicit API contracts between teams. When the interface is well-defined, the teams can work independently and the coordination meetings become unnecessary.
• Knowledge silos where one person holds all the context: Implement documentation standards and pair programming rotations. The solution is knowledge distribution, not people distribution.

Fix the Incentives

If teams are optimizing for the wrong things, changing the org chart won’t fix that. Changing the incentives will.

If Team A ships features that break Team B’s service, the fix isn’t to merge the teams — it’s to make Team A own the reliability of the features they ship. When the engineer who writes the code is also the one who gets paged at 2am when it breaks, the quality of that code improves dramatically. This is the core insight behind “you build it, you run it” — it creates a direct feedback loop between quality and consequence.

If teams are hoarding information and not collaborating, the fix isn’t to restructure them — it’s to create shared goals and shared metrics. When two teams are measured on the same outcome, collaboration becomes rational self-interest rather than organizational charity.

Fix the Charter

Many team conflicts exist because team charters overlap or have gaps. Two teams think they own the authentication module. Zero teams think they own the deployment pipeline. Every change to the order processing flow requires coordination between four teams, none of whom feel fully responsible.

A clear charter — what you own, what you don’t, what your interfaces are, and what your SLAs are to other teams — resolves 80% of organizational friction without moving a single person. The charter should be specific enough that any engineer can answer “who owns this?” for any component in the system.

Fix the Communication Mechanisms

Sometimes the problem isn’t who’s on which team — it’s that teams don’t have effective mechanisms for communicating across boundaries. Before reorganizing, try:

• RFC processes for cross-cutting technical decisions
• Weekly cross-team syncs with rotating attendance (15 minutes, not an hour)
• Shared on-call rotations for systems that span multiple teams
• Inner-source models where any engineer can contribute to any team’s codebase following documented contribution guidelines

The Reorg Test

Before proposing a reorganization, answer these five questions honestly:

1. Can I articulate the specific problem this reorg will solve? Not “improve alignment” or “increase collaboration” — the specific, measurable problem.
2. Have I tried solving it without a reorg? If you haven’t tried fixing information flow, incentives, and charters first, you haven’t tried the cheaper solutions.
3. Is the problem structural, or is it a people/process problem wearing a structural costume? Two teams that don’t collaborate won’t suddenly collaborate because you merged them. The interpersonal dynamics follow the people, not the org chart.
4. Am I willing to accept 3-6 months of reduced productivity as the cost? If the problem isn’t severe enough to justify that cost, the reorg isn’t worth it.
5. Will this still be the right structure in 18 months? If the business is changing rapidly, you’ll need to reorg again in a year — and each reorg costs another 3-6 months of productivity.

If you can’t answer yes to all five, you don’t need a reorg. You need a conversation, a process change, or a better set of team agreements.

---

The Garnet Grid perspective: We help engineering leaders diagnose organizational problems before they restructure. Sometimes the answer is a reorg. Most of the time, it isn’t — and the cheaper solutions work better. Learn about our architecture audits →