Reorganizations are one of the most disruptive things you can do to an engineering organization. Yet they’re sometimes necessary—when the current structure no longer serves the business, when teams have grown too large, or when strategic direction changes. Done poorly, reorgs destroy productivity and morale. Done well, they unlock new capabilities.
Here’s how to approach org restructuring thoughtfully.
When to Restructure
Valid Reasons
restructure_when:
misalignment:
- Org structure doesn't match product architecture
- Teams work on overlapping responsibilities
- Dependencies create constant coordination overhead
scale:
- Teams too large for effective management
- Communication overhead exceeds value
- Need to parallelize work
strategy_change:
- Company pivoting direction
- New product areas need dedicated focus
- Sunsetting areas need graceful transition
dysfunction:
- Persistent team conflicts
- Critical work falling through cracks
- Talent leaving due to structure
Invalid Reasons
dont_restructure_for:
new_leader:
- "I want to put my stamp on things"
- Stability has value; earn trust first
avoiding_problems:
- "Maybe a reorg will fix the conflict"
- Reorgs move problems, don't solve them
activity_theater:
- "We need to show we're doing something"
- Reorgs are costly; don't do them for optics
copying_others:
- "Company X is organized this way"
- What works for them may not work for you
Common Org Patterns
Team Topologies
team_patterns:
stream_aligned:
description: Teams aligned to flow of work (product, customer segment)
strengths: End-to-end ownership, customer focus
challenges: Potential duplication, platform gaps
platform:
description: Teams providing internal platforms/services
strengths: Reduce cognitive load, enable other teams
challenges: Risk of becoming bottleneck, needs product thinking
enabling:
description: Teams helping others adopt new capabilities
strengths: Spread knowledge, accelerate adoption
challenges: Temporary by nature, measuring impact
complicated_subsystem:
description: Teams owning complex specialist areas
strengths: Deep expertise where needed
challenges: Can become bottleneck, knowledge silos
Interaction Modes
interaction_modes:
collaboration:
what: Teams work together closely
when: Discovery phase, unclear boundaries
cost: High coordination overhead
x_as_a_service:
what: One team provides service to others
when: Clear interface, stable requirements
cost: Less flexibility, potential bottleneck
facilitating:
what: One team helps another build capability
when: Knowledge transfer, new technology adoption
cost: Temporary, needs clear exit criteria
Planning the Restructure
Discovery Phase
discovery_process:
understand_current_state:
- Map existing team structures
- Identify dependencies and interactions
- Survey team pain points
- Review delivery metrics
define_goals:
- What problem are we solving?
- What does success look like?
- What trade-offs are acceptable?
explore_options:
- Generate multiple structure options
- Evaluate against goals
- Consider transition costs
- Get input from affected leaders
Design Principles
design_principles:
clear_ownership:
- Every important area has single owner
- No gaps, no overlaps
- Decision rights are clear
sustainable_teams:
- 5-9 people per team (two-pizza)
- Sufficient skills for mission
- Clear growth path for members
minimized_dependencies:
- Teams can deliver independently
- Clear interfaces between teams
- Limited coordination required
aligned_to_value:
- Structure reflects value streams
- Customer focus visible in structure
- Business priorities reflected
Executing the Change
Communication
communication_approach:
before_announcement:
- Brief affected managers first
- Prepare FAQ
- Plan for questions
- Have transition details ready
announcement:
- Explain the why clearly
- Show new structure
- Acknowledge disruption
- Share timeline
follow_up:
- Individual conversations with affected
- Team meetings to address concerns
- Written documentation of changes
- Regular updates on transition
Transition Plan
transition_elements:
people_moves:
- Clear timeline for changes
- Manager assignments
- Physical/remote logistics
- Updated systems access
work_continuity:
- What happens to in-flight projects?
- Knowledge transfer plans
- Handoff documentation
- Temporary dual-membership if needed
new_team_formation:
- Team charter creation
- Relationship building time
- Process establishment
- Goals and metrics definition
Supporting People
people_support:
acknowledge_emotions:
- Change is hard
- Loss of team identity is real
- Uncertainty is stressful
- Allow processing time
provide_clarity:
- Clear role definitions
- Manager expectations
- Growth opportunities
- Success criteria
active_listening:
- One-on-ones to hear concerns
- Skip-levels for broader perspective
- Anonymous feedback channels
- Action on feedback
Common Pitfalls
What Goes Wrong
reorg_pitfalls:
poor_communication:
symptom: Rumors and anxiety
fix: Communicate early, clearly, honestly
ignoring_informal_networks:
symptom: Productivity drops unexpectedly
fix: Map actual collaboration, not just formal structure
underestimating_transition:
symptom: Extended productivity loss
fix: Plan for 3-6 month settling period
solving_wrong_problem:
symptom: Issues persist after reorg
fix: Diagnose root cause before restructuring
too_frequent_changes:
symptom: Change fatigue, cynicism
fix: Commit to stability, give structures time to work
neglecting_culture:
symptom: Values erode, morale drops
fix: Deliberately preserve and evolve culture
Measuring Success
Metrics
reorg_metrics:
short_term:
- Voluntary attrition rate
- Engagement survey scores
- Time to fill new roles
- Manager feedback
medium_term:
- Delivery velocity recovery
- Cross-team dependency issues
- Escalation frequency
- Team satisfaction
long_term:
- Business outcomes improved
- Strategic goals achieved
- Organizational health metrics
- Talent retention
Key Takeaways
- Restructure for real problems, not to “do something”
- Understand current state deeply before designing new state
- Use proven patterns (Team Topologies) as starting points
- Design for clear ownership, sustainable teams, minimal dependencies
- Communicate early, clearly, and honestly
- Plan for extended transition period (3-6 months)
- Support people through the change emotionally and practically
- Avoid frequent reorgs—commit to structures and give them time
- Measure success with both human and business metrics
- Preserve informal networks and culture intentionally
Restructuring is expensive. Do it rarely, do it thoughtfully, do it once.