Session Brief: Spotify Model Mapping

Ziel

Artefakt: Spotify-Modell-Karte

Arbeitsfrage

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

Kontext

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.

Setup

• Format: Methoden-Session
• Dauer: 90-180 min
• Modus: Workshop
• Teilnehmende: Ein Facilitator mit Org-Design-Erfahrung; CTO oder Engineering-Director als Sponsor; Engineering-Leads; HR-Partner für Personalkapital-Perspektive; Scribe für Aktionen.
• Owner: Ein Facilitator mit Org-Design-Erfahrung
• Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
• Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Spotify-Modell-Karte hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

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.

Vorbereitung

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.

Agenda

1. Phase 1: Begriffe definieren (20 min) Owner: Facilitator Aktion: 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. Hinweis: Spotify-Mythos: das Modell wurde idealisiert dargestellt. Spotify selbst hat es weiterentwickelt. Wer Modell kopiert, ohne eigene Bedeutung zu klären, baut Buzzword-Org. Output: Spotify-Modell-Karte

2. Phase 2: Squads positionieren (20-30 min) Owner: Facilitator Aktion: Aktuelle Teams als Squads platzieren. Pro Squad Mission, Größe, Verantwortung notieren. Squads ohne klare Mission markieren. Hinweis: Wenn Squad keine Mission hat oder zu groß ist (>10 Personen), ist es kein Squad in spotify-Sinn. Ehrlich kennzeichnen, statt Etikette anbringen. Output: Aktionsliste

3. Phase 3: Tribes und Chapters (30-40 min) Owner: Facilitator Aktion: Squads zu Tribes gruppieren nach gemeinsamem Bereich. Chapters identifizieren: welche Skill-Gruppen existieren (Frontend, Backend, Mobile, Data, QA). Chapter-Lead pro Chapter benennen. Hinweis: Tribes haben Skalierungsgrenzen (Dunbar-Zahl ~150). Bei kleinerer Org-Größe sind Tribes redundant. Chapters brauchen Lead, sonst sind sie nominell, nicht funktional. Output: Spotify-Modell-Karte

4. Phase 4: Guilds explizit benennen (15-20 min) Owner: Facilitator Aktion: Aktive Guilds (freiwillige Interessen-Gruppen) auflisten. Beispiele: ML-Guild, Security-Guild, Accessibility-Guild. Pro Guild Häufigkeit der Treffen und Format. Hinweis: Wenn keine Guilds existieren, ist Modell unvollständig. Guilds entstehen organisch, nicht per Anordnung. Wenn niemand interessiert ist, gibt es keine Guild. Output: Aktionsliste

5. Phase 5: Lücken und Aktionen (20-30 min) Owner: Owner Aktion: Reibungspunkte und Lücken im Modell markieren: Squads ohne Tribe, Chapters ohne Lead, fehlende Querschnitts-Themen. Aktionen mit Owner und Frist. Hinweis: Aktionen können sein: Squad-Mission schärfen, Chapter-Lead benennen, Guild gründen, oder bewusst Spotify-Begriffe ablegen, weil sie nicht passen. Output: Spotify-Modell-Karte

6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Spotify-Modell-Karte

Abschluss

• Ergebnisartefakt aktualisieren: Spotify-Modell-Karte
• Ablageort, Version und Review-Empfänger festlegen.
• Owner, nächster Schritt und Reviewtermin festlegen.

Spotify-Modell-Karte: Spotify Model Mapping

Arbeitsfrage

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

Kontext

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.

Beteiligte

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

Input

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.

Vorlage

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.

Fertigstellungscheck

• Spotify-Modell-Karte ist vollständig genug für Review:
• Ablageort:
• Version / Status:
• Review durch:
• Nächster Schritt:

Nächster Schritt

• Ergebnis prüfen
• offene Fragen markieren
• Review oder Entscheidung terminieren