Complete firstStakeholder Mapping
A current overview of engineering teams and their responsibilities exists.
Without: Without team list, squads and tribes are drawn by wish rather than reality, and diagnosis loses grounding.
RunsheetTeam Design
Spotify Model Mapping
ComplexityMedium
Time90-180 min
Participants5-15
FormatWorkshop
MaturityEstablished
01
Prerequisite
What needs to be finished first
02
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro board with Spotify model template (squads, tribes, chapters, guilds as sections); current team list; org chart as reference; list of known frictions; pens; confidential area for diagnosis.
People / roles
One facilitator with org-design experience; CTO or engineering director as sponsor; engineering leads; HR partner for human-capital perspective; scribe for actions.
Pre-read
Team list with size and responsibility; current reporting lines; existing chapter structures (for example frontend chapter, backend chapter); guild activities; comparison with real Spotify model from literature.
Time needed
90-180 min
Setup
Template with four sections: Squads (autonomous teams), Tribes (group of squads with shared area), Chapters (skill groups across squads), Guilds (interest groups). Definitions visible. Critical note: Spotify itself no longer uses it in this form.
03
Core question
The one question this method answers
How is our engineering org actually structured into squads, tribes, chapters and guilds, and where do friction or gaps emerge?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Define terms | 20 min | Discuss each term and define it for own org. Squad: autonomous team with mission. Tribe: 30-150 people with shared area. Chapter: skill group (for example frontend) across squads. Guild: voluntary interest group. | Spotify myth: the model was idealized. Spotify itself evolved it. Copying the model without clarifying own meaning creates buzzword org. |
2Phase 2: Position squads | 20-30 min | Place current teams as squads. Note mission, size, responsibility per squad. Mark squads without clear mission. | If squad has no mission or is too large (>10 people), it is not a squad in the Spotify sense. Mark honestly instead of applying label. |
3Phase 3: Tribes and chapters | 30-40 min | Group squads into tribes by shared area. Identify chapters: which skill groups exist (frontend, backend, mobile, data, QA). Name chapter lead per chapter. | Tribes have scaling limits (Dunbar number ~150). In smaller orgs, tribes are redundant. Chapters need a lead, otherwise they are nominal, not functional. |
4Phase 4: Name guilds explicitly | 15-20 min | List active guilds (voluntary interest groups). Examples: ML guild, security guild, accessibility guild. Per guild: meeting frequency and format. | If no guilds exist, the model is incomplete. Guilds emerge organically, not by order. If nobody is interested, there is no guild. |
5Phase 5: Gaps and actions | 20-30 min | Mark friction points and gaps in model: squads without tribe, chapters without lead, missing cross-cutting topics. Actions with owner and deadline. | Actions can be: sharpen squad mission, name chapter lead, found guild, or deliberately drop Spotify terms because they do not fit. |
05
Artifact
What comes out at the end
Form
Spotify model map (board export) with all four sections, squads with mission, tribes with area, chapters with lead, guilds with format. Action list with owner and deadline. Critical disclaimer on Spotify reality.
Versioning / ownership
Reassess every six months. Immediately on reorganization. Archive previous version. Document explicit migration when switching model (for example to Team Topologies).
Tool alternatives
- Miro or FigJam with Spotify template
- Lucidchart with org diagram template
- Confluence page with sections per element
- Notion database with team properties
- Org chart tools (org.io, Pingboard) with custom fields
spotify-model-mapping-working-template.md
Compact working template for Spotify Model Mapping with context, input, output artifacts, and next step.
Spotify Model Mapping Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Spotify model map:
- Action list:
Open questions
- ...
Next step
Owner, date, success signal.
06
Example output
Concrete filled scenario, fictional example
spotify-model-mapping-beispiel.md
Concrete filled scenario, fictional example
Spotify Model Mapping - Engineering org, 2026-05-18
Disclaimer: Spotify itself evolved the model. This map describes our state, not idealized Spotify.
Squads (12)
| Squad | Mission | Size | Tribe |
|---|---|---|---|
| Onboarding | Activation of new users | 7 | Product Tribe |
| Client Management | Client lifecycle | 8 | Product Tribe |
| Receipt Pipeline | AI receipt recognition | 9 | AI Tribe |
| AI Training | Model development | 5 | AI Tribe |
| Identity Platform | Auth + user lifecycle | 6 | Platform Tribe |
| Data Platform | Data infrastructure | 7 | Platform Tribe |
| Infrastructure | Cloud, DevOps | 5 | Platform Tribe |
| Customer Success Engineering | Support tooling | 4 | (no tribe, anti-pattern) |
| Mobile | iOS and Android | 6 | Product Tribe |
| Payments | Stripe integration | 4 | (small, maybe in Product Tribe) |
| DevEx (Enabling) | Tooling coaching | 3 | (Enabling, own structure) |
| Security Coaches | Security reviews | 2 | (Enabling) |
Tribes (3)
- Product Tribe (38 people): Onboarding, Clients, Mobile, Payments.
- AI Tribe (14 people): Receipt Pipeline, AI Training.
- Platform Tribe (18 people): Identity, Data, Infrastructure.
Chapters (5)
- Frontend Chapter (Lead: @lisa, 18 people).
- Backend Chapter (Lead: @ben, 32 people).
- Data Engineering Chapter (Lead: @anna, 8 people).
- QA Chapter (Lead: @marcus, 6 people).
- ML Engineering Chapter (Lead: vacant, 6 people).
Guilds (3 active)
- Security Guild: monthly lunch sessions, voluntary.
- Accessibility Guild: bi-weekly, driven by frontend.
- Documentation Guild: ad-hoc, low activity.
Gaps and actions
- Customer Success Engineering without tribe: assigned, but unclear where. Discussion: integrate into Product Tribe or own "Customer" tribe. Owner: @julia, decision by 2026-06-30.
- ML Engineering Chapter without lead: vacancy weakens skill building. Owner: @julia, hiring or promotion by 2026-07-15.
- Documentation Guild low activity: check whether to dissolve or restart. Owner: @lisa, discussion in Q3.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Buzzword adoption
Symptom
Terms squad, tribe, chapter are introduced, old structures renamed, nobody knows what actually changes.
What to do
Own definition with meaning per term. Question model adoption if it is purely nominal. Better known terms (team, department) than empty labels.
Trap
Squads without mission
Symptom
Squads are nominally autonomous, but lack clear mission. Everyone works on different topics.
What to do
Force 1-2 sentence mission per squad. Squad without mission is functional department, not squad. Mark honestly or sharpen mission.
Trap
Chapters without function
Symptom
Chapter is named, but no lead, no cadence, no skill-coaching activity.
What to do
Lead and at least monthly cadence per chapter. If no activity, dissolve chapter instead of carrying label. Honesty is diagnostic value.
Trap
Guilds by order
Symptom
Management orders "we now found guild X", nobody attends meetings.
What to do
Guilds are voluntary and organic. Support through time and visibility, not order. If there is no demand, there is no guild.
Trap
Spotify myth adopted uncritically
Symptom
Model is copied like image from Spotify whitepaper, without own adaptation.
What to do
Disclaimer in diagram: Spotify itself no longer uses it in this form. Check each element for own meaning. Seriously consider Team Topologies or own model as alternative.
08
Stop criteria
Done signals checkable in under a minute
Engineering org has fewer than 30 people, model is overhead.
Terms cannot be defined for own org, model adoption would be theater.
Sponsor (CTO/engineering director) not present, actions would be non-binding.
Org is in transition, map would be outdated in 4 weeks.
Established org design already exists (Team Topologies, classic departments), Spotify Mapping would create parallel structure.
Spotify model myth cannot be questioned in workshop, critical diagnosis impossible.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.