Team Structure & Org Design

Your org chart is your first architecture decision. Conway’s law guarantees your system’s communication patterns will mirror your team boundaries — so design teams intentionally or accept accidental architecture.

Conway’s Law — The Inescapable Force

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” — Melvin Conway, 1967

This is not a suggestion. It is an empirical observation that has held for 50+ years. The inverse is equally powerful:

Inverse Conway Maneuver: Deliberately structure your teams to produce the architecture you want. If you want loosely coupled microservices, you need loosely coupled teams with clear ownership boundaries.

How This Plays Out in a 16-Person Cross-Functional Team

With 16 engineers across frontend, backend, QA, and data, the structural decisions you make directly shape what you can build:

Structure	Architecture You Get	Failure Mode
Discipline-aligned (FE team, BE team, QA team)	Layered architecture with thick API contracts	Handoff delays, “throw it over the wall” QA
Feature-aligned (cross-functional squads)	Vertical slices, independent deployability	Duplication, divergent standards
Hybrid (squads + thin discipline chapters)	Vertical slices with horizontal standards	Matrix confusion if chapter leads have authority without accountability

The right answer depends on your deployment model and product architecture. If your 16 engineers own 2-3 distinct product areas, feature-aligned squads make sense. If they all contribute to one monolith, discipline alignment might be pragmatically correct while you decompose.

---

Team Topologies — The Four Fundamental Types

Skelton and Pais (2019) codified four team types that, when combined, cover all legitimate team structures. Anything else is usually a sign of organizational debt.

1. Stream-Aligned Team

Purpose: Aligned to a single flow of work — a product, feature set, user journey, or business domain.

Characteristics:

• Cross-functional: has all skills needed to deliver end-to-end (FE, BE, QA, data)
• Owns the full lifecycle: build, deploy, run, monitor
• Sized 5-9 people (two-pizza rule, backed by Dunbar’s research on working groups)
• Has a clear mission tied to business outcomes, not technical components

When it works: When product areas are well-defined and loosely coupled. Spotify’s squads (before they abandoned the model publicly) and Amazon’s two-pizza teams are the canonical examples.

When it breaks: When the “stream” is too broad (team becomes a mini-org with internal dependencies) or too narrow (team lacks enough work to stay engaged).

At MMS scale (16 engineers): Two stream-aligned squads of 6-7 engineers each, plus a 2-3 person enabling or platform function, is a natural decomposition. Each squad owns a distinct product area end-to-end.

2. Platform Team

Purpose: Provide internal services that reduce cognitive load for stream-aligned teams.

Characteristics:

• Treats stream-aligned teams as customers
• Provides self-service capabilities (CI/CD, observability, infrastructure)
• Success measured by adoption and friction reduction, not feature delivery
• Small: typically 3-5 people even in large orgs

The critical mistake: Building a platform team that becomes a bottleneck. If stream-aligned teams need to file tickets and wait for the platform team, you have created a dependency, not a platform. The litmus test: can stream-aligned teams self-serve 80%+ of their needs?

Real examples:

• Spotify’s infrastructure teams provided Backstage as a self-service developer portal
• Netflix’s platform team built tools (Spinnaker, Zuul) that product teams consumed without coordination
• At 16 engineers, a dedicated platform team is usually premature — but one engineer spending 30% on platform concerns (CI/CD, shared tooling) is essential

3. Enabling Team

Purpose: Help stream-aligned teams acquire new capabilities without creating dependencies.

Characteristics:

• Temporary engagement model: coach, don’t do
• Specialists in areas like security, performance, observability, or new technology adoption
• Success means the stream-aligned team no longer needs them
• Anti-pattern: becoming a permanent crutch or a “center of excellence” that hoards knowledge

At MMS scale: When adopting the AI platform, an enabling function (could be a principal engineer + one other) that pairs with squads to build AI capabilities into their domains, then moves on.

4. Complicated-Subsystem Team

