Org Design

Org design is one of the highest-leverage things you will ever do as an engineering manager. Most managers think their job is managing people. It is. But the way you structure those people determines what your organization can build, how fast it can move, and how happy everyone is while doing it.

Get org design right and teams hum. Get it wrong and you spend all your time in coordination meetings wondering why nothing ships.

Why Org Design Matters

There is a law in software engineering that has been true since 1967 and will be true long after we are gone. It is called Conway's Law:

"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." — Melvin Conway

This is not a suggestion. It is a law of nature. If you have three teams working on a compiler, you will get a three-pass compiler. If you have a frontend team and a backend team, you will get a system with a thick API boundary between frontend and backend. If you have teams organized by geography, you will get services organized by geography.

This means org design is system design. When you draw boxes on an org chart, you are also drawing boxes on an architecture diagram. Whether you intend to or not.

The practical implication is powerful: if you want to change your architecture, you often need to change your org structure first. Trying to build a unified platform with three siloed teams will fail. Trying to build independent microservices with one monolithic team will also fail. The org and the architecture need to match.

This is why org design matters more than most managers realize. You are not just deciding who reports to whom. You are deciding what your system will look like in two years.

Team Topologies

The book Team Topologies by Matthew Skelton and Manuel Pais gave us a clean framework for thinking about team types. Before this book, most organizations had a mess of "teams" that nobody could categorize. Now we have four types, and they cover almost everything.

Stream-Aligned Teams

These are your feature teams. They are aligned to a stream of work — a product, a user journey, a business domain. They own something end-to-end and can deliver value independently.

A stream-aligned team working on checkout owns the checkout experience from the frontend button to the payment processing. They do not need to file tickets with three other teams to ship a feature.

This is the default team type. Most of your teams should be stream-aligned. If you are starting from scratch, start here.

When to use: Almost always. This is your bread and butter.

Platform Teams

Platform teams exist to make stream-aligned teams faster. They build internal platforms — infrastructure, developer tools, CI/CD pipelines, shared services — so that stream-aligned teams do not have to solve the same problems over and over.

A good platform team treats other engineering teams as their customers. They provide self-service tools. They do not become a bottleneck. If stream-aligned teams have to file tickets and wait for the platform team to do work for them, the platform team has failed.

When to use: When you have enough stream-aligned teams (usually 4+) that common infrastructure work is being duplicated. Before that, it is overhead.

Enabling Teams

Enabling teams are temporary or semi-permanent teams that help other teams adopt new capabilities. Think of them as internal consultants. They might help teams adopt a new testing framework, migrate to a new database, or improve observability practices.

The key distinction: enabling teams do not do the work for other teams. They teach and coach. They work themselves out of a job.

When to use: When you need to spread a new capability across multiple teams and it is too complex for a document or a lunch-and-learn.

Complicated-Subsystem Teams

These teams own a piece of the system that requires deep specialist knowledge — a machine learning model, a video encoding pipeline, a financial calculation engine. The math or science is hard enough that you need dedicated experts.

When to use: Rarely. Only when the subsystem genuinely requires specialist knowledge that you cannot expect a stream-aligned team to maintain. Do not create these just because something is "hard." Create them because the domain knowledge is genuinely specialized.

Putting It Together

A typical mid-size engineering org might look like: 6 stream-aligned teams, 1 platform team, 1 enabling team working on observability adoption, and 1 complicated-subsystem team for the ML recommendation engine. That is 9 teams covering a lot of ground with minimal coordination overhead.

Team Size

The two-pizza rule exists for a reason. Jeff Bezos popularized the idea that a team should be small enough to be fed by two pizzas. In practice, this means 4 to 8 engineers is the sweet spot.

Here is why.

Communication overhead scales quadratically. The number of communication channels in a team of n people is n(n-1)/2. For a team of 5, that is 10 channels. For a team of 10, that is 45. For a team of 15, that is 105. You can feel this. A standup with 5 people takes 10 minutes. A standup with 15 people takes 40 minutes and nobody is listening.

Too small (1-3 engineers):

Fragile. One person on vacation and the team is at half capacity or worse.
Limited skill diversity. You need at least a few people to cover frontend, backend, and infrastructure.
Hard to sustain on-call rotations.
Bus factor is dangerously low.

Just right (4-8 engineers):

Enough people to cover multiple skill areas.
Small enough that everyone knows what everyone else is working on.
Sustainable on-call rotations.
Standups are fast. Planning is efficient.
One manager can effectively support the team.

Too big (9+ engineers):

Communication overhead explodes.
The manager cannot give everyone adequate attention.
Subgroups form naturally, which means you effectively have two teams pretending to be one.
Decision-making slows down.
Standups become status meetings where most people zone out.

When a team hits 9 or 10 people, start thinking about splitting. When it hits 12, you are already late.

Span of Control

Span of control is how many direct reports a manager has. This is a different question from team size, because a manager might have engineers plus tech leads plus other managers reporting to them.

For engineering managers managing individual contributors: 5-8 direct reports.

At 5, you have enough time for meaningful 1:1s, career development conversations, and still contribute to technical discussions. At 8, you are busy but functional. Above 8, something starts to drop — usually career development or technical involvement.

For managers of managers (directors): 4-6 direct reports.

Managing managers is more cognitively demanding. Each direct report represents an entire team's worth of context. You need to understand what each team is doing, help each manager grow, and coordinate across teams. 4-6 is the range where you can do this well.

How this affects org depth:

If you have 50 engineers and each manager has 7 direct reports, you need about 7 managers. If each director has 5 managers reporting to them, you need about 2 directors. That gives you a three-level org: Director -> Manager -> Engineer.

If you artificially keep the org flat with 15 direct reports per manager, your managers will be overwhelmed and your engineers will be under-supported. If you go too deep with 3 direct reports per manager, you have too many managers and too many layers of communication.

Flat vs. Deep:

Flat orgs (wide span of control) move faster on decisions because there are fewer layers. But they put enormous pressure on managers and tend to under-invest in people development.

Deep orgs (narrow span of control) provide better support for individuals but slow down communication and decision-making. Information gets filtered and distorted as it passes through layers.

The right answer is somewhere in the middle, and it depends on the maturity of your team. Senior, autonomous teams can tolerate wider spans. Junior teams need narrower spans and more hands-on management.

Team Splits and Merges

Teams are not permanent. As your product and organization grow, you will need to split teams and occasionally merge them. Both are disruptive if done poorly and energizing if done well.

When to Split a Team

The team is too big. More than 8-9 engineers. This is the most common trigger.
The team owns too many things. If a team owns three unrelated services and context-switches constantly, it is effectively three teams sharing a manager. Make it official.
The team has two distinct workstreams. If half the team works on feature A and the other half works on feature B, and they rarely interact, split them.
Priorities conflict. If the team constantly argues about whether to work on project X or project Y, it might be because X and Y should be owned by different teams with different priorities.

When to Merge Teams

The teams are too small. Two teams of 3 engineers each are both fragile. Merge them into one team of 6.
The teams always work together. If two teams cannot ship anything without coordinating with each other, they might be one team split artificially.
One team has lost its purpose. Sometimes a team's domain shrinks or a product gets deprecated. Rather than keep a team alive for maintenance, merge them into a related team.

How to Do It Without Breaking Everything

Decide ownership boundaries first. Before you announce anything, figure out exactly which services, codebases, and responsibilities go where. Ambiguity during a split is toxic.
Talk to the tech leads and senior engineers first. They will have opinions about where the natural seams are. Listen to them. They know where the code boundaries are better than you do.
Communicate the "why" clearly. People need to understand why this is happening. "We are splitting because the team is too big and we cannot move fast enough" is a good reason. "Because I read a blog post" is not.
Give it time. A newly split or merged team will be slower for 4-6 weeks as they figure out new processes, build relationships, and establish ownership. Do not panic. Do not re-split. Let it settle.
Move people thoughtfully. Do not just draw a line down the middle. Consider who works well together, who has domain knowledge, who wants to grow in a new area. This is a chance to be intentional about team composition.

Ownership and Boundaries

This is the single most important principle in org design:

Every service, every feature, every system should have exactly one team that owns it.

Not two teams. Not "shared." Not "it depends." One team.

Shared ownership is no ownership. When two teams own something, neither team prioritizes it. Bugs sit unfixed because each team thinks the other team will handle it. Technical debt accumulates because neither team budgets time for it. Incidents happen and there is a 10-minute delay while people figure out who should respond.

Clear ownership means:

One team is on-call for it. When it breaks at 2am, there is no ambiguity about who gets paged.
One team makes technical decisions about it. No design-by-committee across teams.
One team prioritizes work on it. The product manager and engineering manager for that team decide what gets built and when.
One team is accountable for its health. Uptime, performance, code quality — one team owns the outcomes.

When drawing team boundaries, optimize for minimal cross-team dependencies. The fewer handoffs between teams required to ship a feature, the faster you move. If shipping a single user-facing feature requires coordinating across 4 teams, your boundaries are wrong.

A useful exercise: list your top 10 product priorities for the quarter. For each one, count how many teams need to coordinate to deliver it. If the average is more than 1.5, your team boundaries need work.

Reorg Planning

Sometimes you need a reorg. Teams have grown, products have changed, the org structure no longer matches the architecture you want. A reorg is the right tool — but it is a blunt one, and it comes with real costs.

