Meine Session planen

# 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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