Purpose: Own a component that requires deep specialist knowledge most engineers don’t have.

Characteristics:

• Exists because the cognitive load of the subsystem would overwhelm a stream-aligned team
• Examples: ML model serving, real-time data pipeline, payment processing engine
• Should be rare — most organizations need zero or one of these

At MMS scale: If your AI platform involves a genuinely complex ML pipeline or agent orchestration layer, a 2-3 person complicated-subsystem team that owns that layer while stream-aligned teams consume its APIs is legitimate.

---

Interaction Modes

Team Topologies defines three interaction modes between teams. Getting these wrong creates organizational friction:

Mode	Description	Duration	Example
Collaboration	Two teams work closely together on a shared goal	Temporary (weeks to months)	Stream team + enabling team adopting new observability stack
X-as-a-Service	One team provides, other team consumes via API/interface	Permanent	Platform team provides CI/CD; stream teams consume it
Facilitating	One team coaches another to build new capability	Temporary	Enabling team teaching stream team performance testing

The trap: Defaulting to collaboration for everything. Collaboration is expensive — it requires high-bandwidth communication and synchronization. Reserve it for genuinely novel problems. Most interactions should be X-as-a-Service.

---

Span of Control

The Numbers

Span	Context	Why
3-5	New manager, complex domain, senior ICs needing career growth	Deep coaching, high-context work
5-7	Experienced manager, established teams	Standard operating range
7-10	Stable teams, autonomous engineers, manager is not also IC	Possible but leaves little room for strategic work
10+	Flat org with strong tech leads	Manager becomes a coordinator, not a coach

The formula that matters: Hours available for 1:1s and coaching = (40 hours - meetings - strategic work) / number of reports. If each report needs ~2 hours/week of management attention (1:1 + prep + follow-up + ad-hoc), 8 reports = 16 hours/week on people work alone.

With 16 engineers: You need either tech leads who handle day-to-day technical decisions (giving you more span) or another manager (giving you a managing-managers challenge). Both are valid; the choice depends on whether your bottleneck is technical direction or people growth.

---

Scaling From 5 to 50

Each growth threshold creates a phase transition that requires structural change:

5 Engineers (One Team)

• Everyone talks to everyone
• No process needed beyond a shared board
• Manager is often a player-coach (writing code)
• Communication channels: 10 (n*(n-1)/2)

10 Engineers (Two Teams)

• First split decision: by product area or by discipline?
• Need explicit API contracts between teams
• Manager stops writing production code (or should)
• Communication channels: 45 — information starts getting lost
• First tech lead role emerges

16 Engineers (Current State)

• Two to three squads with clear ownership
• Need a staffing model: who goes where, and how do you balance seniority?
• Cross-cutting concerns (testing strategy, deployment, architecture) need explicit ownership
• 1:1s consume 8+ hours/week minimum
• Need to start thinking about IC ladder (senior, staff) to retain top talent
• Communication channels: 120 — you cannot rely on osmosis

25 Engineers

• Consider second manager or principal engineer with management-like scope
• Architecture decisions need a formal process (ADRs)
• Onboarding becomes a program, not an ad-hoc buddy system
• Culture starts to fragment between teams — need intentional culture work

50 Engineers

• Multiple managers, need a director layer
• Teams of teams — Team Topologies becomes essential
• Platform team is no longer optional
• Hiring becomes a continuous process, not episodic
• You are managing managers, not engineers

---

Reorgs — When and How

When to Reorg

Reorg when the cost of the current structure exceeds the disruption cost of changing it:

• Two teams must coordinate on every feature — merge them or redraw boundaries
• One team owns too many things — cognitive load is causing dropped balls
• Architecture has diverged from org structure — Conway’s law is fighting you
• Key person dependency — one person is a bottleneck across multiple areas

When NOT to Reorg