When a Reorg Is Actually Needed

The current structure is actively slowing delivery.
Teams are constantly blocked on each other.
Ownership is unclear and causing incidents or quality issues.
You have grown significantly (doubled the team) and the old structure does not scale.
Your product strategy has fundamentally shifted and teams are organized around the old strategy.

A reorg is NOT needed when:

You have a new VP who wants to "put their stamp" on things.
One team is underperforming (that is a management problem, not a structure problem).
You read a book and got excited (give it a month, the excitement will fade).

How to Plan a Reorg

Start with the desired outcomes. What does success look like? "Teams can ship independently" or "Every service has clear ownership" or "We can support three new product lines." Write this down. If you cannot articulate the outcomes, you are not ready.
Draft the new structure. Draw the new org chart. List every team, its mission, its ownership, and its members. Identify every service and system and assign it to exactly one team.
Pressure-test it. Take your top 10 product priorities and map them to the new structure. Can each one be delivered with minimal cross-team coordination? If not, iterate.
Socialize with key leaders first. Share the plan with your fellow managers, directors, and tech leads before announcing it broadly. Get their feedback. They will catch things you missed. They will also feel respected and included, which matters.
Communicate the change. Be transparent about what is changing, why, and when. Give people a clear timeline. Share the new org chart. Answer questions honestly.
Execute quickly. Once you announce, move fast. The worst thing is a slow-motion reorg where people sit in limbo for weeks. Rip the bandaid off. Change Slack channels, update on-call rotations, reassign JIRA boards — do it all in the first week.

The Reorg Hangover

Every reorg comes with a productivity dip. Plan for it. Expect 2-3 months of reduced velocity while teams:

Build new relationships and trust.
Learn new codebases and systems.
Establish new processes and norms.
Mourn the old team (this is real — people get attached).

Do not schedule an aggressive product milestone for the quarter after a reorg. Give teams space to get their footing. The payoff comes in months 4-6, when the new structure starts to click and teams move faster than they did before.

Real-World Examples

Scenario 1: Team Split That Unlocked Velocity

A payments team of 11 engineers owned everything from the checkout UI to payment processing to fraud detection. They were constantly context-switching. Sprint planning was a negotiation between three competing priorities. Features took twice as long as estimated because engineers kept getting pulled into unrelated fires.

The manager split the team into two: a Checkout team (5 engineers, owned the checkout UI and payment orchestration) and a Risk team (6 engineers, owned fraud detection and payment compliance). Each team got a clear mission and distinct ownership.

The first month was rough. Both teams felt understaffed and the Risk team had to learn parts of the codebase they had not touched before. But by month three, both teams were shipping faster than the original team of 11 had been. Sprint commitments were being met. Engineers reported feeling more focused and less stressed. The checkout conversion rate improved because the Checkout team could finally dedicate sustained attention to it.

Scenario 2: Reorg That Went Wrong

A VP joined a 60-person engineering org and decided to reorganize from product-aligned teams to technology-layer teams (frontend, backend, data). The rationale was "consistency" — all frontend engineers should work together to ensure consistent UI patterns, all backend engineers should share knowledge.

Within two months, everything slowed to a crawl. Shipping a single feature now required coordination across the frontend team, the backend team, and the data team. Ticket handoffs tripled. Each team blamed the other for delays. The frontend team built components that the backend team had not built APIs for. The data team was constantly blocked on schema changes that required backend team cooperation.

Six months later, the org quietly reorged back to product-aligned teams. They lost nearly a year of velocity. The lesson: Conway's Law is not optional. You cannot organize by technology layers and expect to deliver product features quickly. The org structure creates the communication patterns, and the communication patterns create the architecture. Fight this at your peril.

Scenario 3: Team Topology Change That Reduced Cross-Team Dependencies

An e-commerce company had six stream-aligned teams and no platform team. Each team managed its own infrastructure: its own Kubernetes configs, its own CI/CD pipelines, its own monitoring setup. Engineers spent roughly 25% of their time on infrastructure tasks, and every team did it slightly differently.

The engineering director created a platform team of 4 engineers, pulled from volunteers across the six teams. The platform team built a standardized deployment pipeline, a shared monitoring stack, and internal tooling that abstracted away Kubernetes complexity.

Within six months, the time stream-aligned teams spent on infrastructure dropped from 25% to about 5%. That freed up roughly 20% more capacity across six teams for product work. Cross-team dependencies actually decreased because teams no longer needed to ask each other how they solved infrastructure problems — the platform team had a standard solution.

The key to success: the platform team treated the other teams as customers. They did user research (internal surveys, shadowing engineers). They built self-service tools. They never became a ticket queue.

Common Mistakes

