Spotify hat vor einigen Jahren sein Organisationsmodell sehr ausführlich beschrieben. Das hat viele Unternehmen zur Übernahme dieses „Spotify-Modells“ bewogen. Ich habe Christoph Schmiedinger zu Gast, der ein lesenswertes Whitepaper unter dem Titel „Vorbild Spotify? – Was sie beachten sollten, bevor sie das Organisationsmodell kopieren“. Wir sprechen vor allem über das, was viele nicht beim Spotify-Modell wissen, nämlich über Spotify nach 2015.
In dieser Podcast-Episode diskutiert Dierk Söllner mit Christoph Schmiedinger die Integration des Spotify-Organisationsmodells in die DevOps-Praxis. Sie erörtern die Geschichte und Entwicklung von Spotify, die Struktur des Unternehmens, einschließlich Tribes, Squads und Chapters, sowie die Anpassungen, die Spotify über die Jahre vorgenommen hat. Der Fokus liegt auf den Herausforderungen und möglichen Fallstricken bei der Übernahme des Spotify-Modells in andere Organisationen, sowie auf der Rolle des Product Owners und Chapter Leads innerhalb dieses Modells.
Inhalt
- Einführung und Kontext von Spotify und DevOps
- Geschichte und Entwicklung von Spotify
- Struktur von Spotify: Tribes, Squads, Chapters, Guilds
- Bedeutung des Spotify-Modells für agile Organisationen
- Diskussion über das Spotify-Modell
- Die Rolle von Tribes und ihre Funktionen
- Squads und ihre Flexibilität in der Methodik
- Chapters und die Bedeutung von Expertise-Gruppen
- Guilds als optionale, interessenbasierte Gruppen
- Anpassungen und Lernprozesse von Spotify
- Entwicklung und Änderungen bei Spotify seit 2012
- Herausforderungen bei der Übernahme des Spotify-Modells
- Rolle und Herausforderungen des Product Owners
- Bedeutung und Aufgaben des Chapter Leads
- Implementierung des Spotify-Modells in anderen Unternehmen
- Überlegungen zur Anpassung des Modells an unterschiedliche Unternehmenskontexte
- Risiken und Chancen des Modells in verschiedenen Organisationsstrukturen
Shownotes
Whitepaper von Christoph Schmiedinger „Vorbild Spotify?“
Vorbild Spotify – Die Herausforderungen einer Transformation
McKinsey Quarterly: ING’s agile transformation. January 2017
Mussler, H.: Die Commerzbank nimmt sich Spotify als Vorbild. FAZ online, 19.08.2018
Kukreja, S.: Edgar Schein’s Model of Organizational Culture. Management Study HQ
Tracey, E.: What’s it like to work at Spotify?“ Honeypot Blog, 13.11.2015
Kendis Team: Exploring Key Elements of Spotify’s Agile Scaling Model. Medium, 23.7.2018
Pink, D.: Drive: The surprising truth about what motivates us. Riverhead Books, 2011
Transkript (automatisiert erstellt, daher keine Gewähr 🙂 )
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer
hochperformanten IT-Organisation. Als Trainer und Coach mache ich Teams
und Menschen erfolgreich, um die aktuellen Herausforderungen bewältigen zu können.
Ich bringe meine Tätigkeit neben der persönlichen Coaching-Kompetenz eine
breite und langjährige Fachkompetenz ein. DevOps umfasst für mich kulturelle,
organisatorische, prozessuale und technische Aspekte. Diese diskutiere ich mit Experten aus
der Praxis oder in einer Short Story, die ich selber bespreche. Heute feiere ich ein
kleines Jubiläum, die 25. Ausgabe, und jetzt müsste hier eigentlich ein kleiner
Tusch kommen, aber den spare ich mir jetzt an der Stelle mal. Ich freue mich heute auf das
Thema Vorbild Spotify, was Sie beachten sollten, bevor Sie das Organisationsmodell kopieren.
Zu Gast habe ich Christoph Schmiedinger von Boris Kloga Consulting. Er hat sich mit dem
Thema ausführlich beschäftigt und seine Ergebnisse in ein äußerst lesenswertes
Whitepaper gepackt. Ich suche für meine Podcasts immer solch guten Content als Basis,
also hier schon mal vielen Dank Christoph, das ist wirklich eine gute Basis, über die wir gleich
reden können. Als System Engineer, Projektmanager und Product Owner hat Christoph Schmiedinger mehrere
komplexe, skalierte Entwicklungsprojekte im sicherheitskritischen Bereich mit agilen
Methoden erfolgreich durchgeführt und heute hilft er mit dieser Expertise seinen Kunden
bei strategischen Weichenstellungen und entwickelt passende Umsetzungsmaßnahmen für die Kunden.
Christoph und ich kennen uns aus einem gemeinsamen Projekt aus
2013, 2014 glaube ich war das, ist also schon ein bisschen her, aber natürlich haben wir beide
beim Thema Agilität in einem deutschen Energiekonzern so einiges erlebt. Christoph, bevor ich an dich
weiterreiche, das Thema noch kurz zur Motivation für das Whitepaper, das ihr bei Boris Kloga so
formuliert habt. Wir wollen auf das Spotify-Modell umstellen. So lauten viele Anfragen, die uns in
den letzten zwei Jahren erreicht haben. Die schwedische Musik-Streaming-Plattform ist der
Inbegriff des frischen,
agilen Unternehmens. Zwar schreibt Spotify erst seit Ende 2018 Gewinne, doch seine Aufbaustruktur
aus dem Jahre 2012 erscheint Unternehmen weltweit als die Antwort auf die Frage, wie man eine agile
Organisation bauen kann. Lesen Sie in diesem Whitepaper und das werde ich natürlich in den
Shownotes verlinken, weshalb Sie eine Copy- und Paste-Strategie auf dem Weg zur agilen
Organisation gut überlegen sollten, wo Spotify mit seinem Organisationsmodell heute steht und
was bei der Übernahme des Modells zur Herausforderung werden kann.
Ja, genug der Vorrede, Christoph. Ich habe dich ja schon kurz vorgestellt. Was habe ich vergessen? Was
möchtest du noch ergänzen, um dich vorzustellen? Ja, vielen Dank, Dirk, einmal für die Möglichkeit,
auch bei dir da im Podcast mitzuwirken. Ich glaube, du hast schon vieles gesagt. Tatsächlich hat mich
die letzten Jahre sehr viel bewegt im Sinne von großen Transformationen. Also immer, wenn es
darum ging, irgendwie ein Unternehmen, ja, ich würde sagen, einen Bereich oder ein ganzes Unternehmen
in Richtung Agilität zu bringen, dann habe ich mich sehr viel bewegt. Ich habe mich sehr viel bewegt,
ja, und immer, wenn diese große Transformation ansteht, dann spricht man früher oder später auch
über das Aufbauorganisationsmodell, weil man, glaube ich, mittlerweile schon stark dazu übergeht,
zu sehen, dass es nicht nur um Methodik und Mindset geht. Also die zwei Punkte sind absolut
valide und wichtig, aber am Ende muss auch die Struktur dazu passen. Und das hat mich ja abseits
auch von dem Spotify-Modell auf jeden Fall die letzten zwei, drei Jahre sehr beschäftigt.
Wir sind ja im DevOps-Podcast hier und da bitte ich ja meine Gäste immer,
um ihre persönliche Definition von DevOps. Wie würdest du DevOps definieren oder beschreiben?
Also für mich ist DevOps auf jeden Fall einmal ein Mindset-Thema, also im Sinne von wirklich
dieses Großfunktionale zu leben, auch dieses Thema T-Shape zu leben, also quasi auch mal über den
Tellerrand rauszublicken, sich mit anderen Experten zu unterhalten und natürlich das Thema End-to-End,
im Sinne von, dass man in einem Team möglichst viele Teile der Wertschöpfung abdeckt. Und ich glaube,
das kann man auch gut kombinieren, weil letztendlich auch in dem sogenannten Spotify-Modell wird auch
sehr, sehr viel von der Expertise, um ein Produkt zu bauen oder auch zu betreiben, dann in letzter
Konsequenz oder um einen Service bereitzustellen, in die Teams gepackt. Weil für mich geht das Thema
sogar noch weiter. Es wird ja auch manchmal von diesen Biz-DevOps gesprochen, wo quasi wirklich
dann am Ende in einem Team einfach jegliche Expertise vorhanden ist, um ein Produkt nicht
nur zu bauen, sondern auch langfristig zu betreiben. Und ich glaube, das schafft einfach einen
ungemeinen Mehrwert, weil…
So typische Handover einfach vermieden werden.
Du hast eben das Thema Biz-DevOps angesprochen. Ist dir schon so etwas in der Praxis begegnet?
Ich höre immer davon, aber ich habe selber nur eben aus Hörensagen erzählt. Also kennst du Unternehmen,
die schon so in der Richtung unterwegs sind?
Ich will mal sagen, zumindest teilweise. Die Frage ist, glaube ich, stark, wie weit definiert man
diesen Ops-Gedanken? Wie weit geht der wirklich bis zu den Hardware-Applikationen oder reicht das
quasi immer so?
Ich würde sagen, wir haben eine Bank auch begleitet, die stark auch auf dieses Spotify-Modell
setzt. Dort war auf jeden Fall, was die schon mal geschafft haben, ist wirklich Biz und IT
sozusagen, Biz und Dev zusammenzubekommen. Und die hatten zumindest einen Experten, der
Ops mitbetreut hat im Team. Manchmal sogar zwei. Ich denke, das geht schon ganz nah. Würde
ich jetzt sagen, das ist schon perfekt. Wahrscheinlich nicht. Aber es geht schon sehr, sehr nahe.
an den Gedanken. Und ich habe damit eigentlich sehr, sehr gute Erfahrungen in dem Unternehmen gemacht,
weil sehr, sehr viel durch das Team einfach eigenverantwortlich umgesetzt werden kann und auch
betrieben werden kann und man nicht ständig angewiesen ist auf andere Teams, die irgendwie
supporten, wo man dann wieder Abhängigkeiten hat, was natürlich auch die Planung am Ende
super schwierig macht.
Ja, okay. Also insofern, meine Frage ging so in die Richtung Biz und gar nicht so sehr Ops, aber natürlich
sind ja dann diese drei Bereiche, die ich dann auch in der Richtung, die ich dann auch
unternehmen müsste. Es gibt dann ja auch dann die Fortschöpfung wie DevSecOps, wenn ich dann
Security mit reinnehme. Da könnte man wahrscheinlich so einen richtig langen Namen, ein langes Akronym
zusammenbauen, um alles das, was da rein sollte, mit reinzunehmen. Aber insofern finde ich es
interessant, wenn du sagst, Biz ist schon ein bisschen mit drin. Und so wie ich DevOps verstehe,
geht es ja auch gar nicht darum, jedes Wissen als Ressource, als Mensch drin zu haben, sondern
das Wissen eben genau zu haben. Und das hast du ja eben gesagt. Da waren ein, zwei Experten, die das
Wissen mitbringen, aber die vielleicht gar nicht mehr diese Experten-Tätigkeiten ausführen müssen, sondern
einfach nur das Wissen mit einbringen.
Vielleicht, um da nochmal ganz kurz drauf zu blicken, ich glaube, da kann echt dieser Schritt Richtung
Spotify-Modell oder in eine Art von Spotify-Modell echt helfen, weil der fokussiert sehr stark, dieser
Ansatz fokussiert sehr stark auf Biz und Dev zusammenzubekommen. Und das kann quasi ein Mittel sein, wenn man
quasi schon ein gutes DevOps-Team aufgestellt hat, um dann mit der letzten Schritt,
um das Biz noch dazu so anzudrucken. Und dann ist immer die Frage, so wie du sagst,
dann am Ende hat man einen superlangen Namen und dann ist auch gleichzeitig immer noch der Fall,
wir sollten maximal neun bis zehn Leute da in dem Team sein, was natürlich auch immer das Ganze nicht
einfacher macht. Aber ich kann es zumindest als Tipp geben, dass so ein Spotify-Ansatz ganz gut ist,
wenn man schon DevOps aufgestellt hat, um einfach Business noch dazu zu nehmen.
Ja, okay. Und dann hast du natürlich dann neun Experten und dann brauchst du eigentlich ein
cross-funktionales Team, wo jeder
möglichst viel an Aufgaben übernehmen kann.
Dann hast du dann da wiederum das Problem. Also
wahrscheinlich gibt es nicht die goldene
Lösung, aber wie du schon sagst,
ein paar Dinge, die man beachten sollte.
Du hast selber gesagt eben,
wir reden über das Thema Vorbild Spotify.
Euer White Paper heißt ja auch so,
Vorbild Spotify, Fragezeichen,
was sie beachten sollten, bevor sie das
Organisationsmodell kopieren.
Da würde ich jetzt mal die erste Frage stellen,
da hast du schon so ein bisschen drauf abgezielt.
Ist das Modell Spotify,
eigentlich ist das nur ein
Organisationsmodell,
oder ist das nicht auch ein bisschen mehr?
Ja, das ist eine gute Frage.
Also es ist natürlich
ein wenig mehr. Am Ende,
was Spotify damals veröffentlicht
hat, 2012,
war eigentlich der
Way of Working. Wie arbeiten die?
Da gab es unter anderem
zwei Videos, die sich stark mit der
Engineering Culture beschäftigt haben.
Also wie wird dort zusammengearbeitet?
Wie wird dort eben auch in cross-funktionalen
Teams und T-Shape zusammengearbeitet?
Also da waren wesentlich mehr,
als nur ein paar Aspekte dabei.
Also die haben einige Videos auch dazu gedreht,
die man auch gut auf YouTube findet.
Und das andere Part war ein White Paper.
Und das hat sich tatsächlich
stark mit der Organisationsstruktur beschäftigt.
In dem Paper geht es weniger darum,
wie sich diese einzelnen Strukturen
dann miteinander austauschen,
sondern der Fokus war wirklich
stark auf Organisationsstruktur,
gerade im Sinne der Aufbauorganisation
und Rollen.
Also dadurch, es ist glaube ich im Gesamtkonstrukt
das ganze Spotify mehr, wenn man, ähm,
wenn man heute aber Unternehmen fragt,
worauf sie speziell achten, wenn sie sich
quasi was von Spotify abgucken
wollen, dann tendieren sie in der Regel
dazu, sehr stark auf dieses Organisationsmodell
zu gucken.
Ja, vielleicht liegt das auch daran, dass
die Generation, die
das verantwortet, die sich darauf
ausrichtet, dass die eben eher lesen
als YouTube gucken. Da haben wir ja auch aktuell
ein paar Beispiele, wo auch die ein oder andere
Organisation oder Partei
Schwierigkeiten hat mit YouTube.
Das nur am Rande. Aber das ist
Politik, das lassen wir mal raus hier.
Okay, also du sagst ganz, ganz
klar, es ist eigentlich mehr, aber die meisten
fokussieren eben auf Organisationen,
auf Rollen, weil das eben das in dem Whitepaper
beschrieben ist, was dann von den meisten
herausgezogen wurde.
Ich glaube, wir sollten ganz kurz
nochmal auf das eingehen, was du auch in
deinem Whitepaper dann beschrieben hast.
Wie sah denn Spotify im Jahre
2012 aus? Ich glaube, das wäre, ich sage mal,
wichtig, dass man das nochmal ganz kurz zusammenfasst,
auch wenn die meisten der Hörer das wahrscheinlich
schon irgendwie mal gehört oder gelesen
haben. Kannst du nochmal ganz kurz darstellen,
wie Spotify im Jahre 2012
ausgesehen hat? Genau, also einerseits
ich würde es mal gerne in zwei Teile
einteilen. Einerseits ist es, wie
hat es quasi der Kontext ausgesehen
und 2012, wenn man
sich damit ein bisschen beschäftigt, dann war
noch sehr jung damals das Unternehmen, sicher
kein blutjunges Startup. Wurde 2006
gegründet, Spotify, also waren so
sechs Jahre alt und hatten so
ungefähr 600 Mitarbeiter.
Und insgesamt eine sehr, sehr junge
Mannschaft. Also selbst der
CEO war zum damaligen Zeitpunkt
gerade einmal 29 Jahre alt. Also
starke Startup-Kultur, stark junges
Team und was
auch sehr beachtlich ist, sie waren sehr
auf Wachstum getrieben.
Also Wachstum, Wachstum, Wachstum.
Unter anderem, weil denen damals
schon bewusst war, okay, wir können
nur eine Chance gegen die großen Tech-Konzerne
wie Google oder Facebook oder
Apple, haben wir nur eine Chance, wenn wir
richtig viele User haben.
Und ich glaube, das hat sich im Nachhinein auch bewahrheitet,
diese Strategie. Spotify
hätte sich wahrscheinlich nicht durchgesetzt und wäre
heute on par mit den ganz Großen,
wenn sie nicht extrem viele Nutzer
schon versammelt hätten.
Also alles war auf Wachstum getrimmt und das ist mit ein Punkt
auch, warum der erste Quartalsgewinn
erst 2018 war. Ende
2018, erster operativer Quartalsgewinn.
Das bedeutet eigentlich zwölf Jahre
lang Geld im operativen Geschäft
verloren. Und das muss man sich auch mal leisten können.
Und da steckt natürlich eine starke
Wachstumserwartung quasi hinter
den Venture Cap.
Das ist einerseits mal der Kontext,
was die damals gebaut haben und dass es
mehr das Organisationsmodell ist.
Im Wesentlichen eine Struktur aus
sogenannten Tribes. Im Wesentlichen
sind das Bereiche, die maximal
irgendwie so 100 bis 120
Menschen vereinen. Und dieser Tribe
dreht sich um,
ja ich will mal sagen, um einen Teil des Produkts.
Spotify beschreibt das,
dass sich halt manche um den Player
kümmern, manche um die Playlists,
dann kümmert sich eine Dritte
um die Recommendations
und also verschiedene Teile der Applikation
werden quasi
durch die einzelnen
Tribes dann abgedeckt.
Und das Wichtige
ist, dass innerhalb dieses Tribes
und deswegen hatte ich auch das vorher erwähnt,
dass es sehr gut ist, um BIS und DEF
zu vereinen. Die Idee war, innerhalb
eines Tribes quasi zu dem Produkt
sowohl alle Fachexperten als auch alle
Techniker zu vereinen. Also nicht
die Trennung zwischen Fachbereich und
IT zu machen, sondern die wirklich
in ein produktzentriertes Struktur
eigentlich zuzugeben. Oder
in eine servicezentrierte Struktur.
Wenn wir uns eine Bank hernehmen, könnte
ein Tribe dann das Thema
Hypotheken sein, ein Tribe könnte es sein
Investments. Also man versucht eher
Produkte und Services zu schneiden und dann
quasi alle Experten, die es dafür braucht,
das ist eben meistens Fachbereich und IT,
und Operations, da kommen wir
genauso wieder zu dem langen Namen,
dann unter eine Struktur zu geben. Und in diesem
Tribe sind dann kleine
Squads, was im Wesentlichen agile Teams
sind. Warum heißen die Squads?
Weil nicht wirklich festgelegt ist,
mit welcher Methodik die arbeiten.
Also es sind keine Scrum Teams, es sind keine
Kanban Teams, es ist meistens eine Mischung aus
vielen Methoden und die werden
Squads genannt. Die Squads sind, ich will mal
sagen, aufgesetzt wie typisch agile Teams.
Klein, mit Product Owner,
der quasi die Richtung
vorgibt und diese
Squads arbeiten dann quasi wiederum
an Teilen des Tribes.
Und dem Tribe, dem sitzt ein Tribe Lead
vor, das heißt man hat dann auch eine
Führungskraft, die quasi die Richtung vorgibt, für
den Tribe und eine Führungskraft für alle
IT-Experten und alle Fachbereich-
Experten, die quasi darunter
dem Tribe zugeordnet sind.
Also wo es dann nicht mehr die Schwierigkeit gibt, dass man
vielleicht so zwei unterschiedlichen
Führungskräften berichten muss, sondern es
gibt wirklich quasi eine Linie nach oben
und das ist dann der Tribe Lead.
Und der dritte Aspekt, den
das Spotify-Organisationsmodell
noch vereint, ist das sogenannte
Chapter. Und damit wird ein
wenig dem beigetragen,
dass man sagt, okay, ich habe jetzt
verschiedene Experten mit
ähnlichen Skills und die sind ja meistens in den
verschiedenen Squads verstreut, zum Beispiel
ich habe eine Frontend-Entwickler
oder einen Operations-Ingenieur einfach in
vielen Teams und die zieht man
zusammen zu einem Chapter, um dort
sich quasi weiterzuentwickeln, um
Standards zu setzen, um zu sagen,
okay, wir Operations, wir
vereinheitlichen bestimmte Vorgehensweisen,
wir entwickeln uns weiter, um
bessere Operations-Guys
zu werden. Und
das ist das Chapter und der wird geführt von
einem Chapter Lead und das ist
eher so ein senioriger Leader, der versucht
quasi Standards zu setzen und seine
anderen Mitarbeiter da weiterzuentwickeln.
Das ist die Struktur quasi,
die, ich will mal sagen, quer drübergelegt
wird auf die andere
und dort dient es hauptsächlich
der Weiterentwicklung der Mitarbeiter.
Okay.
In meinen Unterlagen habe ich auch
noch die Guilden
mit dabei. Wie würdest du die dort einsortieren?
Die Guilden
sind eher so ein optionales Element.
Die Guilden sind dann
freiwillig, also die anderen drei Strukturelemente,
die ich gerade erklärt habe, sind wirklich
die Basisstruktur. Die Guilden,
da geht es dann wirklich darum,
wenn eher so Interessens
Bekundungen für ein bestimmtes Thema
gibt, die dann tribe-übergreifend
über die ganzen Organisationen gespannt
werden. Also ein Beispiel wäre hier
vielleicht eine Testautomatisierung oder
Beispiel wäre,
wir beschäftigen uns vielleicht
mit moderner Architektur oder
was auch immer. Also Guilden sind eher
etwas Freiwilliges, wo eine Community
zusammenkommt, um sich
zu einem bestimmten Thema auszutauschen.
Okay.
Ja.
Und in deinem
Whitepaper hast du ja auch geschrieben, dass die meisten
dieses
Modell, was du eben beschrieben hast,
als das Spotify-Modell kennen.
Und da muss ich mich einbeziehen. Also ich habe
das als Basis mal genommen
und das, was Spotify 2015
geändert hat,
das hast du auch sehr
schön beschrieben. Also was hat Spotify
2015 verändert,
um sich eben weiterzuentwickeln
und was ist da im Detail passiert?
Ja. Ich glaube, das ist einer so der
Kern-Message ist es auch, die ich
damit ausdrücken wollte, weil
das Spotify-Modell immer
und das kritisiere ich auch
ein wenig, dass unter dem Spotify-Modell
stark immer das 2012er
Modell quasi
referenziert wird, obwohl Spotify selber
quasi schon was gelernt hat.
Das ist jetzt auch kein Wunder.
Es sind schon wieder extrem viele Jahre
vergangen. Das ist auch schon wieder sieben Jahre her.
Und natürlich haben die auch was gelernt
aus der Struktur und haben dann auch Änderungen
vorgenommen. Zwei davon
sind eigentlich die spannendsten Änderungen.
Das sind auch die zwei größten Änderungen, die sie etwa
2015 genau um den Dreh herum geändert haben.
Einerseits
das Thema, dass sie noch mehr gewachsen
sind. Muss man natürlich auch wissen. Sie sind noch mal
von 600 auf 2000
Mitarbeiter hochskaliert bis 2015.
Und sie haben dann
mehrere Tribes wieder zugeordnet
zu einer Allianz.
Und eine Allianz ist stark
der Aspekt, dass das
ein Kundensegment ist. Also sie haben
bei Spotify Allianzen gebaut
für die
Hörer zum Beispiel. Oder
eine Allianz für die Plattenlabels.
Und eine Allianz
für noch andere Partner, die vielleicht
eher Werbung und so weiter schalten
auf Spotify. Und die Idee war,
um mehr Leimen zwischen den Produkten
zu sorgen.
Um dann auch dem Kunden ein ganzes
Portfolio anzubieten.
Ich glaube, fast in einer Bank ist das noch
einfacher zu erklären.
Wenn wir bei dem Beispiel bleiben. Du hast quasi
einen Tribe für Hypotheken. Du hast einen
Tribe für das normale Daily Banking.
Im Sinne von, wo du dein Konto hast.
Du hast einen Tribe für
Investment. Am Ende
willst du als Retailkunde
willst du ja ein Portfolio
genießen. Und du willst nicht quasi,
dass sich irgendwie alles unterschiedlich
verhält von den Produkten. Das heißt, es braucht ein
starkes Alignment. Weil wenn ich ein Privatkunde
bin, ich will ja alles aus einer Hand haben.
Ich will ja nicht, dass
mir irgendwie das seltsam vorkommt, dass das Konto
ganz anders aussieht als meine Wertpapierplattform.
Und so weiter. Also man
hat versucht, mit diesen Allianzen nochmal
darüber den Kunden
eigentlich in den Fokus zu stellen. Vorher war es eine
sehr produktzentrierte Organisation.
Indem ich quasi meine Tribes stark nach
Produkten oder nach Produktbestandteilen
schneide. Und
das hat man wieder ein wenig zusammengefasst.
Zu Allianzen, um wieder den
Kundengedanken mehr reinzubringen. Das war
eines der wesentlichen Aspekte,
die geändert wurden. Und das zweite ist,
dass schnell klar
wurde, dass dieser Tribe Lead,
von dem ich davor gesprochen habe, der ja für 100
Kollegen ungefähr zuständig ist,
und der ja sowohl IT
als auch Fachbereich verantwortet, weil er ja
dem Bereich vorsteht oder diesem Tribe
vorsteht und die Priorisierung und
die Richtung für diesen Tribe vorkippt.
Und da wurde schnell klar,
der kann nicht alles vereinen.
Wenn der eher aus dem Business kommt,
dann tut der sich extrem schwer,
die ganzen technischen Aspekte in so einem Tribe
mit zu berücksichtigen. Wenn der stark von der
technischen Ecke kommt, dann tut der
sich schwer, oder diejenige sich schwer,
alle Business-Aspekte mit zu
berücksichtigen. Und deswegen hat
Spotify da umgestellt und
haben gesagt, okay, wir
machen ein
Tribe Leadership Trio.
Also es geht nicht mehr nur um einen Tribe
Lead, um eine Führungskraft, sondern
sie hat uns dann gemacht, dass quasi eher ein
Product Lead gibt, der eher für das Business
steht. Es gibt einen Tech Lead,
der eher diese technischen Aspekte
ich will mal sagen
verantwortet. Und
es gibt einen Design Lead.
Ich glaube, der Design Lead ist schon sehr speziell für
Spotify. Ich glaube, jeder, der
Spotify schon mal benutzt hat, die haben
einfach einen starken Fokus auch auf Design,
dass alles gut aussieht und schön aussieht, auch
ansprechend aussieht und userfreundlich ist.
Und deswegen haben sie, glaube ich, da
auch nochmal einen Design Lead installiert
quasi, der die ganzen Design-Themen
verantwortet. Das sind so im Wesentlichen
die zwei großen Änderungen. Und
interessanterweise sind die heute in der Industrie,
selbst wenn sich Unternehmen
viel mit der Spotify-Struktur beschäftigen,
noch nicht so am Schirm.
Ich glaube, man muss es einfach wertschätzen,
dass die Learnings gemacht haben
und sich zumindestens das mal kritisch
anschauen und fragen, hey,
machen diese Learnings auch bei uns
Sinn, das so zu adaptieren?
Ja. Sind denn diese drei
Personen, diese drei Rollen gleichberechtigt
in der Führung?
Also,
falls man da von Führung sprechen kann,
das ist ja schon
die Frage, wie geht dort Führung an der Stelle?
Also, sind die drei gleichberechtigt?
Also, ich würde
definitiv von Führung sprechen, ja,
und im Spotify-Modell sind
die gleichberechtigt. Also, da ist schon
die Idee, dass sich die quasi als Führungs-
Trio gemeinsam
abstimmen. Ich sehe
das in der Praxis, wir haben das ja auch bei einigen Kunden
schon bemerkt, dass
ein einziger, alleiniger Tribe Lead nicht immer
ganz einfach ist, weil der einfach eine
weite Strecke von Verantwortung
und Kompetenzen mitbringen muss.
Wir haben häufig dazu tendiert,
dass wir doch einem so den minimalen
Vor-Lead geben, eher
im Sinne einer Geschäftsführung, ja,
also im Sinne eines Boards, ja, dann ist halt jemand
CEO und einen CTO
und einen CFO oder was auch immer,
wo schon alle
enorme Führungskompetenzen haben und die
am Ende auch gemeinsam das Unternehmen
verantworten, aber dass es irgendwie noch
den Vorsitzenden gibt, der
vielleicht bei kritischen Themen dann
doch eine Entscheidung trifft.
Ich glaube, die Frage, die hier stark mit
drinsteckt, ist, wie gut
versteht sich dieses Duo?
Wie gut arbeiten die zusammen
und kommen die zu einer gemeinsamen
Lösung, wo
quasi das Beste im Sinne
des Tribes oder der Allianz oder
wie auch immer dann letztendlich umgesetzt wird?
Ja, ich glaube auch, das ist
eine Frage, die wirklich an den Personen
hängt. Wie leben diese
oder wie verstehen diese Personen ihre Rollen,
wenn ich an meine Berufshistorie
zurückdenke, bei meinem ersten
Arbeitgeber, also das ist schon ein paar
Jährchen her, da hatten wir zwei
geschäftsführende Gesellschafter und die haben
das alles im Duo entschieden und
ich habe in meinen neun Jahren, wie ich
dort war, nur einmal erlebt, dass
der eine den anderen vor allen anderen
quasi auch kritisiert hat und gezeigt hat, dass
er das nicht in Ordnung fand. Ansonsten
war es immer klar, man hat immer
gemerkt als Mitarbeiter, wer hat
jetzt hier den Lead, also wer hat dort
das Thema, wo trifft er eine Entscheidung?
Und der andere hat das dann akzeptiert
und sie haben dann vielleicht das eine oder andere Mal hinten
im Kämmerlein Dinge verändert,
Entscheidungen nochmal diskutiert, aber die haben
wirklich, weil sie sich persönlich sehr gut
verstanden haben und die Grenzen,
die Entscheidungsgrenzen,
ich denke schon klar abgesteckt waren, aber auch
immer wieder neu verhandelt wurden,
die beiden haben das eben gut hinbekommen und das
habe ich danach schon immer nochmal erlebt,
also das Thema Führung und
Duo-Führung oder sogar
eine Dreier- oder Vierer- oder Fünferführung,
die Fünferführung habe ich auch schon
erlebt, das kann dann funktionieren, wenn
die fünf sich oder diese
mehr oder weniger sich gut verstehen und
eben harmonieren an der Stelle.
Jetzt hast du in deinem
Whitepaper auch ein paar Herausforderungen
formuliert und
ich denke, auf die können wir immer noch ein bisschen
eingehen. Die erste Herausforderung,
die du formuliert hast, ist
der organisatorische Schnitt von
Tribes. Du hast zu den
Herausforderungen auch immer eine Lösung formuliert,
also würde ich sagen,
wie würdest du diese Herausforderung
beschreiben und wie sieht die Lösung aus?
Ja, der organisatorische
Schnitt, genau. Also das ist eigentlich ein Punkt,
den ich schon leicht vorab
durchaus geteasert habe,
das ist halt die Wichtigkeit oder das, was das
Spotify, diesen Ansatz so
spannend macht, ist, dass man wirklich
versucht, einen produktzentrierten oder einen
servicezentrierten Schnitt reinzubekommen
und dass man dann wirklich
eben Business und IT
und das kann bis in den Ops-Bereich
reingehen, unter eine Struktur
bringt, unter eine Führungskraft oder von mir
aus auch gerne ein Führungsduo oder Führungstrio,
aber dieses Thema mal in
eine Einheit zu bekommen und obwohl das
eine Kernthese dieses ganzen
Modells ist, beobachte ich immer wieder,
dass sich Unternehmen schwer tun, wirklich
alle Skills reinzupacken
unter eine
Einheit und da will ich einfach
nur mitgeben, auch wenn es schwer ist und
ich kann das durchaus nachvollziehen, dass dieser Schnitt
von den Tribes und dass da viele Überlegungen
auch reinfließen müssen, aber
es ist ein zentrales
Thema, das einfach
betrachtet werden muss und wo ich wirklich
die Empfehlung gebe, tun Sie das.
Tun Sie quasi wirklich
Business, IT unter eine Einheit
zusammen, weil sich da einfach die Zusammenarbeit
wesentlich verbessert, weil man letztendlich
auch hinter gleichen Zielen arbeitet
und nicht mehr dieses
zwei Bereiche, zwei Silos.
Und der zweite Aspekt, der noch in
diesen organisatorischen Schnitt
reinfällt, ist diese
Thematik nicht zu groß zu werden.
Viele Unternehmen tendieren
dann auch dazu, Richtung 150 zu gehen,
oder vielleicht sogar noch mehr.
Ein Tribe sollte klein sein.
Man spricht immer so gern von 100 Personen
oder vielleicht ein wenig mehr.
Im Spotify-Modell ist das auch referenziert,
im Whitepaper von denen. Hat auch viel mit
der sogenannten Dunbar-Zahl zu tun.
Man hört ja auch schon raus, ein Tribe,
Stamm, kommt ja auch so ein bisschen
von den indigenen Völkern.
Und die Idee von der Dunbar-Zahl war auch,
dass es nur eine
Reihe von Menschen gibt, die man wirklich
persönlich kennen kann.
Im Sinne von,
man kann so, und da gehen die Zahlen ein wenig auseinander,
aber so 120 bis 130,
die kann man wirklich gut kennen, mit denen kann man
eine persönliche Beziehung aufbauen.
Und die Idee ist quasi, Organisationsstrukturen
nur so klein zu schneiden, dass man auch
so ein Gefühl hat, man gehört dazu.
Wie zu einem Stamm, wo quasi
alle das gleiche Ziel verfolgen und so eine Art
an Verbindung auch miteinander haben.
Selbst wenn wir in Richtung
100 gehen,
wenn wir uns das von der,
ich will mal sagen, von der Führungsspanne ansehen,
gerade wenn wir nur einen Tribe Lead haben
und kein Führungs-Do, dann werden
die Führungsspannen einfach extrem groß.
Ich glaube, Agilität hat
schon was damit zu tun,
keine steilen Hierarchien mehr zu haben,
aber Agilität hat
definitiv nichts damit zu tun,
riesige Führungsspannen zu haben, weil
Agilität oder agile Führung oder moderne
Führung hat ja viel auch damit zu tun, dass ich mich
mit den Menschen beschäftige, dass ich die
vielleicht sogar coache und intensiv auf ihrem Weg
begleite. Und das kann ich natürlich nicht, wenn ich
eigentlich Menschen zu führen habe.
Und einfach nur mal beim Beispiel
zu bleiben von 100 Mitarbeitern,
wenn wir da kleine autonome
agile Teams drunter packen, dann
sind das ja in der Regel mindestens 10,
sollten ja eigentlich eher sogar 15
sein. 15 agile Teams,
wenn wirklich jeder von denen einen Product Owner hat,
dann haben wir schon mal 15 Product Owner,
die irgendwie nach oben berichten.
Dann gibt es noch die ganzen Chapter Leads,
die quasi dafür sorgen,
dass die ganzen Expertisen
aligned sind, also dass die Datenbankentwickler
aligned sind, dass die UX-Designer aligned sind.
Also wenn wir dann nochmal 15
Chapter Leads haben, dann müssen die auch
irgendwie alle nach oben berichten.
Und man kann da schon erkennen,
das wird schwierig. Und man
kann sich natürlich dadurch behelfen, indem
man statt einem Tribe Lead so eine Art Führungs-
Duo oder Führungs-Trio einsetzt.
Aber nichtsdestotrotz sollte
man hier versuchen, nicht zu groß zu schneiden,
weil das macht diese Führungsspannen
extrem groß. Und das
ist definitiv auch nicht förderlich
in einem agilen Umfeld.
Das finde ich eine interessante Aussage,
die würde ich nochmal ein bisschen hinterfragen
oder mit einem anderen Podcast
Beispiel einfach mal
in Frage stellen, diskutieren.
Ich weiß gar nicht, wann das war,
das ist schon ein paar Podcast-Folgen her,
die
Swiss Re, Schweizer Rückversicherung,
die haben, wenn ich das damals richtig
verstanden habe, für sich gesagt,
wir erhöhen die Führungsspannen, gerade
bei den Führungsrollen,
also erste und zweite Ebene, damit
sie wegkommen vom Mikro-Management.
Also wie passt das zusammen?
Du hast ja eigentlich genau das Gegenteil eben formuliert.
Zumindest, wenn ich es auf den ersten
Blick richtig verstanden habe.
Also klar,
von dem Mikro-Management will ich
absolut nicht hin. Aber wenn
ich jetzt da meine Führungskraft habe, die sich
wirklich viel auch damit beschäftigt,
eine Strategie zu entwickeln.
Also ich nehme jetzt einen Tribe Leader an,
der führt vielleicht bei einer kleinen Bank
den Bereich
Online-Konten oder was auch immer.
Ich glaube,
vieles der Zeit sollte eigentlich
in die Strategiearbeit fließen.
Wie wollen wir uns positionieren?
Was ist das Why dieser
Produkte, die wir da an die Kunden bringen wollen?
Wie müssen sich die verändern?
Verändert sich vielleicht sogar das Geschäftsmodell?
Also alle Aspekte, die mit Strategie reinfließen.
Und wenn ich sage, dafür wird mal ein beträchtlicher
Anteil der Zeit verwendet,
Hausnummer
die Hälfte der Zeit und ich teile
die restliche Hälfte meiner Zeit
zehn Mitarbeiter an, dann hat
das gar nicht mehr so viel mit Mikro-Management
zu tun.
Weil dann habe ich gar nicht mehr so viel Zeit für jeden
Einzelnen.
Ich glaube, es ist auch wichtig, wie nutze ich diese Zeit?
Wenn ich das Beispiel jetzt
weiter exerziere, dann könnte ich mir
irgendwie komme ich dann vielleicht auf einen Case von
ich habe zwei, drei Stunden für den Mitarbeiter pro Woche.
Was gar nicht so viel ist.
Weil in der Regel ja doch irgendwie
noch ein paar andere Sachen dazu kommen,
außer Strategie und Mitarbeiterführung.
Also wenn es gut ist, selbst mit einer kleinen
Zeit, dann komme ich auf irgendwie zwei Stunden pro Mitarbeiter.
Und dann ist die Frage, wie nutze ich die?
Nehme ich die zwei Stunden her
und erkläre dem Mitarbeiter ganz genau,
was er diese Woche zu tun hat?
Oder versuche ich ihm eher zu helfen,
sich weiterzuentwickeln?
Vielleicht mehr Verantwortung zu übernehmen?
Und so weiter.
Ich denke, ein gesundes
Zeit-Invest pro Mitarbeiter
ist absolut notwendig.
Ich glaube, es geht vielmehr
um die Frage,
wie nutze ich diese Zeit?
Und ich kann durchaus radikale Ansätze
verstehen, wo ich sage, okay,
wir kriegen dieses Mikro-Management einfach
nicht weg. Und ein radikaler Schritt
mag sein, ich drehe die Führungsspanne so hoch,
dass ich es nicht mehr schaffe.
Das ist natürlich auch ein legitimer Weg.
Ich glaube, manchmal eine verfahrene Situation
braucht auch
nicht verfahrene Lösungen,
aber braucht auch innovative Lösungen
oder krasse Lösungen.
Krass innovativ, okay.
Insofern, das passt dann schon
zusammen. Das ist ja auch immer der
Punkt, dass man natürlich immer
die individuelle Situation sich anschauen
muss. Das finde ich auch das Schöne an dem
agilen Vorgehen. Es gibt
kein Patentrezept. Es gibt natürlich
wichtige Dinge, die man beachten sollte, aber es
gibt eben kein Patentrezept. Und vielleicht
war das wirklich genau diese
krasse innovative Lösung oder
der Ansatz zu sagen, okay, wir müssen jetzt
den Mikro-Managern
das Mikro-Management
austreiben und erhöhen mal
ganz krass die Führungsspanne.
Dann kann man ja nachher auch noch ein bisschen
zurückfahren an der Stelle.
Und das ist ja auch nicht in Stein gemeißelt.
Haben wir ja bei Spotify gesehen. Die haben ja auch
ihre Dinge verändert und entsprechend
auch die Organisation angepasst.
Jawohl.
Du hast noch die Herausforderung
angesprochen, die Rolle des
Product-Owners. Was ist denn
aus deiner Sicht, gerade auch
in dem Wildpaper, die Herausforderung
in der Rolle des Product-Owners?
Also,
der Spotify-Ansatz
setzt ganz stark darauf,
quasi so ein
De-Layering zu machen, also quasi weniger
Führungsebenen
einzusetzen. Und durch dieses
De-Layering bricht da ein wenig die mittlere
Führungsebene weg.
Und das äußert sich ja auch ein wenig, was ich mit dem
gerade beschrieben habe, diese Führungsspannen,
diese großen.
Also, der Tribe Lead verantwortet
eigentlich den ganzen Bereich mit bis zu 100
Mitarbeitern und darunter gibt es eigentlich
Product-Owner und Chapter Leads, die jeweils ein
kleines Team von 9 bis 10
Personen verantworten. Oder
zumindest führen. Und
die Herausforderung, die dann besteht,
ist, gerade bei größeren Tribes,
der Tribe Lead kann nicht mehr die Strategie
für alle Produkte, die darin gemacht
werden oder für alle Produktbestandteile.
Die Strategie, der
kann die nicht verantworten, weil das einfach zu viel ist.
Bleiben wir bei dem Beispiel von 15
Teams. Wenn wir da 10 bis 15 Teams
darunter haben, ist die logische
Konsequenz, der Tribe Lead wird nicht
die Strategie machen von
diesen ganzen Teams.
Und früher hatte man dafür
stark, das ist mein Eindruck, früher hatte man
dafür stark quasi das mittlere Management,
die irgendwie zwischen 20
bis 30 Mitarbeiter geführt haben
und dann für einen Teil dieses Produktes
stark auch für die Strategie verantwortlich waren.
Das wandert
quasi in dem Modell viel zu den Product-Ownern
und das ist absolut gut und
auch notwendig. Letztendlich spricht
ja auch Agilität ganz stark von
es soll extrem viel Verantwortung auch bei den
Product-Ownern sein. Die sollen verantwortlich sein
für die Strategie. Ich glaube
in vielen Unternehmen ist das einfach noch nicht gewohnt
und da kommen wir dann in die Situation,
dass die Product-Owner einfach ein wenig
überfordert sind. Und das stelle
ich quasi auch da als eine
der Herausforderungen. Dass
die Product-Owner teilweise überfordert sind
mit dem
mit der vielen Verantwortung, die sie bekommen
und ein zweiter
Aspekt ist, dass die
ich will mal sagen, die Weiterentwicklung auch auf
der Karriereleiter, wenn man das so nennen will,
ich will nicht sagen
schwieriger ist, aber
es gibt quasi Product-Owner, du führst quasi ein
kleines Team von acht, neun
Kollegen und der nächste Schritt wäre
Tribe Lead, wo du vielleicht gleich
100 Personen hast.
Und da ist ja ein riesen Schritt zwischen den zwei
Rollen. Und früher hat man quasi sich
advanced, nach dem Motto, man ist mal auf die nächste
Ebene gewandert, konnte dann mit 20 bis
30 ausprobieren und ist dann erst quasi
zu einer Tribe Lead Ebene gekommen.
Dass durch das die mittlere Ebene
nicht mehr gibt, ist auch die Frage, wo lernt man?
An das so einen größeren Kontext zu führen.
Natürlich gibt es andere Möglichkeiten.
Man kann irgendwie ein Projekt dann
bekommen, ein wichtiges, wo man viel mit
Alignment machen muss und dann auch wieder mehrere Teams steuern.
Ich will einfach nur sagen,
da fehlt was in der Mitte, was
sicherlich gut ist, um mal
auch quasi diese
ganz vielen Ebenen in vielen Unternehmen
auch auszudünnen, aber
nicht alles war immer schlecht an den alten
Strukturen. Man muss auch immer mitdenken,
was fehlt mir vielleicht durch diese
Struktur und das ist heute die Strategie für
die einzelnen Produktbestandteile oder für die einzelnen
Produkte innerhalb eines Tribes und
das müssen jetzt die Product Owner mitmachen.
Einfach auch ein wenig
Enablement und
Aufbau der Product Owner.
Also ich glaube, du hast hier einen Punkt angesprochen.
Jetzt so beim Zuhören und der Diskussion mit
dir habe ich mir überlegt,
das wäre auch mal ein Thema für einen Podcast,
nämlich genau die Herausforderungen
der Rolle des Product Owners
mal mit jemandem zu besprechen,
der da so seine Erfahrungen gemacht
hat, weil ich glaube, dass wir über die
Herausforderungen des Scrum Masters
viel reden und viel lesen,
zumindest geht es mir so,
weil das ja auch Organisationsveränderungen hat
oder impliziert, aber
ein Product Owner hat ja auch
eine Menge Herausforderungen und diese, die du
eben angesprochen hast, die ist mir noch nie
so bewusst geworden, also im Sinne von
wo sind für ihn Karrieremöglichkeiten,
wo sind für ihn Entwicklungsmöglichkeiten.
Also insofern, wenn das ein
Product Owner hört, diesen Podcast,
darf sich gerne melden, dann würde
ich gerne mal mit einem echten, leibhaftigen
Product Owner sprechen und
seine Erfahrungen dazu hören.
Vielleicht kennst du ja auch einen, Christoph,
kannst auch einen empfehlen. Ja, gerne.
Eine Herausforderung hast du noch
beschrieben, die nennt sich
die Ausgestaltung des Chapter Leads
und da hast du ja sogar im Prinzip zwei Lösungen
vorgeschlagen oder ausformuliert
in dem Whitepaper.
Genau, ich denke dieses,
gerade dieses Thema Chapter
und Chapter Lead ist so,
ich will nicht sagen das große Mysterium,
ja, aber es ist ein Thema,
was wirklich am meisten Unsicherheit
auch auslöst bei denen,
die sich diesem Modell annehmen
und versuchen eine Art dieses Modells
zu implementieren.
Es stellen sich nämlich viele Fragen,
ist der Chapter Lead
die disziplinarische Führungskraft
für die anderen?
Arbeitet der Chapter Lead mit
in einzelnen Scrum Teams
oder in einzelnen Squads sozusagen
oder ist er einfach nur da, um quasi
das Chapter voranzutreiben?
Ja, Spotify hat da zwar recht klare Antworten
in ihrem Paper, also
es ist die disziplinarische Führungskraft
und ja, der arbeitet mit,
aber in der Praxis, dann bei der Implementierung
tun sich extrem viele schwer, genau das zu implementieren
und das beruht auch, glaube ich, auf dem Teil daran,
ich meine, wir haben es hier mit einem schwedischen
Startup zu tun, die haben eine andere
Führungskultur, vielleicht ist bei denen
dieses Thema disziplinarische Führungskraft
gar nicht so in dem Maße
präsent,
wie das vielleicht bei uns
in Mitteleuropa ist.
Also da schwingen ein paar Aspekte mit
und ich denke, genau da gibt es
ein paar Lösungen, man kann natürlich
jetzt viel darüber diskutieren, wie könnte
man das so bauen, dass das passt
und dass man nicht einfach nur die alte
Führungskraft nimmt und einfach nur
Chapter Lead statt Team Lead draufschreibt,
weil das wollen wir eigentlich nicht,
dann hat man eigentlich nichts erreicht oder nichts geändert
und ein möglicher Weg
kann sein,
dass wir den Weg dieser
Lateralen Führung konsequent weitergehen,
dass wir sagen, okay, wir haben
jemanden, der führt das Team
im Sinne eines Purpose, im Sinne einer
Vision, das ist der Product Owner, der führt
lateral, wir haben
eine Rolle und das
kann entweder der Scrum Master sein oder
vielleicht ein Agile Coach oder ein Kanban Coach,
der führt das Team eher im Sinne der
Selbstorganisation, also ein Team in die
Selbstorganisation zu bekommen und der dritte
Aspekt ist dieses Mastery, das kommt aus
dem Daniel Pink Modell,
wo quasi
Daniel Pink sagt,
um gut arbeiten zu können, brauchst du
einen Purpose, Autonomie und
Mastery, also du musst es auch können
und
dieses Können, dieses Mastery liegt beim
Chapter Lead und ich frage mich, warum kann
der nicht auch lateral sein, also
Product Owner ist lateral, Scrum Master ist lateral,
das ist irgendwie alles so haken dran,
das haben wir gelernt, die letzten Jahre auch
in dem Scrum Kontext, warum nicht auch
der Chapter Lead lateral
und dann können sich ja diese
vielen Führungsaufgaben, die es gibt, teilen
und die disziplinarischen
Letztverantwortung haben wir dann nur noch beim
Tribe Lead, der sich natürlich nicht um das Daily
Business kümmert und eigentlich nur Eskalationen
vielleicht managt und alle anderen
Führungsaufgaben liegen quasi bei diesem
Trio,
ich glaube das, was die Schwierigkeit macht, weil diese Idee
klingt per se gut, nach dem Motto, wir
machen alle zu lateralen Führungskräften,
man muss sich halt die Gedanken machen, wie gehe ich
mit diesen ganz heiklen Themen um,
wie Gehaltsfindung, wie Feedback-Prozesse,
wenn die nicht mehr
von einer Person gemacht werden, man müsste
quasi sich kümmern darum, dass es daran
60 Grad Feedbacks installiert werden,
man müsste sich darum kümmern, dass vielleicht
ein Gehaltsfindungsprozess nicht mehr durch eine
Person stattfindet, sondern vielleicht in der Gruppe
diskutiert wird, wie jemand eingeschätzt
wird, wie viel der zu verdienen
wird oder was auch immer.
Und ich glaube, weil das so ein
sensitiver Bereich ist, tun
sich ganz, ganz viele Unternehmen schwer,
dieses Modell quasi zu Ende zu führen.
Wenn man diesen Weg
nicht konsequent gehen kann, aus welchen Gründen
auch immer, das wäre dann die
zweite Alternative, dann habe ich
für mich so wahrgenommen,
wichtig ist, der Chapter Lead
okay von,
also quasi der Chapter Lead kann
disziplinarische Führungskraft sein, wichtig ist
einfach, dass sich der super viel Feedback
holt, dass der quasi so ein
360 Grad Feedback auch simuliert,
mit vielen Menschen spricht und
dann eine möglichst gute Entscheidung
auch trifft, um den Kollegen
da eine faire
Vergütung letztendlich zu geben.
Und bezüglich der Frage, soll der
mitarbeiten oder nicht, da trenne ich es gerne
in zwei Aspekte.
Wenn für dieses Chapter
ich will mal sagen,
wenig Alignment notwendig ist, wenig
Standardsetzung, Hausnummer
vielleicht unter 20%, dann
kann man den mitarbeiten lassen in einem
Squad, wobei wir uns
immer klar sein müssen, sobald
jemand aus dem Squad
andere Themen auf dem Tisch hat,
er ist nicht mehr fokussiert. Das ist ja
eigentlich einer der Kernverletzungen schon
gegen agile Werte,
dass jemand quasi nicht voll fokussiert ist für das
Team und der wird immer zerrissen sein, diese Person.
Wenn die nicht so viel nebenbei
zu tun hat, dann mag das noch legitim
sein. Ich sehe halt oft Chapter,
wo quasi viel auch im Alignment
zu tun ist, viel in der Standardsetzung,
dass ein Datenbankchapter sich
damit beschäftigt, welche Datenbanken
setzen wir ein, um nicht 30 Datenbanken
einzusetzen, sondern vielleicht eher ein
kleines Set von 5. Ich tendiere
dazu, wenn nicht
so viel Alignment, wenn nicht so viel Standard,
dann kann man die in einem Squad
mitarbeiten lassen, wenn viel da
zu tun ist. Klassisches Beispiel auch
UX-Design. Da geht es darum, einen
Style Guide zu bauen. Wie wollen wir als
Unternehmen am Markt wirken? All diese Dinge
sind ja in so einem UX-Chapter zu
besprechen. Da würde ich eher dazu tendieren,
den Chapterlead nicht mitarbeiten zu lassen,
operativ in einem Squad.
Wichtig ist mir
vielleicht da noch als letzten Punkt, wenn der
nicht mitarbeitet in einem Chapter,
er sollte trotzdem nah an der Basis sein.
Am Ende wollen wir vermeiden, dass irgendwie so
ein Elfenbeinturm-Management
rauskommt.
Aber auch das hängt dann natürlich häufig
von den Personen ab. Also wie sie
sich sehen, wie sie ihre Rolle sehen
und
zum Schluss bleibt immer noch der Mensch dann,
der die Rollen
quasi ausfüllt an der
Stelle. Aber ich finde natürlich,
und das
ist dann auch wiederum
das ist dann ja auch immer
empirische Prozesssteuerung.
Gut, jetzt habe ich einen Punkt
noch. Wir sind ja auch gut in der Zeit.
Du hast im Whitepaper noch den
letzten großen Punkt, den letzten wichtigen Punkt
stehen, Redesign der Aufbauorganisation.
Ein großer Umbruch.
Was meinst du damit und
was würdest du da empfehlen? Was sind so deine
Erfahrungen in dem Umfeld?
Ich will damit ausdrücken, immer wenn man sich
am Gedanken macht, um eine Struktur zu ändern,
das hat immer eine große Auswirkung.
Wenn ich eine Struktur umstelle, meistens ist
irgendwie ein großer Teil meines Unternehmens betroffen
oder ein sehr relevanter Part.
Was ich da mitgeben möchte ist,
dass sie sich einfach Gedanken darüber
tauchen sie quasi nicht oder lesen sie
nicht nur einfach das Spotify Whitepaper
durch und versuchen sie es dann zu implementieren,
sondern man sich wirklich tief in
den Kontext auch reindreht
und das quasi gut
ausarbeitet. Ich will sagen, man sollte quasi
nicht unvorbereitet
da in so einen großen Wandel gehen.
Das ist die große Message. Einfach zu sagen,
immer wenn man an der Struktur dreht, das ist
jetzt nicht irgendwie, wir ändern
in einem Team die Teambesetzung,
wo nur eine kleine Auswirkung ist, sondern
eine Strukturänderung hat meistens mit
großer Unsicherheit zu tun, mit einem großen
Umbruch und deswegen ist die Message
lieber gut vorbereiten,
der Invest ist es auf jeden Fall wert.
Ja, gut, Spotify sagt
ja selber auch, das zitiere ich
hier mal so, wenn ich das Modell erkläre,
kapieren und nicht kopieren
an der Stelle. Das ist ein
kleiner Buchstabe, der doch
den Sinn ganz arg dreht an der Stelle.
Ja, ich würde da noch
ganz kurz nochmal nachfragen,
auch weil du ja da noch eine Menge Erfahrung hast.
Klar, man muss sich Gedanken
machen, wohl überlegt,
das ist keine kleine Veränderung.
Wenn ich in die Gespräche
einsteige in dem Umfeld, dann kommt
häufig dann die Frage, wenn Leute verstanden
haben, was hinter DevOps steht,
müssen wir jetzt die Organisation
verändern oder müssen wir sie nicht verändern? Und meine
Antwort ist dann so sinngemäß,
ihr müsst sie nicht verändern,
jedenfalls würde ich das nicht als ein großes
Reorg-Projekt sehen, das wäre
nämlich dann das zweite, dritte, vierte,
fünfte Reorg-Projekt, wo alle dann sagen, ah,
alles klar, jetzt machen wir ein Jahr
Spotify und dann machen wir irgendwann im nächsten
Jahr das nächste, also wo quasi
das Unternehmen sich auch mit Reorg
beschäftigt, das wäre nicht
mein Ziel, aber natürlich, oder meine Empfehlung
war, man muss natürlich schon Dinge verändern.
Also, wie sind so deine Erfahrungen? Würdest
du sagen, eher auf
der Team-Ebene kleinere Teams bauen
oder würdest du sagen, man sollte sich Bereiche
vornehmen oder eine ganze Organisation,
weil hat ja alles Vor- und Nachteile?
Ja,
also tatsächlich ist immer die Frage, na, wie
schnell will man den ganzen Wandel
auch haben? Und mir ist natürlich klar,
dass gerade so Reorganisations-Projekte
immer negativ besetzt sind,
und da auch schon viele, und das meine ich
auch damit, so eine Reorganisation hat immer mit
viel Schmerzen zu tun, also es ist wichtig,
sich da intensiv mit den Inhalten auseinanderzusetzen.
Meine Empfehlung wäre,
vielleicht Bereich für Bereich vorzugehen,
also nicht ganz den
harten Schnitt zu machen und wirklich ganz
große, ganzes Unternehmen umzustellen,
sondern, ich glaube, irgendwann muss
man aus der Team-Ebene, ich glaube, am Anfang startet
man immer sehr schnell mit ein paar Teams
umstellen, ich glaube, das ist auch alles legitim,
nur an irgendeinem Punkt, wenn alles
in den Teams optimiert ist, dann stellt sich halt
wirklich die Frage, fasse ich jetzt vielleicht
bis DevOps
nicht nur im Team zusammen, sondern
packe ich die auch alle unter eine Führungskraft?
Und ich glaube, das ist der springende Punkt, wo
dieser Ansatz auch so wertvoll ist,
zu sagen, okay, wir haben den Punkt überschritten,
wo wir sagen, wir machen da gut Agilarbeit
zusammen, wir wollen in
der letzten Konsequenz gehen und
auch noch die Struktur anpassen. Und dann kann man
mal sinnvoll sein, vielleicht einfach ein Produkt
herzunehmen und dort einfach aus den
verschiedenen Bereichen, wie IT, Operations
und Fachbereich, aus
allen drei Standardbereichen,
die man gerade im Unternehmen hat, löst
man diese Einheit raus, die quasi
für das eine Produkt zuständig ist
und dann macht man einfach mal eine Business Unit und
probiert das auch aus, macht erste Erfahrungen.
Da kann ja auch wieder der lernende Ansatz
sinnvoll sein, zu sagen, okay, wir probieren das
mal für ein Produkt aus und wenn mein Unternehmen
zehn Produkte oder was auch
immer hat, dann ist das mal ein kleines
Lernfeld, wo trotzdem genug Menschen
betroffen sind, keine Frage,
aber dort das mal auszuprobieren
und auch seine eigenen Learnings zu machen, um
dann vielleicht später mal in ein
größeres Reorganisationsprojekt zu gehen und
Dinge groß anzupassen.
Und mit den Erfahrungen, die
man aus diesem einen Bereich gewonnen hat,
das entsprechend dann eben
fortzuentwickeln.
Klingt für mich nachvollziehbar, also schon
nicht in einzelnen Teams,
natürlich in einzelnen Teams zu starten, aber dann, wenn man
das ein bisschen ausweitet, dann
wirklich einen zusammenhängenden Bereich
zu nehmen, wie auch immer man den gestaltet
oder schneidet an der Stelle.
Ja Christoph, herzlichen Dank.
Wir haben jetzt die
geplante Zeit etwas überschritten, aber
ich glaube, oder hoffe, dass das für die
Zuhörer kurzweilig ist, dass sie da
sehr gut zuhören können und dass sie vor allen Dingen
viele mitnehmen. Und wenn dann
Fragen sind, natürlich kann man in den
Whitepaper ein paar Sachen nachlesen.
In den Whitepaper sind auch viele andere Quellen
verlinkt und
nochmal angegeben. Also ich glaube, das könnte
für den einen oder anderen oder sollte
der Einstieg sein, sich dann nochmal,
wie du auch sagst, mit dem Spotify
Modell intensiver zu beschäftigen
und nicht im Jahre 2012
aufzuhören, sondern
2015 mindestens mal zu nehmen,
was dort entsprechend beschrieben ist.
Gut, also vielen Dank von mir.
Gibt es noch irgendetwas, was du
noch sagen willst,
was du noch nicht untergebracht hast
in dem bisherigen Gespräch?
Ich glaube, das ist
am Ende gut zusammengefasst, ja.
Also quasi sich tiefer damit zu
beschäftigen, auch mal über die
Learnings quasi der anderen Unternehmen nochmal
drüber zu gucken und
ansonsten, genau,
könnt mich gerne kontaktieren.
Ich stehe auch für Fragen zur Verfügung und ich bedanke mich
sehr herzlich bei dir, Dirk,
dass ich heute mit dir sprechen durfte über
mein Whitepaper. Dankeschön.
Vielen Dank.