• To “shake things up” or signal change (cosmetic reorgs destroy trust)
• During a critical delivery window (finish the milestone first)
• As a substitute for addressing a performance issue with one person
• More than once per year (reorg fatigue is real and cumulative)

How to Reorg Well

1. Define the target architecture first — what communication patterns do you want?
2. Talk to affected people before announcing — surprises destroy psychological safety
3. Move in one clean cut — phased reorgs create months of ambiguity
4. Expect a 2-4 week productivity dip — budget for it explicitly
5. Define success criteria — how will you know the reorg worked in 3 months?

---

Anti-Patterns

Anti-Pattern	Symptom	Fix
Matrix everything	Everyone reports to 2+ people, nobody knows who decides	Single clear reporting line; dotted lines are advisory only
Team per technology	“React team” and “Node team” create integration bottlenecks	Cross-functional teams aligned to product areas
Reorg as strategy	Quarterly reshuffles with no architectural rationale	Define target state first, reorg only to reach it
Ivory tower architecture	Architects who design but don’t build	Embed architects in stream-aligned teams
Understaffed platform	Platform team of 1 with 50 consumers	Either invest properly or don’t pretend you have a platform
Hero culture	One person “holds it all together”	Redistribute knowledge, pair aggressively, document

---

Frameworks and Models

Dunbar’s Numbers Applied to Engineering

Number	Meaning	Engineering Implication
5	Close collaborators	Inner team, daily standup group
15	Trust group	Extended team including stakeholders
50	Mutual recognition	Department — everyone knows names
150	Casual acquaintance	Engineering org ceiling before silos form

Cognitive Load as a Design Constraint

Team Topologies’ strongest contribution is framing cognitive load as a hard constraint:

• Intrinsic cognitive load: Complexity inherent in the problem domain
• Extraneous cognitive load: Complexity from tools, processes, poor documentation
• Germane cognitive load: Complexity from learning and growth

The goal: minimize extraneous load so teams can handle intrinsic load and have room for germane load. If a team owns 5 microservices, 3 databases, a Kafka consumer, and a batch job — their extraneous load is probably crowding out everything else.

Practical heuristic: If a team cannot explain their full domain in a 30-minute whiteboard session, they own too much.

---

Real-World Application

Spotify Model (and Why It Partially Failed)

Spotify’s squad/tribe/chapter/guild model (2012) was influential but the company itself later acknowledged problems:

• Chapters (discipline groups) had no real authority, leading to inconsistent practices
• Tribes became too large (100+ people) and lost coherence
• The model was described aspirationally, not as actual practice

Takeaway: The concepts (autonomous squads, alignment through missions) remain sound. The implementation detail matters more than the label.

Amazon’s Two-Pizza Teams

Amazon’s model works because it is coupled with two other mechanisms:

1. Single-threaded leadership — each team has one leader whose only job is that team’s mission
2. API mandates — teams must expose APIs, no backdoor integrations
3. Fitness functions — teams are measured on outcomes, not outputs

Without these supporting mechanisms, small teams just create coordination problems.

Google’s Engineering Productivity Research

Google’s research (published through DORA/Accelerate) showed that team structure matters less than:

• Deployment frequency
• Lead time for changes
• Mean time to recovery
• Change failure rate

But structure enables or prevents these metrics. A team that cannot deploy independently will never achieve high deployment frequency.

---

References

Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow Conway, M. (1968). “How Do Committees Invent?” — Datamation Fournier, C. (2017). The Manager’s Path — Chapter on managing multiple teams Larson, W. (2019). An Elegant Puzzle: Systems of Engineering Management — Chapters on org design Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate — Statistical evidence for team autonomy Skelton & Pais — Team Topologies talks (various conference recordings on YouTube) Spotify Engineering Culture (2014) — Spotify Labs blog “Lessons Learned from the Spotify Model” — Jeremiah Lee (2020) Dunbar, R. (1992). “Neocortex size as a constraint on group size in primates” — Journal of Human Evolution