Org Design¶

Your org chart is not neutral. It shapes what gets built, how fast you can move, and where friction accumulates.

Organizational structure is often treated as an HR concern—boxes and lines on a diagram. But for engineering leaders, it's a core tool. The way you draw boundaries between teams determines communication paths, decision rights, dependencies, and ultimately what's easy and what's hard to accomplish.

This document is not a summary of Team Topologies or other frameworks. It's about how to think about organizational shape: when structure is the problem, how to recognize symptoms of bad boundaries, when to reorganize, and when not to.

What problem this solves¶

Without intentional org design:

• Teams optimize locally but create system-wide drag.
• Dependencies slow everyone down.
• Decision rights are unclear—everything escalates.
• Communication overhead grows faster than headcount.
• Reorgs happen reactively, not strategically.
• People don't know who owns what.

Structure is invisible until it's wrong. Then it's the only thing you can see.

When to use this¶

Read this when:

• Cross-team work feels consistently hard.
• You're unsure whether a problem is people or structure.
• You're considering a reorganization.
• Your team is growing and current structure won't scale.
• Decision-making has slowed down without clear reason.
• You're designing a new team or splitting an existing one.

This is not about:

• Reporting relationships and management spans (though they're related).
• Career ladders or role definitions.
• Specific frameworks like Team Topologies (though those are useful inputs).

How structure shapes behavior¶

Conway's Law isn't just an observation—it's a design tool. Your organization will produce systems that mirror its communication structure. If you want different systems, you may need different structure.

Structure determines¶

What's easy:

• Work that stays within a single team is fast.
• Decisions that fall within clear ownership get made.
• Communication within a team is low-friction.

What's hard:

• Work that crosses team boundaries requires coordination.
• Decisions that span unclear ownership stall.
• Communication across teams requires effort and can lose fidelity.

The implication: When you design org structure, you're deciding what will be easy and what will be hard. Choose intentionally.

The core principles¶

Principle 1: Boundaries should reflect cognitive load¶

A team can only hold so much context in their heads. If a team needs to understand too many things to do their work, they'll either slow down or cut corners.

Signs of excessive cognitive load:

• Teams need to understand systems they don't own.
• Context-switching is constant.
• Onboarding takes months because there's too much to learn.
• Expertise is spread thin across too many domains.

The fix: Draw boundaries so teams can be experts in their domain without needing expertise in everything adjacent.

Principle 2: Dependencies should be minimized, not managed¶

If two teams need to coordinate constantly, something is wrong with the boundary between them. Either they should be one team, or the boundary should move.

Signs of excessive dependencies:

• Work is blocked waiting for another team.
• Meetings exist primarily for coordination, not collaboration.
• Roadmaps are coupled—one team can't plan without the other.
• Releases require synchronization across teams.

The fix: Redraw boundaries so the most common work streams stay within teams. Move the dependency inside or architect it away.

Principle 3: Ownership should be unambiguous¶

Every system, service, and domain should have exactly one owner. Shared ownership means no ownership.

Signs of ambiguous ownership:

• When something breaks, there's debate about who fixes it.
• Improvements don't happen because everyone thinks someone else owns it.
• Multiple teams make changes to the same code or service.
• "Who owns this?" is a frequently asked question.

The fix: Assign clear ownership. If two teams have legitimate claims, that's a signal to reconsider the boundary.

Principle 4: Communication paths should match work flows¶

Information needs to flow where work flows. If the work requires constant communication between teams, but the org structure doesn't support that, you've created friction.

Signs of mismatched communication:

• Work happens in informal channels that bypass official structure.
• Information gets lost crossing team boundaries.
• Meetings multiply to compensate for structural gaps.
• People route around the org chart to get things done.

The fix: Either change the structure to match the work, or change the work to match the structure. The mismatch is the problem.

Symptoms of structural problems¶

Before you reorganize, make sure structure is actually the problem. Here's how to tell.

The coordination tax¶

What it looks like: Simple work takes forever because it crosses boundaries.

Example: A feature requires changes to three services owned by three teams. Each team has their own priorities. The feature takes a quarter instead of a sprint.

Questions to ask:

• Is this work pattern common or rare?
• If common, why isn't it inside one team's boundary?
• What would need to change to eliminate the coordination?

The decision vacuum¶

What it looks like: Decisions stall because no one knows who's responsible.

Example: A technical choice affects multiple teams. Each team has opinions, but no one has authority. The decision goes up to a leader who lacks context.

Questions to ask:

• Who should own this decision?
• What's preventing clear ownership?
• Is this a gap in the structure or a gap in accountability?

The ownership fight¶

What it looks like: Teams compete for control of a domain or system.

Example: Two teams both think they should own the notification service. They clash over design decisions and roadmap priorities.

Questions to ask:

• Why do two teams have overlapping claims?
• Is the domain actually coherent, or should it be split?
• What would need to change for ownership to be clear?

The ghost dependency¶

What it looks like: A team seems autonomous but actually depends on another team's undocumented decisions.

Example: Team A builds features assuming Team B's API will behave a certain way. Team B changes the API without knowing Team A depends on it.

Questions to ask:

• Are dependencies explicit and managed?
• Should this dependency be eliminated or formalized?
• Is there a missing interface or contract?

The silo symptom¶

What it looks like: Teams don't talk to each other. Each optimizes locally, but global outcomes suffer.

Example: Platform team builds infrastructure they think product teams need. Product teams work around it because it doesn't match their actual needs.

Questions to ask:

• What's preventing cross-team communication?
• Are incentives aligned, or does each team have different success metrics?
• Is there a structural barrier or a relationship barrier?

When to reorganize¶

Reorgs are disruptive. They cause confusion, anxiety, and productivity loss. Don't reorg unless the benefits clearly outweigh the costs.

Reorganize when¶

• Structural problems are chronic. The same issues recur despite process improvements and good intentions.
• Work patterns have fundamentally changed. The work that needs to happen no longer matches how teams are organized.
• Growth requires new structure. The current structure worked at 20 people but won't work at 60.
• Clear ownership is impossible under current boundaries. No amount of clarification fixes ambiguous domains.

Don't reorganize when¶

• The problem is people, not structure. Rearranging boxes won't fix trust issues, skill gaps, or poor leadership.
• You're hoping structure will solve undefined problems. If you can't name what's wrong, a reorg won't fix it.
• The disruption cost exceeds the benefit. Some structural friction is acceptable if the change cost is high.
• You've recently reorganized. Give changes time to settle before concluding they didn't work.

Designing good boundaries¶

When you do design or redesign structure, here's what to optimize for.

Start with work, not people¶

Ask: What work needs to happen? What are the natural clusters? What crosses boundaries frequently? Then design structure to fit the work.

Don't start with: How do we organize these people? That leads to structure that fits current people, not current work.

Minimize cross-boundary work¶

For the most common, most critical work streams, the work should stay inside one team. Reserve cross-boundary coordination for exceptional cases.

Make ownership explicit¶

For every system, service, and domain, answer: Who owns this? Who makes decisions about it? Who's on call for it? If you can't answer clearly, the boundary isn't clear.

Plan for evolution¶

Structure is not permanent. Build in mechanisms for revisiting: regular org health reviews, explicit triggers for reconsidering boundaries, willingness to iterate.

Consider interaction modes¶

Teams don't just exist—they interact. Consider how:

Different work patterns need different interaction modes. Structure should support the modes you need.

What good looks like¶

Well-designed organization structure:

• Work flows within teams. Most work completes without cross-team coordination.
• Ownership is clear. Everyone knows who owns what. Debates are rare.
• Dependencies are explicit. Where teams depend on each other, it's known and managed.
• Decisions happen at the right level. Teams have authority over their domain. Escalation is rare.
• Communication matches work. Information flows where it needs to without fighting the structure.
• Structure evolves. The organization periodically reviews whether structure still fits work patterns.

Signs you're on the right track:

• New team members can understand who owns what within their first month.
• Cross-team projects are the exception, not the norm.
• Teams can make most decisions without escalating.
• Reorgs are infrequent and strategic, not reactive and disruptive.

Copy-pastable artifact: Org health diagnostic¶

# Org Health Diagnostic

Use this quarterly to assess whether structure is serving or hindering your teams.

## Dependency check

- What cross-team dependencies exist?
  [List]
- Which are working well?
  [List]
- Which cause regular friction?
  [List]
- Can any be eliminated or restructured?
  [Reflection]

## Ownership check

- Are there domains with unclear ownership?
  [Yes/No — if yes, list them]
- Are there domains with overlapping ownership?
  [Yes/No — if yes, list them]
- When was the last ownership dispute?
  [Description]

## Communication check

- Is important information flowing where it needs to?
  [Observations]
- Are there informal channels routing around official structure?
  [Observations]
- What meetings exist primarily for coordination?
  [List]

## Decision check

- Are decisions happening at the right level?
  [Yes/No — examples]
- What decisions are stalling due to unclear ownership?
  [List]
- What decisions are escalating unnecessarily?
  [List]

## Load check

- Are any teams overloaded with cognitive load?
  [Observations]
- Do teams have clear, focused missions?
  [Yes/No — exceptions]

## Structural change consideration

Based on this assessment:

- [ ] Structure is working. No changes needed.
- [ ] Minor adjustments needed. [Describe]
- [ ] Significant structural issues. Deeper review needed.

## Next steps

| Issue | Proposed action | Owner | Due |
| ----- | --------------- | ----- | --- |
|       |                 |       |     |

Further reading¶

• Team Topologies by Matthew Skelton & Manuel Pais — The standard reference for modern org design in tech.
• An Elegant Puzzle by Will Larson — Practical wisdom on engineering organization.
• Thinking in Systems by Donella Meadows — Systems thinking that applies to org design.
• Dynamic Reteaming by Heidi Helfand — How to change team composition thoughtfully.

Related pages¶

• Scaling Teams — How structure changes as you grow.
• Scaling Systems — Technical architecture and org structure are linked.
• Decision Making & ADRs — How decisions get made within and across teams.
• Working Agreements — Explicit norms for how teams interact.
• Platform Themes — Platform teams as a specific org pattern.