Reorging too frequently. If you reorg more than once a year, you are not giving any structure enough time to work. Every reorg costs 2-3 months of productivity. Reorg twice a year and you have spent half the year in transition. Your teams will develop "reorg fatigue" and stop investing in their team identity because they expect it to change again soon.

Unclear ownership. "Team A and Team B both own this service" is a recipe for disaster. Fight hard for clear, unambiguous ownership. If two teams need to collaborate on something, designate one as the owner and the other as a contributor.

Teams too big. Managers often resist splitting teams because it means finding (or developing) another manager. Do not let org constraints drive team design. If a team needs to split, figure out the management problem separately.

Ignoring Conway's Law. Your org structure will shape your architecture whether you like it or not. Work with this force, not against it. Design your teams around the architecture you want, not the architecture you have.

Not communicating the "why." People can handle change. What they cannot handle is change without explanation. "We are reorging because our current structure creates too many cross-team dependencies and it is slowing us down" is something people can understand and get behind. "We are reorging" with no explanation breeds anxiety and cynicism.

Optimizing for the current quarter. Org design should optimize for the next 12-18 months, not the next sprint. Do not reshape teams around a single project. Shape teams around enduring product domains and let them take on projects that fit their domain.

Copying another company's structure. Spotify's model worked for Spotify. Google's model works for Google. Your org is different — different product, different stage, different people, different culture. Learn from others but design for your own context.

Business Value

Org design is not an academic exercise. It directly impacts the bottom line. Here is how.

Velocity impact. Well-designed teams ship faster. When a team can deliver a feature end-to-end without waiting on other teams, cycle time drops dramatically. Teams with clear ownership and right-sized membership routinely ship 2-3x faster than teams that are too large or have tangled dependencies.

Reduced coordination cost. Every cross-team dependency is a coordination cost — meetings, Slack threads, ticket handoffs, waiting. Good org design minimizes these dependencies. Fewer dependencies means less time spent coordinating and more time spent building. In a well-structured org, engineers spend 70-80% of their time on direct product work. In a poorly structured one, that number can drop below 50%.

Clearer ownership. When ownership is unambiguous, accountability follows. Teams that own something take pride in it. They fix bugs faster, invest in quality, and think long-term about the health of their systems. This reduces incidents, improves reliability, and lowers maintenance costs over time.

Faster delivery. All of the above compounds into faster delivery. Features ship sooner. Customer feedback loops tighten. The business can respond to market changes more quickly. In competitive markets, this is the difference between leading and following.

Talent retention. Engineers want to work on teams that ship. They want clear ownership, manageable scope, and the autonomy to make decisions. Good org design provides all of this. Bad org design — unclear ownership, constant reorgs, too many dependencies — drives your best people away.

The return on getting org design right is enormous. A well-structured 50-person engineering org will outperform a poorly structured 80-person org. Structure is a multiplier, and it works in both directions.

Common Pitfalls

Reorging too frequently. If you reorganize more than once a year, you are not giving any structure enough time to work. Every reorg costs two to three months of productivity, and frequent changes cause teams to develop "reorg fatigue" and stop investing in their identity.
Ignoring Conway's Law. Your org structure will shape your system architecture whether you intend it to or not. Trying to build a unified platform with siloed teams, or independent microservices with a monolithic team, will fail because you are fighting a force of nature.
Allowing unclear or shared ownership. When two teams own a service, neither team prioritizes it. Bugs sit unfixed, tech debt accumulates, and incidents trigger a 10-minute delay while people figure out who should respond. Every system needs exactly one owning team.
Keeping teams too large instead of splitting. Managers often resist splitting teams because it means finding another manager. But a team of 12 has communication overhead that destroys focus and slows decision-making. Do not let org constraints drive team design.
Copying another company's org structure. Spotify's model worked for Spotify. Google's model works for Google. Your organization has a different product, stage, team, and culture. Learn from others but design for your own context.
Not communicating the "why" behind structural changes. People can handle change, but they cannot handle change without explanation. Announcing a reorg without clearly articulating the reasons breeds anxiety, cynicism, and resistance.

Key Takeaways

Conway's Law is real. Your org structure will become your system architecture. Design accordingly.
Default to stream-aligned teams. Add platform, enabling, and complicated-subsystem teams only when you have a clear reason.
Keep teams at 4-8 engineers. Split when they get bigger. Merge when they get too small.
Managers should have 5-8 direct reports. More than that and quality suffers.
Every system needs exactly one owning team. Shared ownership is no ownership.
Reorgs cost 2-3 months of productivity. Do them only when the current structure is actively hurting you, and do them decisively.
Always communicate the "why" behind structural changes. People deserve to understand the reasoning.
Org design is system design. Treat it with the same rigor you would treat a major architectural decision.