Run SheetTeam DesignTeam Topologies

Spotify Model Mapping

KomplexitätMedium

Zeit90-180 min

Teilnehmende5-15

FormatWorkshop

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenStakeholder Mapping

Eine aktuelle Übersicht der Engineering-Teams und ihrer Verantwortungen liegt vor.

Ohne: Ohne Team-Liste werden Squads und Tribes nach Wunsch statt Realität gemalt, Diagnose verliert Bezug.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro-Board mit Spotify-Modell-Vorlage (Squads, Tribes, Chapters, Guilds als Sektionen); aktuelle Team-Liste; Org-Chart als Referenz; Liste bekannter Reibungen; Stifte; vertraulicher Bereich für Diagnose.

Personen / Rollen

Ein Facilitator mit Org-Design-Erfahrung; CTO oder Engineering-Director als Sponsor; Engineering-Leads; HR-Partner für Personalkapital-Perspektive; Scribe für Aktionen.

Vorabinfos

Team-Liste mit Größe und Verantwortung; aktuelle Reporting-Linien; bestehende Chapter-Strukturen (z. B. Frontend-Chapter, Backend-Chapter); Guild-Aktivitäten; Vergleich mit echtem Spotify-Modell aus Literatur.

Zeitbedarf

90-180 min

Setup

Vorlage mit vier Sektionen: Squads (autonome Teams), Tribes (Gruppe von Squads mit gemeinsamem Bereich), Chapters (Skill-Gruppen über Squads hinweg), Guilds (Interessen-Gruppen). Definitionen sichtbar. Kritischer Hinweis: Spotify selbst nutzt es nicht mehr in dieser Form.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Wie ist unsere Engineering-Org tatsächlich strukturiert in Squads, Tribes, Chapters und Guilds, und wo entstehen Reibungen oder Lücken?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Begriffe definieren	20 min	Pro Begriff Definition diskutieren und für eigene Org festlegen. Squad: autonomes Team mit Mission. Tribe: 30-150 Personen mit gemeinsamem Bereich. Chapter: Skill-Gruppe (z. B. Frontend) über Squads hinweg. Guild: freiwillige Interessen-Gruppe.	Spotify-Mythos: das Modell wurde idealisiert dargestellt. Spotify selbst hat es weiterentwickelt. Wer Modell kopiert, ohne eigene Bedeutung zu klären, baut Buzzword-Org.
2Phase 2: Squads positionieren	20-30 min	Aktuelle Teams als Squads platzieren. Pro Squad Mission, Größe, Verantwortung notieren. Squads ohne klare Mission markieren.	Wenn Squad keine Mission hat oder zu groß ist (>10 Personen), ist es kein Squad in spotify-Sinn. Ehrlich kennzeichnen, statt Etikette anbringen.
3Phase 3: Tribes und Chapters	30-40 min	Squads zu Tribes gruppieren nach gemeinsamem Bereich. Chapters identifizieren: welche Skill-Gruppen existieren (Frontend, Backend, Mobile, Data, QA). Chapter-Lead pro Chapter benennen.	Tribes haben Skalierungsgrenzen (Dunbar-Zahl ~150). Bei kleinerer Org-Größe sind Tribes redundant. Chapters brauchen Lead, sonst sind sie nominell, nicht funktional.
4Phase 4: Guilds explizit benennen	15-20 min	Aktive Guilds (freiwillige Interessen-Gruppen) auflisten. Beispiele: ML-Guild, Security-Guild, Accessibility-Guild. Pro Guild Häufigkeit der Treffen und Format.	Wenn keine Guilds existieren, ist Modell unvollständig. Guilds entstehen organisch, nicht per Anordnung. Wenn niemand interessiert ist, gibt es keine Guild.
5Phase 5: Lücken und Aktionen	20-30 min	Reibungspunkte und Lücken im Modell markieren: Squads ohne Tribe, Chapters ohne Lead, fehlende Querschnitts-Themen. Aktionen mit Owner und Frist.	Aktionen können sein: Squad-Mission schärfen, Chapter-Lead benennen, Guild gründen, oder bewusst Spotify-Begriffe ablegen, weil sie nicht passen.

Artefakt

Was am Ende rauskommt

Form

Spotify-Modell-Karte (Board-Export) mit allen vier Sektionen, Squads mit Mission, Tribes mit Bereich, Chapters mit Lead, Guilds mit Format. Aktionsliste mit Owner und Frist. Kritischer Disclaimer zur Spotify-Realität.

