Engineering Team Structures: Squads, Tribes, and Guilds Explained
What each model actually means, when to use it, and the restructuring mistakes that slow teams down instead of speeding them up
How you organize your engineering teams is one of the highest-leverage decisions a growing tech company makes — and one of the least reversible. Get it right and teams ship independently, communication is cheap, and ownership is clear. Get it wrong and you end up with a coordination tax that compounds every quarter.
Read the full version with comparison tables and stage-by-stage guidance at projiq.app/blog/engineering-team-structure/
Conway's Law: Structure Is Architecture
Conway's Law (1967) states that organizations design systems that mirror their own communication structures. If your backend and frontend teams are separate departments with separate managers, your system will develop a strong backend-frontend boundary — whether or not that's the right technical design.
The Inverse Conway Maneuver uses this deliberately: design your team structure around the architecture you want, and the architecture will follow.
The Spotify Model: Squads, Tribes, Chapters, Guilds
The Spotify model organizes engineering teams around four units:
| Unit | Size | What it is |
|---|---|---|
| Squad | 5–10 people | Cross-functional, autonomous team owning a product area end-to-end |
| Tribe | 40–150 people | Collection of squads in related areas, bounded by Dunbar's number |
| Chapter | 3–12 people | Formal skill community within a tribe (line management included) |
| Guild | Any size | Informal, company-wide community of interest — no formal authority |
The key tension the model solves
Squads need autonomy to move fast. But complete autonomy produces incoherence — squads that drift in different technical directions or solve the same problem five different ways. Chapters and guilds are the alignment mechanisms.
What Spotify didn't publish
The 2012 blog post was a snapshot, not a blueprint. A few things worth knowing:
Squads frequently failed to achieve true autonomy — most features touched multiple squads
Chapter Leads holding both line management and technical leadership created role confusion
Spotify themselves have evolved significantly from the published model
It worked in a specific cultural context that most orgs don't share
Team Topologies: A More Principled Framework
Published in 2019 by Matthew Skelton and Manuel Pais, Team Topologies defines four fundamental team types:
1. Stream-aligned team — owns an end-to-end product stream. The most common type. All other team types exist to support these.
2. Platform team — builds internal developer platforms that stream-aligned teams consume as a service. Reduces cognitive load on product teams.
3. Enabling team — temporarily helps stream-aligned teams adopt new capabilities. Time-bounded by design — the goal is to build capability, not create dependency.
4. Complicated-subsystem team — owns deeply specialist system components requiring expertise most engineers don't have (recommendation engines, video processing, cryptography).
It also defines three interaction modes:
Collaboration: two teams work closely together for a bounded period
X-as-a-Service: one team provides a defined service with minimal interaction — the target state for platform teams
Facilitating: an enabling team helps another team acquire a capability, then steps back
Functional vs. Feature Teams
| Dimension | Functional Teams | Feature Teams |
|---|---|---|
| Organized by | Skill: Frontend, Backend, QA | Outcome: Checkout, Onboarding, Search |
| Strength | Deep specialization | End-to-end ownership, fast delivery |
| Weakness | High coordination overhead | Risk of duplicated infrastructure |
| Scales to | Poorly — cost grows quadratically | Well — new squad = new capacity |
When to Restructure: Stage Guide
| Stage | Engineers | Structure |
|---|---|---|
| Seed | 1–8 | One flat team. No formal structure. |
| Series A | 8–20 | Light functional split or 2 cross-functional tracks |
| Series B | 20–60 | 2–5 squads + nascent platform team |
| Series C+ | 60–200 | Full squad/tribe or Team Topologies |
| Scale | 200+ | Multiple tribes, strong platform org |
The clearest restructuring signal: work regularly stalls because multiple teams must coordinate changes to the same system, and that overhead consumes more than 20% of capacity.
The Restructuring Mistakes to Avoid
1. Copying the vocabulary, not the principles. Renaming teams "squads" without giving them genuine autonomy produces development silos with better branding.
2. Restructuring to solve a culture problem. Low trust and poor communication reproduce in the new structure. Address culture first.
3. Building platform teams too early. Below ~30 engineers, a platform chapter (part-time working group) is usually a better trade-off than a full dedicated team.
4. Restructuring too frequently. Every restructure carries a 3–6 month performance trough. Measure recovery with DORA metrics — it takes longer than most people expect.
Principles That Work Across Any Structure
Clear written ownership — every service and on-call rotation has a named team
Team APIs — every team publishes what they own, what they don't, and how to engage them
Minimal viable process — standardize outcomes, not methods
Explicit cognitive load management — reduce scope before adding headcount
For the full breakdown including comparison tables, stage-by-stage guidance, and the Conway's Law deep dive, read the complete article at projiq.app/blog/engineering-team-structure/.
Projiq is a project management platform for engineering organizations — one flat price for your whole team, no per-seat fees. Start free.
