How do you design org and team structure?

Question

IT Interview Practice · Accepted Answer

Org design is about **drawing team boundaries so that the work that changes together lives together** — minimizing cross-team dependencies for the things that move fast. Structure should follow strategy and the system, not the other way around.

## Principles

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Stream-aligned thinking

Favor long-lived, stream-aligned teams that own a flow of work, supported by platform teams that reduce others' cognitive load. Reorganize when the structure starts fighting the work — not on a whim.

## Pitfalls

- **Functional silos** (a "QA team," a "frontend team") that force every feature to cross many handoffs.
- **Ignoring Conway's Law** and being surprised the architecture mirrors the org chart.
- **Reorganizing constantly**, which resets trust and ownership each time.
- **Fuzzy ownership**, where everything is "shared" and therefore owned by no one.

## Why it matters

Structure quietly determines speed.

Bad boundaries create endless coordination meetings and blurred accountability; good ones let teams move independently.

Because of Conway's Law, org design *is* architecture design.

Get the team boundaries wrong and no amount of engineering heroics will make the system clean.

Principles

Stream-aligned thinking

Pitfalls

Why it matters

Related questions