Tool-Alternativen

Miro oder FigJam mit Spotify-Template
Lucidchart mit Org-Diagramm-Vorlage
Confluence-Seite mit Sektionen pro Element
Notion-Datenbank mit Team-Properties
Org-Chart-Tools (org.io, Pingboard) mit Custom-Fields

Versionierung / Ownership

Halbjährlich neu bewerten. Bei Reorganisation sofort. Vorversion archivieren. Bei Modell-Wechsel (z. B. zu Team Topologies) explizite Migration dokumentieren.

canvas

Spotify Model Mapping Arbeitsvorlage

Kompakte Arbeitsvorlage für Spotify Model Mapping mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Spotify Model Mapping Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Spotify-Modell-Karte:
- Aktionsliste:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

spotify-model-mapping-beispiel.md

markdown

## Spotify Model Mapping - Engineering-Org, 2026-05-18

**Disclaimer**: Spotify selbst hat das Modell weiterentwickelt. Diese Karte beschreibt unseren Stand, nicht idealisiertes Spotify.

**Squads (12)**

| Squad | Mission | Größe | Tribe |
|-------|---------|--------|-------|
| Onboarding | Aktivierung neuer Nutzer | 7 | Product-Tribe |
| Mandanten-Management | Mandanten-Lifecycle | 8 | Product-Tribe |
| Beleg-Pipeline | KI-Belegerkennung | 9 | KI-Tribe |
| KI-Training | Modell-Entwicklung | 5 | KI-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 | (kein Tribe, anti-Pattern) |
| Mobile | iOS und Android | 6 | Product-Tribe |
| Payments | Stripe-Integration | 4 | (klein, evtl. in Product-Tribe) |
| DevEx (Enabling) | Tooling-Coaching | 3 | (Enabling, eigene Struktur) |
| Security Coaches | Security-Reviews | 2 | (Enabling) |

**Tribes (3)**
- Product-Tribe (38 Personen): Onboarding, Mandanten, Mobile, Payments.
- KI-Tribe (14 Personen): Beleg-Pipeline, KI-Training.
- Platform-Tribe (18 Personen): Identity, Data, Infrastructure.

**Chapters (5)**
- Frontend-Chapter (Lead: @lisa, 18 Personen).
- Backend-Chapter (Lead: @ben, 32 Personen).
- Data Engineering-Chapter (Lead: @anna, 8 Personen).
- QA-Chapter (Lead: @marcus, 6 Personen).
- ML Engineering-Chapter (Lead: vakant, 6 Personen).

**Guilds (3 aktiv)**
- Security-Guild: monatliche Lunch-Sessions, freiwillig.
- Accessibility-Guild: bi-weekly, von Frontend getrieben.
- Documentation-Guild: ad-hoc, geringe Aktivität.

**Lücken und Aktionen**
1. **Customer Success Engineering ohne Tribe**: zugeordnet, aber unklar wohin. Diskussion: Eingliederung in Product-Tribe oder eigenes Tribe „Customer“. Owner: @julia, Entscheidung bis 30.06.
2. **ML Engineering Chapter ohne Lead**: Vakanz, schwächt Skill-Aufbau. Owner: @julia, Hiring oder Promotion bis 15.07.
3. **Documentation-Guild geringe Aktivität**: prüfen, ob auflösen oder neu starten. Owner: @lisa, Diskussion in Q3.

Was tun

Disclaimer in Diagramm: Spotify selbst nutzt es nicht mehr in dieser Form. Pro Element prüfen, ob es eigene Bedeutung hat. Team Topologies oder eigenes Modell als Alternative ernsthaft erwägen.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Engineering-Org hat weniger als 30 Personen, Modell ist Overhead.

Begriffe können nicht für eigene Org definiert werden, Modell-Adoption wäre Schein.

Sponsor (CTO/Engineering-Director) nicht anwesend, Aktionen wären unverbindlich.

Org befindet sich im Umbruch, Karte würde in 4 Wochen veralten.

Bereits etabliertes Org-Design (Team Topologies, klassische Abteilungen), Spotify-Mapping würde Parallelstruktur erzeugen.

Spotify-Modell-Mythos ist im Workshop nicht hinterfragbar, kritische Diagnose nicht möglich.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden