The VP of Engineering announced the reorg on a Monday morning. The engineering organization had grown from 30 to 150 people in two years, and the original team structure—feature teams organized around products—no longer made sense. Dependencies between teams were creating bottlenecks. Ownership was unclear. Something had to change.
But the announcement came as a surprise. Managers learned their teams were being dissolved in the same all-hands where engineers learned their reporting structures were changing. Questions were deflected with "we're still working out the details." Within a week, rumors filled every gap the announcement had left.
Three months later, 15% of the engineering organization had left. The new structure was technically in place, but productivity had cratered. The reorg had been necessary, but the execution had been catastrophic.
I've seen this pattern repeatedly. Reorgs are sometimes unavoidable—organizations outgrow structures, strategies shift, growth demands new configurations. But the execution determines whether a reorg energizes the organization or devastates it.
After guiding over 30 engineering reorgs at SmithSpektrum, I've learned what separates successful restructurings from the ones that trigger exodus and destroy trust[^1].
When Reorgs Are Actually Necessary
Not every problem requires reorganization. Before restructuring, be certain you're solving the right problem.
Scale misfit is a legitimate reason to reorg. Structures that worked at 30 engineers rarely work at 150. Span of control becomes unmanageable, coordination complexity explodes, and what felt like agile autonomy becomes chaotic overlap. If your organization has doubled or tripled since the current structure was designed, revisiting that structure makes sense.
Strategy shifts sometimes require structural changes. If your company pivots from B2B to B2C, or from monolith to platform, the teams optimized for the old model may not serve the new direction. Structure should follow strategy.
Persistent coordination failures despite process fixes suggest structural issues. If the same cross-team dependencies cause problems quarter after quarter, and process improvements haven't helped, the structure itself may be the problem.
Acquisitions and integrations often necessitate restructuring. Merging engineering organizations requires decisions about how teams will combine, where duplications will be resolved, and how cultures will be integrated.
But many reorgs happen for bad reasons. New leaders wanting to put their stamp on the organization destroy working structures for ego rather than need. Managers avoiding hard conversations restructure around problem people rather than addressing problems directly. Political maneuvering uses teams as chess pieces. Copying what worked at another company ignores that your context is different.
Before reorging, ask: Have we actually tried to solve this problem without restructuring? Process changes, clarified ownership, better communication, leadership coaching—these address many issues that look structural but aren't.
The Organizational Models
Understanding your options helps you make better choices.
Product or feature teams organize around products or product areas. Each team owns a complete vertical slice—frontend, backend, data—for their product. The strength is autonomy: teams can move independently without waiting for other teams. The weakness is duplication: multiple teams may solve similar problems differently, and coordination across products becomes harder. This model works well for product-led companies with clear feature boundaries.
| Reorg Type | When Appropriate | Timeline | Risk Level |
|---|---|---|---|
| Team split | Team too large (>8-10) | 2-4 weeks | Low |
| Function merge | Duplicate capabilities | 4-6 weeks | Medium |
| New layer (add managers) | Span of control too wide | 4-8 weeks | Medium |
| Full restructure | Strategy shift | 8-12 weeks | High |
| Leadership change | Performance issues | Immediate | Very high |
Platform or infrastructure teams organize horizontally, providing shared services that multiple products consume. The strength is expertise concentration and consistency: one excellent platform team builds infrastructure everyone uses. The weakness is bottleneck potential: if the platform team can't keep up with product team needs, everyone slows down. This model works when shared infrastructure needs are substantial.
Pods or squads are small, cross-functional teams optimized for speed. Spotify popularized this model, though many companies have adopted and adapted it. Pods move quickly and have clear ownership but can struggle with coordination across pods and consistency of approach.
Matrix organizations split reporting: engineers report to a functional manager for career development and a product manager or project lead for daily work. The strength is flexibility—you can reassign engineers to projects without restructuring. The weakness is confusion: when you have two bosses, accountability gets murky, and organizational politics multiply. Matrix structures are common in large enterprises and rare in startups for good reason.
Most real organizations are hybrids. You might have product teams for customer-facing features, a platform team for shared infrastructure, and a specialized team for security or data. Pure models are rare; thoughtful combinations are more common.
Planning the Reorg
Good reorgs start with clear goals. Bad reorgs start with org charts.
Before designing any structure, articulate what problem you're solving. What will be different after this reorg that isn't true now? How will you know you've succeeded? What specific dysfunctions will this restructuring address?
Write these down. If you can't articulate the goal clearly, you're not ready to restructure. And if the goal is vague—"improve collaboration" or "increase velocity"—the reorg is likely to produce structural change without actual improvement.
Once goals are clear, design the new structure. For each team in the new model, define its mission (what it owns), its composition (who's on it), and its boundaries (what it doesn't own). Map dependencies between teams—how will they need to coordinate? Ensure career paths exist within the new structure. Think about skill distribution: is expertise concentrated appropriately, or have you created teams that lack critical capabilities?
Then map people to positions. This is where reorgs become real—you're deciding which humans go where. Sometimes the mapping is obvious. Often there are ambiguities: two people who could fill the same role, individuals who fit multiple teams, teams that need skills you don't currently have. Handle these carefully; your decisions about people will be scrutinized and remembered.
Finally, plan the communication and transition. When will you announce? To whom, in what sequence? What will you say, and what will you explicitly not say? What questions will people ask, and what are your answers? What happens to in-flight work? When do new reporting structures take effect?
Communication: The Make-or-Break Factor
More reorgs fail because of poor communication than because of poor design.
The principles that matter: transparency about the why, consistency in messaging, speed in execution, and empathy for the disruption you're causing.
Transparency doesn't mean revealing every detail before decisions are final. It means explaining honestly why change is happening. "We've grown faster than our structure, and the current model creates dependencies that slow everyone down" is honest. "We're reorganizing for greater synergy" is corporate-speak that erodes trust.
Consistency means everyone hears the same message. When the VP tells one story and managers tell another, rumors fill the gaps. Align your leadership team on messaging before the announcement. Everyone should be able to answer the same basic questions the same way.
Speed matters because uncertainty is toxic. The worst reorg experiences involve drawn-out timelines—an announcement that change is coming, followed by weeks of ambiguity about what exactly will change, followed by gradual reveals that keep everyone unsettled. When you're ready to announce, announce everything you've decided. If something genuinely isn't decided yet, say so explicitly rather than leaving gaps.
Empathy acknowledges that reorgs are disruptive even when necessary. People are losing teammates, managers, familiar contexts. Even positive changes involve adjustment. Acknowledging this—not pretending everything is fine—builds trust.
The communication sequence I recommend: brief the leadership team a week or two in advance so they can prepare, brief managers a few days before so they understand their role in the rollout, then announce to the entire organization in a single coordinated moment. Same-day individual conversations between managers and their team members follow, addressing personal questions the all-hands couldn't cover. Open Q&A sessions in the following days address ongoing concerns.
What you communicate matters as much as when. Cover: the reason for the change, what's changing and what's not, each person's specific situation, the timeline for transition, what support is available, and how to raise concerns or ask questions.
Managing the Transition
The announcement is the beginning, not the end. The weeks following a reorg announcement determine whether the change succeeds.
The first week should focus on individual conversations and emotional processing. Every affected person should have a one-on-one with their manager (new or existing) addressing their specific situation. What does this mean for me? Is my job secure? Who do I work with now? What happens to the project I was working on?
The second week should focus on new team formation. New teams need kickoffs—not just logistics, but relationship building. People need to meet their new colleagues, understand the team's mission, and start forming working relationships.
The third and fourth weeks establish new processes. How does this team run standups? How do we coordinate with adjacent teams? What are our priorities?
Throughout, check in frequently. Weekly pulse surveys, skip-level conversations, open office hours—create multiple channels for concerns to surface. Problems caught early are fixable. Problems that fester become resignations.
Support managers especially. They're the front line of the reorg—responsible for implementing changes while also processing their own feelings about disruption. Give them talking points for difficult questions. Give them a place to escalate issues they can't resolve. Give them time with leadership to stay aligned.
Common Mistakes
The biggest mistake is surprising people who shouldn't be surprised. When managers learn about changes to their teams in the same meeting where engineers learn, you've signaled that you don't trust or value those managers. When individuals hear about their fate through rumors rather than directly, you've damaged relationships that may not recover.
The second biggest mistake is slow communication that allows rumors to flourish. Every day between "something is changing" and "here's what's changing" is a day of anxiety, speculation, and declining productivity. Move quickly from decision to announcement to implementation.
Underestimating disruption is common, especially among leaders who are excited about the new structure. You've been thinking about this for months; for your team, it's sudden. The productivity dip is real. The relationship-rebuilding takes time. Plan for a recovery period rather than expecting instant improvement.
Creating the new structure without clear ownership creates different problems than the ones you were solving. If the old structure had ambiguous boundaries, and the new structure also has ambiguous boundaries, you've reorganized for nothing. Be explicit about who owns what.
Ignoring the informal network is a subtle mistake. Official structure matters, but so do the relationships and communication patterns that exist regardless of org charts. A reorg that breaks key informal connections—moving people who were effective partners into separate silos—may lose value that wasn't visible on the old chart.
Measuring Success
How do you know if the reorg worked?
Short-term metrics (30-90 days) tell you about execution. Voluntary attrition: Is there a spike? Any departure during this period deserves investigation—did they leave because of the reorg? Team survey scores: Did engagement and satisfaction decline significantly? Productivity indicators: There's usually a dip; how deep, and how quickly does it recover? Escalation volume: Problems should spike initially as people navigate uncertainty, then decline.
Medium-term metrics (6-12 months) tell you about design. Did the reorg solve the problems it was meant to solve? If cross-team dependencies were the issue, are those reduced? If ownership clarity was the issue, is it clearer? Compare delivery velocity, engagement scores, and collaboration quality to pre-reorg baselines.
Failure indicators require attention. If attrition spikes, the reorg damaged trust or morale in ways that need repair. If confusion persists after 90 days, communication or design failed. If people are working around the new structure, it doesn't match how work actually happens. If the same problems recur, the reorg didn't address root causes.
Success isn't just the absence of failure. A successful reorg should eventually produce improvements—better coordination, clearer ownership, faster execution, whatever the goals were. If six months pass and nothing is measurably better, something went wrong.
When Reorgs Include Layoffs
Reorgs sometimes occur alongside reductions in force. This combination is particularly difficult.
If possible, separate the two. A reorg is disruptive. A layoff is traumatic. Combining them creates compound trauma that makes both harder to process and recover from.
If separation isn't possible, be clear that the reorg and the layoff are distinct decisions. People worry that reorganization is a cover for performance-based terminations. If the layoff is about headcount economics and the reorg is about structure, say so explicitly.
Support survivors as much as laid-off employees. The people who remain are processing grief, guilt, and fear. They're also now expected to do more with less. They need attention and support, not just relief that they kept their jobs.
The VP of Engineering whose reorg lost 15% of the team learned from the failure. The mistake wasn't the structure—the new organization design was sound. The mistake was execution: surprising managers, slow communication, no individual follow-up, vague answers to direct questions.
A year later, facing similar growth, a different company approached restructuring differently. Thorough planning, manager briefings a week in advance, same-day individual conversations, clear rationale explained honestly, 90 days of intentional support and check-ins.
Attrition during that reorg? Zero beyond normal baseline.
Reorgs are hard even when done well. But they don't have to be destructive. The difference is preparation, communication, and care for the people involved.
References
[^1]: SmithSpektrum organizational consulting, 30+ engineering reorgs advised, 2019-2026. [^2]: Larson, Will. "An Elegant Puzzle: Systems of Engineering Management," 2019. [^3]: HBR, "Leading Organizational Transformations," 2024. [^4]: McKinsey, "Organizing for the Future," 2025.
Planning an engineering reorganization? Contact SmithSpektrum for organizational design and transition support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum