Organisational design is the art of structuring teams to maximise their ability to deliver value. How you draw team boundaries, define responsibilities, and manage dependencies determines your engineering organisation's speed, quality, and resilience. This guide covers how engineering managers approach organisational design thoughtfully.
Why Organisational Design Matters
Conway's Law states that organisations design systems that mirror their communication structures. This means your team structure directly shapes your software architecture, and vice versa. A misalignment between team boundaries and system boundaries creates coordination overhead that slows delivery and increases the risk of integration failures.
Good organisational design enables teams to work autonomously on meaningful scope while remaining aligned on shared goals. Poor organisational design creates dependencies that require constant coordination, blurs accountability, and generates friction that consumes engineering energy better spent on building.
- Conway's Law: team structure shapes software architecture
- Good design enables autonomy and reduces coordination overhead
- Poor design creates dependencies, blurred accountability, and friction
- Organisational design is a continuous practice, not a one-time decision
Understanding Team Topologies
The Team Topologies framework identifies four fundamental team types: stream-aligned teams (focused on a flow of work aligned to a business domain), platform teams (providing internal services that accelerate stream-aligned teams), enabling teams (helping other teams adopt new capabilities), and complicated subsystem teams (owning complex components that require specialist knowledge).
Most engineering organisations should be composed primarily of stream-aligned teams, supported by a smaller number of platform and enabling teams. The key design decision is how to define the streams - by product area, customer segment, business capability, or user journey. The right answer depends on your organisation's strategy, technical architecture, and where coordination overhead is highest.
When designing team boundaries, optimise for minimising cross-team dependencies. Each team should be able to deliver end-to-end value without waiting for other teams. This is often called 'loose coupling and high cohesion' - the same principle that governs good software design applies to organisational design.
Sizing and Structuring Teams
The ideal engineering team size is five to eight engineers plus a manager. Below five, the team lacks resilience and breadth of skills. Above eight, communication overhead increases exponentially and the manager cannot maintain meaningful one-on-one relationships with each team member.
Within teams, define clear roles without over-specifying responsibilities. A tech lead who owns technical direction, a product manager who owns priorities, and an engineering manager who owns people and process is a common and effective structure. Avoid creating so many roles that coordination within the team becomes the primary activity.
- Optimal team size is five to eight engineers plus a manager
- Below five, teams lack resilience; above eight, coordination overhead dominates
- Define clear roles without creating bureaucratic overhead
- Cross-functional teams reduce external dependencies and increase autonomy
Managing Reorganisations
Reorganisations are one of the most disruptive events a team can experience. When a reorganisation is necessary - and sometimes it genuinely is - plan it carefully. Define the new structure before announcing the change. Communicate the reasoning clearly and honestly. Provide support for engineers who are moving to new teams or managers.
Expect a three-to-six-month adjustment period after any significant reorganisation. During this time, productivity will drop, relationships will need rebuilding, and new processes will need to be established. Factor this cost into your decision about whether to reorganise - the expected benefits must outweigh the disruption cost.
Common Organisational Design Mistakes
The most common mistake is reorganising too frequently. Each reorganisation incurs a significant productivity cost, and teams need stability to build the relationships and norms that enable high performance. Reorganise only when the current structure is clearly preventing the organisation from achieving its goals, not because a new leader wants to put their stamp on things.
Another frequent error is designing teams around individuals rather than capabilities. When a star engineer leaves, a team designed around their unique skills often collapses. Design teams around the capabilities needed and hire to fill those capabilities. This creates resilient structures that survive personnel changes.
Key Takeaways
- Team structure shapes software architecture - align them deliberately
- Optimise team boundaries to minimise cross-team dependencies
- Size teams at five to eight engineers for the best balance of resilience and efficiency
- Reorganise only when clearly necessary and plan for the adjustment period
- Design teams around capabilities, not individuals
Frequently Asked Questions
- How do I know when a reorganisation is needed?
- Look for persistent structural friction: teams that cannot deliver without constant coordination, unclear ownership that causes work to fall through the cracks, or team boundaries that no longer align with the company's strategic priorities. If these problems persist despite process improvements, the structure itself may be the issue. Reorganise as a last resort after exhausting less disruptive alternatives.
- Should teams be organised by technology or by product area?
- In most cases, organise by product area (stream-aligned teams). This gives teams end-to-end ownership and reduces the coordination overhead of shipping a feature. Technology-aligned teams (frontend team, backend team, data team) create handoff points that slow delivery and blur accountability. Reserve technology-aligned structures for true platform or infrastructure capabilities that serve many product teams.
- How do I handle the transition when splitting a team into two?
- Plan the split carefully. Define the scope of each new team before announcing the change. Discuss the split with affected engineers individually before the group announcement. Allow engineers to express preferences about which team they join, even if you cannot honour every preference. Invest in the new team's identity - help them establish their own rituals, goals, and norms rather than simply inheriting everything from the original team.
Explore Team Design Frameworks
Access team topology guides, organisational design frameworks, and reorganisation planning templates designed for engineering managers structuring teams for high performance.
Learn More