#122 Ich hasse Re-Orgs

Die Umstrukturierung der Firma: Hart für alle oder eine neue Chance?

Firmen, ihre Produkte aber auch ihr Umfeld ändern sich ständig. Um wettbewerbsfähig zu bleiben, um weiter Profit zu erwirtschaften, müssen Unternehmen sich (intern) ändern. “Wer nicht mit der Zeit geht, geht mit der Zeit”. Interne Umstrukturierungen sind somit ein notwendiges Übel bei jeder Firma von einer gewissen Größe. Sie kommt, auch wenn man es nicht will, und ist notwendig, um die Organisation in die Richtung zu bewegen, damit die Unternehmensziele erreicht werden.

Umstrukturierungen, sogenannte Reorgs, sind oft negativ behaftet. Doch warum ist das so? Darum geht es in diesem Podcast. Wir klären, was Reorgs eigentlich sind, wozu und mit welchem Zweck diese durchgeführt werden, wie eine Reorg oft bei den Individual Contributern gesehen wird, wie es zu einer Reorg kommt und wie diese durchgeführt wird, aber auch wie du selbst das Beste daraus machen kannst.

Bonus: Warum Consultants im Haus nie was Gutes sind.

*** Diese Episode wird gesponsert von ... Dir: https://engineeringkiosk.dev/kaffee ***

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Gerne behandeln wir auch euer Audio Feedback in einer der nächsten Episoden, einfach die Audiodatei per Email an stehtisch@engineeringkiosk.dev.

Sprungmarken

(00:00:00) Unternehmens- und Teamumstrukturierungen (Reorgs)

(00:03:49) Credibility: Warum sprechen wir über Reorgs?

(00:05:57) Was ist denn eine Re-Org?

(00:08:18) Buy us a coffee

(00:09:40) Was ist denn eine Re-Org?

(00:20:31) Produkte werden bei einer Re-Org beendet

(00:27:48) Die Flughöhe vom Management und Detail-Probleme bei der Re-Org

(00:30:25) Wie startet man eine Re-Org?

(00:39:15) Team-Strukturen abseits von Spotify bei einer Re-Org

(00:43:50) Ausführung und Kommunikation einer Re-Org

(00:54:12) Es steckt viel Arbeit hinter einer Re-Org

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:00:57)

Willkommen zurück beim Engineering-Kiosk. In dieser Episode widmen wir uns einem Thema, das viele von uns lieber meiden würden, den berühmt-berüchtigten Unternehmens- und Teamumstrukturierungen. Besser bekannt als Re-Orgs. Wir nehmen euch mit auf eine Reise durch die Tiefen der Re-Orgs, von den unvermeidlichen Herausforderungen, aber auch bis hin zu den unerwarteten Chancen, die solche Veränderungen nämlich bieten können. Wir beide haben schon ein paar Re-Orgs mitgemacht, deswegen teilen wir auch gerne unsere eigenen Erfahrungen in dieser Episode. Denn ihr wisst ja, nach der Re-Org ist vor der Re-Org. Also, wir springen direkt rein und los geht's. Dieser Podcast zeichnet sich unter anderem dafür aus, dass wir uns nicht nur auf die technischen Themen fokussieren und immer nur über Algorithmen, die neueste Programmiersprache oder die neue Version von React sprechen, sondern dass.

Wolfi Gassler (00:00:57 - 00:01:04)

Wir... Wann haben wir jemals über die neueste Version von React gesprochen? Hallo? Wir machen Evergreens. Wir sprechen sowieso nie über Frameworks.

Andy Grunwald (00:01:04 - 00:02:10)

Und weil das ein Evergreen ist, erwähne ich einfach Sachen, die vielleicht noch in die Zukunft kommen könnten, falls diese Episode dann stark in der Vergangenheit gehört wird. Nein, aber wir fokussieren uns auch, und das ist uns ganz besonders wichtig und das liegt uns auch am Herzen, auf Themen, die eigentlich jede Softwareentwicklerin und jeder Softwareentwickler betreffen, ob man will oder nicht. Und da geht's dann halt auch um das eigene Team, das Gehalt, die Karriere, Stakeholder-Management und Co. Heute haben wir wieder so ein Thema und das ist ein Thema, wo oft man eigentlich gar nicht so einen großen Steak drin hat, aber irgendwie doch. Man kann kaum mitwirken, ist aber irgendwie davon betroffen und man kann es auf jeden Fall nicht wegreden oder man kommt nicht drum rum. Heute sprechen wir mal ein bisschen über Umstrukturierungen von Firmen, von Teams, sogenannten Re-Orgs. Und Orks, hört sich an wie bei Warcraft gerade oder so. Natürlich Orks mit G und nicht mit O-R-C-S. Wolfgang, eine Frage. Was ist deine erste Intention, dein erstes Bauchgefühl, dein erster Gedankengang, wenn du das Thema Re-Orks hörst?

Wolfi Gassler (00:02:10 - 00:02:21)

Es kommt drauf an, in welcher Position. Wenn ich mal aus der Angestelltenrichtung auf das Thema blicke, dann sind Re-Orgs immer sehr, sehr, sehr zeitaufwendig.

Andy Grunwald (00:02:21 - 00:02:24)

Zeitaufwendig? Meine erste Intention ist immer negativ.

Wolfi Gassler (00:02:25 - 00:02:41)

Ja, das ist ja negativ. Das heißt viel, viel Arbeit. Da kommt eine Re-Org, das heißt, alles, was wir normal machen, können wir mal auf die Seite schieben. Und wir machen nur mehr Kommunikation, Konflikte, Problemchen, überall alles in irgendeiner Form diese Re-Org umsetzen. Also ganz, ganz viel Arbeit und keine normale Arbeit.

Andy Grunwald (00:02:42 - 00:03:03)

Die normale Wahrnehmung ist bei meiner Seite auf jeden Fall immer negativ. So, ah, Mist, jetzt schmeißt man wieder alles über den Haufen und jetzt wurden schon wieder die Wände eingerissen, die ich gerade irgendwie hochgemauert habe. Also irgendwie eine starke Veränderung. Aber was denkst du Wolfgang, warum wird eine Re-Org so negativ behaftet angesehen? Warum ist da immer so ein Minustouch dabei?

Wolfi Gassler (00:03:04 - 00:03:27)

Ich bin mir gar nicht sicher, ob es nur Reorgs sind, aber ganz allgemein Änderungen, die von außen kommen, die von außen entschieden werden, wo ich ja selber wenig Einfluss darauf nehmen kann, weil wenn ich selber irgendwie mein Lieblingsframework da austausche und gegen eine neue Technologie austausche, dann bin ich total happy und da ist Änderung gut. Aber sobald Änderung von außen kommt, ist sie üblicherweise schlecht, weil ich sie nicht entschieden habe. Und ich glaube, das ist das grundsätzliche Problem bei Reorgs.

Andy Grunwald (00:03:27 - 00:03:36)

Das bedeutet, wenn du jetzt als Chef deiner Firma eine Re-Org machen würdest, würdest du die nicht als negativ ansehen?

Wolfi Gassler (00:03:36 - 00:03:48)

Ja, wenn sie negativ wäre, würde ich sie ja hoffentlich nicht machen. Also wenn ich entschieden habe, etwas zu ändern und eine Re-Org durchzuführen, dann sähe ich ja hoffentlich positive Dinge da drin. Sonst würde ich sie ja hoffentlich nicht machen.

Andy Grunwald (00:03:49 - 00:04:09)

Jetzt sind wir beide ja nicht Geschäftsführer einer großen Firma mit ganz vielen Leuten. Warum können wir also über dieses Thema sprechen? Weil wir sind ja jetzt auf der negativen Seite. Wir waren ja im Angestelltenverhältnis oder 50 Prozent dieser Podcast-Source sind es bereits noch. Warum können wir also jetzt über das Thema RE-AUC sprechen? Warum sollten diese Leute uns jetzt zuhören?

Wolfi Gassler (00:04:09 - 00:04:44)

Ja, wenn ich mir so überlege, meine letzten zehn Jahre so mal anschaue, dann sind die eigentlich auf meiner Seite zumindest ziemlich geprägt von Re-Orgs. Also egal wo, wie ich gearbeitet habe, ich bin auf verschiedenen Seiten gesessen und in verschiedenen Positionen, aber Re-Orgs sind eigentlich fast an der Tagesordnung gestanden. Und vielleicht habe ich mich mittlerweile so daran gewöhnt, Änderungen durchzuführen, dass ich das ja mittlerweile als Consultant eigentlich auch mache, weil irgendwie das Geschäft von einem Consultant ist ja irgendwo Änderung. Also wenn dich jemand einlädt oder holt, irgendwas zu verbessern, ist es immer mit einer Änderung verbunden.

Andy Grunwald (00:04:45 - 00:04:49)

Heißt das, ich muss Angst haben, wenn ich im Büro jetzt einen Consultant sehe, dass eine Re-Org geplant ist?

Wolfi Gassler (00:04:49 - 00:04:56)

Also ich glaube, du kannst dir sicher sein, wenn du einen Consultant siehst, dass sich irgendwas verändern wird. Aber ich hoffe natürlich immer zum Positiven.

Andy Grunwald (00:04:56 - 00:05:19)

Ich selbst habe schon eine ganze Menge Re-Orgs mitgemacht. Ich habe jetzt nicht genau durchgezählt, aber lass es bestimmt sechs oder sieben sein. Und an zwei bis drei war ich auch zumindest in einem größeren Teilbereich mit beteiligt. Das bedeutet, ich habe die Re-Org nicht nur mit begleitet, sondern teilweise auch mit designed, zumindest in den Bereichen, die ich zu dem Zeitpunkt geleitet habe.

Wolfi Gassler (00:05:19 - 00:05:23)

Also du bist einer von den Bösen. Ich hab's schon verstanden.

Andy Grunwald (00:05:23 - 00:05:42)

War auch negativ betroffen teilweise, aber ich war auch einer der quote-on-quote Bösen oder vielleicht auch der Grund, warum eine Firma noch existiert. Denn, du sagtest gerade, Reorgs macht man in der Regel nicht zum Spaß, beziehungsweise die sollten nicht negativ sein, aber das machen wir gleich das Thema.

Wolfi Gassler (00:05:43 - 00:05:51)

Okay, also wenn du einer von den bösen Buben warst und bist, schön, jetzt habe ich den schwarzen Beta da, schwarzen Beta darf man nicht mehr sagen.

Andy Grunwald (00:05:51 - 00:05:56)

Bub, Abub, wir müssen auf Österreichisch sein, oder? Wenn du Abub warst, kannst du das mal auf Österreichisch sagen?

Wolfi Gassler (00:05:57 - 00:06:13)

Bei uns sagt man Abur, Tiroler Abur. Nein, was sagt man da, die schlechte Karte, die böse Karte? Die böse Karte, genau. Ihr habt ihr die böse Karte jetzt zugeschoben. Das ist perfekt. Aber meine Frage ist eigentlich, was ist denn eine Re-Org? Erklär das mal von der bösen Seite.

Andy Grunwald (00:06:13 - 00:07:40)

Ja, also Re-Org ist ja die Abkürzung für Reorganisation und auf gut Deutsch ist das eigentlich nur eine Umstrukturierung beziehungsweise eine Firmenumstrukturierung und sehr vereinfacht gesprochen werden Teams neu gewürfelt, vielleicht wird die Firma neu aufgestellt anhand einer anderen Richtung, neue Management Layer werden eingezogen oder rausgenommen oder ähnliches. Im Endeffekt ist das meines Erachtens nach ein garantiertes Event, was passieren wird für Firmen ab einer bestimmten Größe und ab einer bestimmten Lebensdauer. Denn so eine Umstrukturierung ist für ein Unternehmen immer die Möglichkeit, sich auf die wirtschaftlichen und gesellschaftlichen Bedingungen anzupassen. Nehmen wir mal Corona, nehmen wir mal Sanktionen von Ländern, nehmen wir mal logistik engpässe oder oder oder ja es passiert ja so viel außerhalb deiner kontrolle und ich glaube besonders in den letzten paar jahren ja wir hatten logistik logistisch diese suezkanal geschichte wo dieses schiff da quer stand wir hatten, Corona der ukraine krieg ist immer noch da dann ganzen sanktionen mit mit russland, dann wird teilweise technologie in amerika verboten oder ist gerade kurz vor dem verbot ja tiktok als letztes irgendwie ist gerade das beispiel dann haben wir jetzt diesen ganzen konflikt da hinten am gasa streifen also es passiert ja so dermaßen viel politisch aber auch gesellschaftlich.

Wolfi Gassler (00:07:40 - 00:08:17)

Gerade, Wobei man natürlich jetzt sagen muss, das sind alles Dinge, die man nicht beeinflussen kann oder die nicht so richtig planbar sind. Aber es sind natürlich auch einfach Events, die geplant sind, weil wenn du zum Beispiel wächst und du bist in irgendeinem Scale-up und die Firma wird einfach größer und größer, dann musst du umstrukturieren. Du kannst nicht einfach immer Leute dazuwerfen und reinwerfen und nichts machen. Also die Struktur muss sich in irgendeiner Form anpassen. Wenn dein Produkt skaliert, wenn du mehr User bekommst, mehr Kundinnen, die das Produkt verwenden. Da musst du bei der Technologie skalieren, aber natürlich auch bei dem Team skalieren. Also du musst überall skalieren und das bedeutet automatisch Veränderung in irgendeiner Form.

Andy Grunwald (00:08:17 - 00:09:14)

100 Prozent. Es kann auch ganz simpel sein, dass die Firma die Strategie jetzt ändert oder, Achtung, einen sogenannten Pivot hinlegt. Das bedeutet, ein altes Produkt irgendwie zu schließen, wegzuwerfen, weil es nicht mehr relevant ist, und ein neues Produkt herzustellen. Das bedeutet, die komplette Strategie ändert sich. Es kann auch komplett eigengetrieben sein. Auf jeden Fall ist eine solche Umstrukturierung immer, immer, immer ein sehr heftiges Event innerhalb der Organisation. Aber, Achtung, unpopular Opinion, notwendig. Denn meines Erachtens nach ist es eher schrecklich, sich an veralteten Strukturen festzuhalten, die einem Unternehmen nicht mehr helfen, die eigenen Ziele zu erreichen. Denn erneut an Propeller Opinion, diese Firma gibt uns allen ja in irgendeiner Art und Weise einen Arbeitsplatz. Und die Leute da oben wollen nur das Beste für diese Firma. Und diese Firma ist in der Regel profitorientiert. Das ist das Ziel, Geld zu machen. Und diese Leute da oben machen solche Re-Orgs natürlich dann auch nicht zum Spaß.

Wolfi Gassler (00:10:37 - 00:11:24)

Wir können das ja auch vergleichen mit der technischen Ebene, wie ich schon erwähnt habe, wir bauen ja gern mal was um, wir machen ein Refactoring, wir machen irgendwas auf einer neuen, coolen Technologie, auf der neuen Hipster-Datenbank, whatever it is. Und da sind wir eigentlich d'accord, dass man irgendwie mit der Zeit gehen muss. Man kann nicht ewig lang auf der extrem alten Technologie sitzen bleiben. Und ich glaube, das muss man einfach auf der Business-Seite auch sehen, auf der Struktur-Seite, dass man da einfach mit der Zeit gehen muss. Und wenn es neue Anforderungen gibt, sei es jetzt auf der technologischen Seite, aber eben auch auf der Struktur-Seite, dann muss man dementsprechend was ändern. Und üblicherweise wird das so gemacht, dass etwas besser wird, obwohl das natürlich nicht bei allen so ankommt, ist eh klar. Aber das kennen wir auch von der technologischen Seite, weil ich schlage irgendein tolles Framework vor und meine anderen drei Teamkollegen sind absolut dagegen.

Andy Grunwald (00:11:25 - 00:11:57)

Genauso wie es ein skill ist sich in einem neuen framework zurechtzufinden ist es auch ein skill sich innerhalb einer reorg zurechtzufinden denn eine reorganisation kann und triggert oft gewisse ängste weil es ist immer eine gewisse art von ungewissheit auch vielleicht wenn man gar nicht betroffen ist ja also ich meine, Der Klassiker ist, dass man eine neue Reporting Line, also einen neuen Manager bekommt, also eine neue Vorgesetzte, dass sich die Kollegen wechseln oder vielleicht sogar auch, dass das Produkt, wo du einfach Schweiß und Tränen, ich hoffe nicht Tränen, aber ihr wisst, was ich meine.

Wolfi Gassler (00:11:57 - 00:11:58)

Freudentränen.

Andy Grunwald (00:11:59 - 00:12:05)

Freudentränen, natürlich. Dass das Produkt, woran ihr das letzte Jahr gearbeitet habt, einfach vielleicht eingestellt wird.

Wolfi Gassler (00:12:06 - 00:12:36)

Das war übrigens mein Erlebnis, wie ich damals ein Team übernommen habe oder frisch eingestiegen bin auch in eine Firma, Team übernommen habe und dann war ich endlich soweit, habe alle gut gekannt, habe das Produkt gut gekannt, habe das Team in irgendeiner Form schätzen gelernt, wir haben ein gutes Verhältnis gehabt. Also wir waren genau an dem Punkt, wo es Eigentlich, wo man sofort aufnimmt, wo man wirklich Gas geben kann, bis man sich eingearbeitet hat. Und genau dann wurde mir vorgeschlagen oder wurde ich gebeten, Abteilung zu wechseln und ein anderes großes Team zu übernehmen.

Andy Grunwald (00:12:37 - 00:12:39)

Dir wurde eine starke Idee unterbreitet.

Wolfi Gassler (00:12:40 - 00:13:15)

Ich hätte mich auch wehren können, theoretisch, und ihr mir das auch lange überlegt natürlich, also ich war da schon eingebunden, aber das Gefühl ist natürlich einfach extrem beschissen auf gut Deutsch. Du bist jetzt endlich auf dem Punkt, wo du richtig los starten könntest, Gas geben kannst und plötzlich wird dir das wieder weggenommen. Also das ist schon eine... Extrem schlechte Situation, würde ich mal sagen. Im Nachhinein gesehen war es natürlich wieder super. Es haben sich da neue Dinge aufgetan. Es war ein super neues Team. Das Alte hat sich auch super weiterentwickelt. Also es war eigentlich das Beste, was mir passieren hat können. Aber natürlich in dem Moment ist es schon schwer, so eine Entscheidung zu treffen.

Andy Grunwald (00:13:15 - 00:14:06)

Aber auch deine Story zeigt ja, dass eine Re-Org eigentlich immer gut Intentions hat, weil ich meine, es soll die Firma ja weiterbringen, es soll vorhandene Probleme lösen, aber man darf auch nicht vergessen, Organisationen ist wie die Natur, sie ist halt nicht perfekt, imperfekt. Es gibt immer, es knirscht immer so. Es ist ähnlich wie bei einem Jobwechsel eine Reorganisation. Man tauscht immer nur ein Problemset mit einem anderen Problemset in der Hoffnung, dass man das neue Problemset besser ertragen kann bzw. nicht so groß ist. Aber es hat natürlich dann auch immer gewisse Risiken. Komplette Teams können verlangsamt werden oder vielleicht auch die Firma für eine gewisse Zeit. Leute wollen das vielleicht nicht. Veränderungen sind immer schwierig. Sprechen wir gleich noch ein bisschen drüber. Das bedeutet sie gehen oder Der Klassiker, es kann einfach sein, wenn man es falsch macht, dass man in sechs Monaten später dieselben Probleme hat wie vorher. Dann ist es natürlich ein sehr teurer Change gewesen, der sehr schlecht ist.

Wolfi Gassler (00:14:06 - 00:14:11)

Bei den ganzen Reorgs, wo du jetzt irgendwo involviert warst, was waren da die Hauptgründe?

Andy Grunwald (00:14:12 - 00:14:58)

Ja, ich hab das Gefühl, ich hab irgendwie gefühlt alle Gründe einmal durch. Eine RE-Org, und zwar ist das die letzte RE-Org, die ich mitgemacht hab, da war das so, dass sich das Business so entwickelt hat, dass ein Team kaum noch alleine agieren konnte, sondern dass die so viel Input und Entscheidungen von Stakeholders benötigt haben, dass natürlich ein unglaublicher Kommunikationswust entstanden ist. Und dann ist die RE-Org dahingehend gegangen, dass man sogenannte Domänen gebaut hat, wo dann alle Leute zu einem Thema, zu einem größeren Feature oder zu einer Business, zu einer Säule drin waren, dass diese Domäne komplett alles selbst entscheiden konnte. Diese Domäne hat dann ein Budget bekommen und konnte sich komplett frei entwickeln, Produktentscheidungen treffen und so weiter, um die Kommunikationswege halt runterzuholen.

Wolfi Gassler (00:14:58 - 00:15:04)

Ist das dann positiv angekommen? Weil es klingt ja jetzt eigentlich sehr positiv, ihr macht die Kommunikationswege kürzer, alles wird irgendwie besser.

Andy Grunwald (00:15:05 - 00:15:08)

Die REOG war so frisch, die ist jetzt gerade so drei Wochen alt.

Wolfi Gassler (00:15:09 - 00:15:13)

Die Kündigungen flattern dir erst ins Haus, wolltest du sagen.

Andy Grunwald (00:15:13 - 00:15:41)

Das Risiko besteht natürlich, klar. Aber ich hatte so was schon mal vorher, und das hat sich als positiv ausgezahlt. Aber ehrlicherweise muss man natürlich sagen, es ist natürlich kein AB-Test. Es sind alles Opportunitätskosten. Ich kann die andere Realität, hätten wir die RE-AUG nicht gemacht, nicht vorhersehen. Aber ich kannte immer das Warum und deswegen hat es in meinem Kopf Sinn gemacht. Oder zumindest wurde das Problemset, die Problemannahme, sehr ausführlich besprochen, dass es dann in meinem Kopf Sinn gemacht hat.

Wolfi Gassler (00:15:41 - 00:15:44)

Aber hat da irgendein Team dem dann auch verloren, also Verantwortung?

Andy Grunwald (00:15:45 - 00:15:59)

Ja, verloren, da sprichst du jetzt sehr negativ. Man kann auch sagen, diverse Teams haben sich weiter fokussiert. Das wäre dann das positive Wording. Also, ja, natürlich, es gab einen Shift in einer Arbeit. Und das hat dann natürlich manchen Individuen gefallen und manchen Leuten halt nicht.

Wolfi Gassler (00:16:00 - 00:16:31)

Weil meine Erfahrung ist, dass das eigentlich immer am schlechtesten wahrgenommen wird, wenn die Strukturen wachsen, vielleicht Personen dazukommen, zu viele Themen dann am Tisch sind bei den Teams und dann wird irgendwas aufgesplittet oder verschoben und dann werden Themen weggenommen. Und das Wegnehmen ist meistens halt irgendwie so ein Verlust und das kennt ja jeder, wenn einem was weggenommen wird, ist es immer schlimmer, als wenn man es gar nie gehabt hätte. Und das ist halt so ein persönlicher Angriff ganz oft, weil Leute haben halt da irgendwie mit Herzblut an einem Thema gearbeitet und plötzlich ist das Thema in einem anderen Team.

Andy Grunwald (00:16:32 - 00:17:09)

Aber ist das nicht eher Perspektive? Ich meine, du redest die ganze Zeit wegnehmen, wegnehmen, wegnehmen. Das ist immer schwierig, immer negativ. Du kannst auch ganz einfach sagen, hey, pass mal auf, du warst gerade Jack of all Trades, weil du auf fünf Hochzeiten getanzt hast in dem Team, so und jetzt wurde das Thema, AB-Test-Plattform für uns, so wichtig, das wird jetzt rausgemerged in ein eigenes Team, weil das mehr Priorität intern bekommen soll, und dann wirst du halt entweder, ich sag mal, Spezialist oder Spezialistin, weil du dann dich mit AB-Testing sehr viel auseinandersetzt, aber du bist dann halt kein Jack-of-all-Trades mehr. Deswegen bin ich mir gar nicht sicher, ob ich das immer als Wegnehmen sagen würde, sondern eher als Focus-Shift.

Wolfi Gassler (00:17:10 - 00:18:07)

Ja, da sieht man, dass du die ausführende Seite bist, die die RE-ORG plant. Und ich spreche jetzt von den Leuten, die betroffen sind. Du kannst es noch so oft wiederholen und gebetsmühlenartig wiederholen. Das ist ja eigentlich nur eine Verbesserung und eine Fokussierung und man kann sich jetzt konzentrieren. Man hat halt trotzdem dieses Gefühl von Wegnehmen. Ich hatte damals auch das Gefühl, das Team wurde mir in irgendeiner Form weggenommen fast, also das, was ich jetzt gerade aufgebaut habe. Im Nachhinein sieht man das natürlich eh anders und ich habe mich auch selber dazu entschlossen, das dann zu ändern. Aber im ersten Moment hat man halt einfach dieses Gefühl und ich glaube, Damit muss man auch lernen umzugehen, also sei es jetzt auf der Ebene von den Betroffenen, aber auch auf der ausführenden Seite, wenn du jetzt Manager bist oder weiter oben, dass du einfach damit rechnest, dass das bei Personen schlecht ankommt und halt einfach Zeit braucht. Das Gefühl wirst du nicht wegbekommen, nur weil du sagst, okay, ihr könnt euch jetzt fokussieren. Das Gefühl wird trotzdem da sein im ersten Moment.

Andy Grunwald (00:18:07 - 00:19:27)

Ja, das sagt der Pessimist, ne. Der Pessimist sagt auch, Andi, du hast Manager-Sprech drauf, ne. Man könnte auch sagen, bitte hört euch diese Episode weiter an, weil dann bekommt ihr nämlich auch den Skill des Optimisten und wie ihr eine Re-Org zu euren Gunsten nutzen könnt, beziehungsweise wie ihr da nicht immer traurig mit einer gezogenen Flappe rausgeht und die ganze Sache eher positiv seht, ja, und nicht so wie der Wolfgang hier. Aber es geht natürlich auch in die andere Richtung, denn Gründe für die Reorg kann natürlich auch ein sogenannter Merger sein. Und ein Merger wird eigentlich darum bezeichnet, dass Teams, die ich sag mal was ähnliches machen und Synergien nutzen, können halt zusammen gemerged werden. So ein klassisches Beispiel ist halt, Wenn du ein Infrastruktur-Team hast, die machen dann den ganzen Server und Cloud und allem drum und dran und du hast dann nebenbei vielleicht noch irgendwo ein Team, was in einer anderen Abteilung ist, was Release-Engineering genannt wird und sich oft um die CI, CD-Pipelines und sowas kümmert, das ist naturell so ein Klassiker, was dann irgendwann halt zusammengeschoben wird, weil die beiden Teams halt so viele Synergien haben. Du brauchst immer Infrastruktur, wenn du testen möchtest, aber irgendwie ist das auch Release Engineering gehört auch irgendwie zum Teil von Plattformen, damit du mehrere Engineering Teams enable kannst und so weiter. Also, das ist halt so ein Standardfall, der besonders in den letzten, ja, ich würde fast sagen Monaten des öfteren Mal passiert.

Wolfi Gassler (00:19:27 - 00:19:42)

Wie war da so die Resonanz? Weil meine Erfahrung ist ja, dass es eher leichter, würde ich mal sagen, angenommen wird, außer dass du natürlich auf der Kommunikationsseite meistens so die Teambildung hast, dass halt vielleicht am Anfang die zwei Teams in irgendeiner Form sich weniger gut verstehen.

Andy Grunwald (00:19:43 - 00:20:31)

Ja, ob die jeweiligen Menschen miteinander können, das ist ja immer das Problem. Wir arbeiten ja mit Menschen im Team. Das kann man nie wegreden. Das ist vielleicht eine Einzelfallbetrachtung. Aber ist halt auch irgendwie so eine Frage von, wie ist denn die Firmenkultur? Es gibt ja auch Firmen, da sagt jeder Software-Entwicklungsteam, okay, ich kümmere mich komplett um meinen eigenen Release-Flow. You build it, you run it. Doppelte Entwicklung oder halt, okay, du hast eine zentrale Teams, Plattform Teams und so weiter und nutzt die als, ich sag mal, Platform as a Service intern. Da wird ein solcher Change natürlich eher positiver angesehen, weil dann alles aus einer Hand, aus einer Sparte kommen kann. Ja, also ich habe beides schon erlebt, negativ sowie positiv, weil man verliert ja auch Freiheit, aber auf der anderen Seite kann man sich natürlich dann auf das Produkt fokussieren.

Wolfi Gassler (00:20:31 - 00:20:44)

Gehen wir mal zu einem wirklich negativen Punkt, meistens zumindest, ich glaube nicht, dass man da irgendwie was positives sehen kann als Team, wenn irgendwie ein Produkt eingestampft wird oder ein ganzes Team eingestampft wird, also Shutdown. Hast du sowas noch mal miterlebt?

Andy Grunwald (00:20:44 - 00:22:06)

Nein, habe ich noch nicht miterlebt. Ich war aber oder bin vor kurzem bei so etwas betroffen gewesen, wo gefragt wurde, ob ein Teil des Businesses eingestampft wird und die Frage wurde dann später mit Nein beantwortet und dann wurde Diese Business Unit nochmal auf eine Trial gelegt von 9 bis 12 Monaten, ob da doch noch irgendwie Geld mitgemacht werden kann. Also wurde die Frage verschoben, kurzum. Aber nein, wurde mir noch nicht. Aber ich meine, wir hatten das auch schon mal in einer Episode erwähnt gehabt. Google ist ja da König drin. Killedbygoogle.com. Ich weiß nicht wie viele Produkte Google inzwischen schon eingestampft hat. Aber einer der letzten Produkte, die uns mehr oder weniger betreffen, ist halt Google Podcasts. Wurde, glaub ich, seit April 2024 heruntergefahren. Zumindest in Deutschland. Und das ist natürlich dann schon eine Hausnummer, ne? Du steckst, wie gesagt, Schweiß und Tränen in ein solches Produkt und dann bye-bye, ist es natürlich so. Das kann natürlich dann auch negative Folgen für, ich sag mal, eine mögliche Beförderung und so weiter mit sich ziehen. Je nach Firmenkultur. der Outcome eines Produktes irgendwie für dich angerechnet wird, dass du daran gearbeitet hast oder der, ich sag mal Effort, weil du hast ja trotzdem, ich sag mal jetzt für Google Podcast alles gegeben und dass das Produkt dann eingestellt wird, lag dann mit hoher Wahrscheinlichkeit außerhalb deines Entscheidungsrahmens.

Wolfi Gassler (00:22:06 - 00:23:25)

Da gibt es einen tollen Blogartikel, glaube ich, von Ex-Googlern, die das sehr bekrittelt haben, dass sehr oft Produkte eingestampft werden und du natürlich dann nie die Chance hast, irgendwie befördert zu werden, weil du halt nie ein Produkt fertigstellst und nie erfolgreich sein kannst und das scheinbar extrem wichtig dort ist und in so einer Beförderungsmappe oder die Leistung, die du halt vorbringen musst und vorzeigen musst, dass die dir dann fehlt. Also das ist ein extremes Problem. Verlinken wir gerne in den Show Notes diesen Blogartikel. Was natürlich ein großer Vorteil ist, gegenüber einer klassischen Re-Org, bei so Shutdowns oder Einstampfen von Produkten, dass das meistens über längere Zeit passiert. Es ist seltener der Fall, würde ich mal sagen, zumindest was ich bisher miterlebt habe, dass es von heute auf morgen einfach so entschieden wird und es sich nicht so ein bisschen angebahnt hat, dass langsam die KPIs runtergehen, dass schon immer in Diskussion ist, wollen wir das Produkt weiterführen, ja oder nein. Also meistens kann man sich da schon so ein bisschen vorbereiten. Ich könnte mir natürlich vorstellen, dass so in großen Konzernstrukturen teilweise halt wirklich Projekte von heute auf morgen eingestampft werden, weil irgendwer gerade lustig ist und das jetzt entscheidet. Aber meine Erfahrung bisher war eigentlich immer so, dass sich das angebahnt hat und nicht so absolut unvorbereitet eingetroffen ist. Aber es ist natürlich trotzdem irgendwie ein persönliches Problem, vor allem wenn du das vielleicht mit aufgebaut hast, das Produkt, oder vielleicht sogar deine Idee war, ist das natürlich immer schlechter.

Andy Grunwald (00:23:25 - 00:25:09)

Nehmen wir mal das genaue Gegenteil von Produkte einstampfen. Reox können natürlich auch sein, es wird eine komplett neue Business Sparta aufgemacht. Ich glaube in letzter Zeit der AI und KI Hype. Ich glaube jede Firma schaut gerade irgendwie, wie können wir das nutzen und vielleicht wird da ein neues Team aufgemacht. Ein bisschen explorativ. Das ist natürlich dann eine positive Chance natürlich auch an neuen heißen Dingen mitarbeiten zu dürfen. Muss man natürlich auch gucken, hat natürlich auch ein gewisses Risiko, weil du bist natürlich nicht die Haupt-Revenue-Sparte deines Businesses, sondern die mögliche zukünftige Haupt-Revenue-Sparte, wer weiß das schon. Aber auch wenn neue Geschäftsmöglichkeiten halt mit großem Potenzial aufkommen, dann kann natürlich auch eine REOG sein. Oder eine andere Geschichte, wenn eine neue Sparte gerade wirklich Traktion bekommt. Das bedeutet, wenn ein neues Tool sich besser entwickelt als gedacht, dass da der sogenannte Headcount umgeschoben wird. Ein Fünf-Mann-Team hat dieses neue Produkt aus der Taufe gehoben und jetzt merken wir, da kommt sehr viel Geld rein, dann lass uns doch nicht nur fünf Leute draufsetzen, sondern 50. Dann kann das natürlich auch zu einer Reorg führen, dass von dem Legacy, was immer noch das Geld verdient, Legacy verdient das Geld, zum neuen Produkt alles umgeschoben wird. Sowas nennt man meistens Acceleration. Beispiele sind da glaube ich Instagram oder Threads oder vielleicht auch das Metaverse. Man weiß es nicht, was da bei Meta alles so abging, aber ich glaube, Threads wurde mit einem sehr kleinen Team entwickelt. Wer es nicht weiß, Threads ist der Competitor oder einer der Competitor von xTwitter aus dem Hause Facebook. Und das wurde in einem sehr kleinen Team entwickelt und mit hoher Wahrscheinlichkeit werden da jetzt deutlich mehr Leute dran arbeiten, weil das doch recht gut angenommen wurde.

Wolfi Gassler (00:25:09 - 00:26:46)

Auch da ist natürlich dann sehr oft eher positive Energie drin, weil einfach da extrem viel weitergeht und Wachstum und plötzlich ist das Produkt bekannt. Also könnte ich mir auch vorstellen, dass das eher positiv ist. Und darum möchte ich wieder zum negativen Thema wechseln. Irgendwie hat sich jetzt eingestellt, dass ich immer die negativen Beispiele bringe und du alles so in deiner grünen Wiese und auch deine rosa-rote Brille da siehst mit positiven Dingen. Aber was es natürlich schon sehr wohl auch gibt, ist so der Klassiker, zumindest so wie man es von unten teilweise sieht oder wie es halt unten ankommt. Da oben gibt es einen neuen C-Level, eine neue Person und die muss jetzt alles irgendwie umstricken. Das heißt, die macht irgendwelche neuen Teams, die strukturiert alles um, einfach um so die persönliche Handschrift mal aufzudrücken. Das kann jetzt natürlich irgendwas Positives sein unter Umständen. Aber oft wird es halt einfach empfunden, als da gibt es eine neue Person und die will halt unbedingt zeigen, wie toll sie ist. Ich kenne das Problem auch ganz klassisch bei Engineering-Managern, die steigen ein bei irgendeinem Team und wollen dann ihre Struktur auf dieses Team aufpressen. Funktioniert grundsätzlich nie, kann man gleich mal vorweg sagen. Aber Man muss auch dazu sagen, um wieder deine rosa-rote Brille aufzusetzen, Andi, meistens haben ja die Leute das Positive im Hinterkopf und die wollen ja auch was verändern. Die machen das ja meistens, weil sie sagen, okay, die Struktur ist besser, da kommt was Besseres raus. Also die haben ja auch nur das Beste im Sinn. Ob das unten dann natürlich ankommt bei den einzelnen Teams und bei den einzelnen Personen, ist nochmal eine andere Sache. Und ich glaube, das ist so 50-50 Chance, dass das sinnvoll sein kann oder auch nicht. Aber es gibt natürlich schon auch diese Personen, die sich da einfach beweisen wollen und dann irgendwas machen. Am besten in der ersten Woche schon, nachdem sie angefangen haben.

Andy Grunwald (00:26:47 - 00:27:32)

Das ist dann der berühmt-berüchtigte 90-Tagesplan, den meist so ein Ziellevel hat oder 180-Tagesplan. Aber du hast gerade schon gesagt, wie es dann unten, das hört sich an so scheiße, fällt immer nach unten. Wenn wir sagen unten, dann reden wir natürlich von den Leuten, die sich die Hände schmutzig machen, die die richtige Arbeit machen. Das bedeutet die sogenannten individuellen Contributor. Du hast gerade gesagt, wie kommt das Ganze denn unten an? Also wie wird eine Re-Org denn von unten beziehungsweise von außen gesehen? Und warum hat das eigentlich so immer einen negativen Touch? Und meine Erfahrung ist auf jeden Fall, es fühlt sich immer so an, als wenn das Management, Quote und Quote, die da oben, immer Boxen im Organigramm verschiebt. Och, diese Box, die passt aber eher nach unten links und diese nach rechts.

Wolfi Gassler (00:27:32 - 00:27:40)

Moment, Moment, Moment. Es fühlt sich so an. Du hast die Reoxia mitdesignt. Hast du nicht Boxen auf irgendeinem Diagramm herumgeschoben?

Andy Grunwald (00:27:40 - 00:27:41)

Ich hab neue Boxen erstellt.

Wolfi Gassler (00:27:42 - 00:27:47)

Eben, da haben wir es ja, also es wird nicht nur so wahrgenommen, es ist einfach so, es werden da Boxen herumgeschoben.

Andy Grunwald (00:27:48 - 00:28:50)

Was bedeutet natürlich auch, dass das Management die ganzen Detailprobleme eines Teams völlig außer Acht lässt. Das bedeutet, dass das Standardprozedere ist, dass nach einer Re-Org man Komponenten hat, Libraries, Microservices, Applikationen teilweise, die völlig ohne Ownership sind, weil das Management gar nicht wusste, dass diese existieren. Also, diese Details werden dann komplett auseinandergelassen. Und so entstehen natürlich immer diese toten Repositories. Das ist so der Klassiker von irgendwelchen Libraries, die überall in der Firma verwendet werden und auch noch gepullt werden bei einem Cargo-Install oder was weiß der, geil, oder NPME-Install. Und irgendwann merkt man, das funktioniert mit Note 16 gar nicht mehr. Oh, letzter Commit vor zwei Jahren. Und dann, hä, wer maintaint diese Library denn? Ja, weißt du noch, damals vor der Re-Org, da gab es da so ein Team, das wurde vom Wolfgang geleitet und die haben die Logging-Library für Javascript immer gemacht, aber seitdem kümmert sich da keiner mehr drum.

Wolfi Gassler (00:28:50 - 00:29:09)

Es ist ja sehr schön, wenn du sagst, die Boxen werden herumgeschoben und an alles, was du denkst, sind so die Applications und Libraries, die hinten irgendwo runterfallen und nicht mehr maintained werden. Es gibt ja auch noch die menschliche Seite, die da nicht betrachtet wird, aber Kleinigkeiten können wir einfach vergessen, die da bei den Boxen hinten runterfallen.

Andy Grunwald (00:29:09 - 00:30:08)

Ich sag ja nur, wie sieht das immer so von, wenn ich die menschliche Seite bin, wie sieht das dann für mich aus. Oft ist ja nicht die erste Kommunikation, warum machen wir das alles, sondern so sieht das neue Bild aus. Und dann denke ich mir, ach du meine Güte, die Logging Library vom Node.js, was ist denn da los. Und ein anderer Dauerbrenner ist auch immer, dass die Kommunikation der Re-Org nicht optimal ist. Ende vom Lied ist immer nur, jeder denkt sich, boah, was ne Shitshow. Das kann aus untergeschiedlichen Gründen sein, aber ab und zu auch, dass der Flurfunk einfach schneller ist als die offizielle Kommunikation. Und das ist natürlich dann immer schade, ja. Du hast dann Leute, die stecken da sehr viel Herzblut rein und Gedanken und allem drumherum, versuchen was Sinnhaftes zu machen und dann wird alles durch... Die Brigitte der Firma, also Brigitte nicht als Mensch, sondern als Zeitschrift in Deutschland, so ein Klatschblatt oder Bärbel oder weiß nicht, wie die Klatschblätter alle so heißen, wird dann alles so mit Halbwahrheiten oder vielleicht auch wie die Bild durch den Flur getragen. Finde ich dann immer schade.

Wolfi Gassler (00:30:08 - 00:30:14)

Ist immer super, dass du immer diese weiblichen Namen nimmst als Klatschblätter. Wo sind deine Fitnessstudio-Klatschblätter?

Andy Grunwald (00:30:14 - 00:30:18)

Du kannst ... Männliches Klatschblatt wär, glaub ich, ein Playboy oder so was. Oder eine Bild?

Wolfi Gassler (00:30:18 - 00:30:21)

Was ist mit dem ganzen Men's Health und diesen ganzen Dingen?

Andy Grunwald (00:30:22 - 00:30:25)

Uh, stimmt. Sorry, hab ich noch nie gelesen, aber ja, du hast recht.

Wolfi Gassler (00:30:25 - 00:30:48)

Siehst du mal. Da sieht man halt, wer öfters zum Friseur geht. Okay, aber kommen wir mal zurück zu dem Design von Reorgs. Jetzt hast du ja gesagt, okay, du hast schon öfters Reorgs designt und hast da Boxen herumgeschoben. Dann erklär mal, wie du da so vorgehst, damit man mal auch die Sicht von deiner Seite sieht, wenn du da Boxen malst. Wie gehst du da vor, wenn du irgendeine Reorg startest?

Andy Grunwald (00:30:48 - 00:32:16)

Harte Frage, aber berechtigte Frage. Im Endeffekt startet alles mit irgendwelchen Annahmen. Man versucht, Klarheit über die Probleme zu bekommen, die eine Organisation hat. Da ist es immer recht gut, so starte ich zumindest, mit eigentlichen Fragen. Warum hat Team X so viele Prioritäten pro Scrum-Zyklus? Und warum hat Team Y so viele unzusammenhängende Prioritäten, die nicht auf ein einziges Ziel ausgerichtet sind? Wo verbringen wir als Team, als Organisation, als Department eigentlich die meiste Zeit? Und wo entsteht der meiste Frust? Also könnte was vereinfacht werden? Oder wieso kommunizieren wir eigentlich jeden Tag mit dem Department, was unter einem anderen Ziellevel ist? Also sind wir von denen abhängig? Können wir überhaupt alles shippen, was wir wollen, ohne uns irgendwie Erlaubnis einzuholen? Also, das Ziel ist halt eher, so Klarheit darüber zu bekommen, welche Probleme man hat, und das meist so als Hypothesen zu formulieren. Weil ich würde da jetzt gar nicht so mit Lösungen direkt anfangen, denn mit diesen Hypothesen geht man halt erst mal los und fragt vielleicht andere Manager, seine Peers oder halt die einzigen Teammitglieder, natürlich dann ohne wirklich zu erwähnen, hey, ich denke mal in der RE-ORG nach. Also, das wird ein bisschen Angst schüren, sondern eher mal halt so Informationsbeschaffung. Hey was wie verbringst du denn deine zeit wo geht am meisten zeit um was macht am meisten frust das sollte das erstmal sind deine annahmen überhaupt wahr.

Wolfi Gassler (00:32:16 - 00:32:53)

Wobei ich glaube was was wichtig ist zu zu sagen und nicht dass es falsch rüberkommt also man überlegt sich jetzt nicht ich will ne reorg machen was könnte ich ändern, Sondern meistens habe ich ja die Pain Points und den Schmerz, den ich irgendwo erfahre, meine Teams werden langsamer, es ist zu viel Kommunikation. Und dann überlege ich mir, okay, könnte eine Re-Org helfen? Also es ist ja nicht so, dass einfach die Re-Org auf dem Plan steht und ich möchte jetzt mal eine Re-Org machen, weil die letzte ist schon wieder zwei Jahre her. Was könnten wir denn da verbessern oder wo könnten wir denn Hypothesen finden? Also es ist natürlich schon umgekehrt üblicherweise. Also man macht das ja nicht ohne Grund. Also man hat eben bei einer Firma neu angefangen und will halt unbedingt da seine Handschrift auftragen.

Andy Grunwald (00:32:53 - 00:35:11)

100 Prozent, Entschuldigung, wenn das falsch rübergekommen ist, aber einer der Aufgaben eines Managers oder einer Managerin, sei es ein Line-Manager oder ein Director, also Manager von Managern oder Ähnliches, ist es natürlich auch mal zwei Schritte zurückzugehen und einfach mal zu hinterfragen, was tun wir hier eigentlich? Wie sieht eigentlich die Wertschöpfungskette aus? Und dabei kommen natürlich dann auch solche Fragen, wo verschwenden wir Zeit, wo kann etwas simplifiziert werden? und auf jeden fall hat man so ein paar hypothesen und die versuche man zu verifizieren und danach bin ich immer ein riesen freund von wir schreiben das ganze mal auf wolfgang lacht immer so wenn ich was was schreiben sage aber ich denke man sollte sich den one oder two pager quote unquote also eine oder zwei seiten, mal aufschreiben, so nach dem Motto, was ist der Current State? Also wo sind wir gerade? Welche Probleme haben wir jetzt gerade? Wie zum Beispiel Team X ist irgendwie von einer Web App und zehn Backends in den letzten drei Monaten angewachsen. Die supporten jetzt drei Web Apps und 30 Backends und 100 Data Pipelines. Vielleicht ist das ein Fokus Problem. Also einfach mal, okay, was läuft denn gerade falsch? Dann bin ich immer ein Freund davon, diese Problematiken aus dem Current State, ich sag mal, in so Themengebiete zu packen, weil das ist halt Informationsstruktur. Damit man das einfach relativ leicht versteht, kann natürlich sein, dass dann Team X, was dann jetzt diese 30 Backends macht, irgendwie die Anzahl der Anfragen von ihren Stakeholder nicht mehr bewältigen kann, so was halt. oder dass ein Team irgendwie keine klare Mission und keine Richtung hat. Das wären dann zum Beispiel jetzt hier so Themengebiete, dass ich die Probleme halt einfach mal so kategorisiere. Und dann als dritten Chapter halt erkläre, warum ein neuer Approach gegebenenfalls hilfreich wäre. Da stelle ich mir oft die Frage, was passiert, wenn wir mit dieser aktuellen Struktur jetzt noch zwei Jahre weitermachen, zwei Jahre weiter wachsen, was passiert dann? Und dann weiß man eigentlich, okay, man hat das aufgeschrieben, das kann man dann auch so teilen. Das Beste am Geschriebenen ist, das vergessen die meisten, wenn du ein Dokument hast und du teilst das Dokument, teilst du eins zu eins, dasselbe mit allen. Wenn du nämlich mit jedem Einzelnen sprichst, hast du nämlich unterschiedliche Kommunikationen, du vergisst immer was, du addest immer was. Deswegen schreiben bringt Klarheit, Hypothesen formulieren, aufschreiben.

Wolfi Gassler (00:35:11 - 00:35:19)

Okay, du hast jetzt alles aufgeschrieben, die Probleme identifiziert im Idealfall, das heißt, üblicherweise kommt danach die Problemlösung, schätze ich mal, oder?

Andy Grunwald (00:35:19 - 00:35:24)

Wenn es eine Lösung gibt, ne? Also man denkt drüber nach, ja, was sind denn die Optionen?

Wolfi Gassler (00:35:24 - 00:35:27)

Also könnte auch eine Lösung sein, ich mache keine Reorg.

Andy Grunwald (00:35:27 - 00:35:28)

Ja, natürlich.

Wolfi Gassler (00:35:28 - 00:35:30)

Oder das Result könnte das sein.

Andy Grunwald (00:35:30 - 00:36:07)

Es könnte auch sein, dass das unter den gegebenen Umständen, Achtung, das ist nämlich immer der Punkt, man hat ja immer nur einen gegebenen Rahmen, unter dem man agieren kann, das ist die beste Lösung, zu der ich komme, weil ich alle Trade-Offs mit einbezogen habe. Genau, und wenn man jetzt halt mal guckt, okay, was habe ich denn für Optionen, dann geht es halt in den ganzen Bereich, okay, wie kann ich denn meine Teams strukturieren, ja, wie designe ich denn mein Department oder meine Teams. Das bedeutet, wie arbeiten denn die einzelnen Teams in meiner Unternehmensstruktur zusammen. Und da stellt sich auch die Frage, macht es denn eigentlich Sinn, vielleicht auf ein bewährtes Modell zu gehen, ja, also kann ich ein Modell von anderen kopieren?

Wolfi Gassler (00:36:08 - 00:36:18)

Eindeutig Spotify-Model. Es ist immer die Antwort der Spotify-Model. Agile, Squads, Tribes, Scrum, Guilds. Spotify löst alles.

Andy Grunwald (00:36:18 - 00:36:27)

Ja, ich glaube, das war der Witz der letzten Dekade, weil ich glaube, als das released wurde, hat irgendjemand von Spotify selbst noch mal gesagt, dass das bei Spotify selbst gar nicht mehr aktiv ist.

Wolfi Gassler (00:36:27 - 00:36:45)

Es war, glaube ich, viel, viel, viel später, dass es nie eigentlich richtig implementiert wurde bei Spotify in der Härte, in der es vorgeschlagen wurde. Aber man muss schon sagen, es war ein Modell, was die Industrie schon geändert hat. Und ich glaube, dass da sehr viele Teile schon übernommen wurden und dass die auch sehr gut funktionieren in der Realität.

Andy Grunwald (00:36:46 - 00:37:11)

Klar, hundertprozentig. Ja, es gibt aber auch andere Modelle, die irgendwie durchs Dorf getrieben wurden, wie zum Beispiel das Amazon-To-Pizza-Modell. Ja, ein Team sollte nur so groß sein, dass das Team von zwei Pizzen satt wird. Oder Basecamp schwört fest darauf, dass innerhalb eines Teams nur ein Programmierer, ein Designer oder maximal zwei Programmiererinnen und ein Designer da sind, weil sie denken ... Also.

Wolfi Gassler (00:37:11 - 00:37:16)

An einem Feature arbeiten. Jetzt weniger klassisch Teams, aber Feature-Teams.

Andy Grunwald (00:37:16 - 00:37:39)

Genau, die sagen halt, okay, für die meisten Dinge ist das die ideale Größe. Und darüber hinaus nimmt halt die Komplexität irgendwie exponentiell zu. Das ist halt deren Glaubenssatz. Auf der anderen Seite muss man natürlich auch sagen, wenn du über Teamdesign sprichst und auch im Tech-Bereich, dann gibt's natürlich auch zwei Gesetze, wenn man so möchte, die man nicht außer Augen ... außer Augen ... Wie heißt das?

Wolfi Gassler (00:37:39 - 00:37:43)

Außer Augen lassen, ja. Aus den Augen verlieren.

Andy Grunwald (00:37:43 - 00:38:15)

Da gibt es natürlich zwei Gesetze, die man nicht aus den Augen verlieren darf. Das eine Modell ist natürlich die sogenannte Conway's Law. Das bedeutet, dass deine Infrastruktur eigentlich so aussieht wie dein Organigramm, deine Microservice-Struktur oder deine Applikationsstruktur. Und die andere Geschichte ist die sogenannte Brooks Law. Die hat was mit den Lines of Communication zu tun. Das bedeutet, dass du, wenn du drei Personen in einem Team hast, dass du drei Kommunikationsverbindungen hast. Wenn du sieben Personen hast, dass du 21 Kommunikationsverbindungen hast.

Wolfi Gassler (00:38:15 - 00:38:16)

Warum hast du 21? Erklär mal.

Andy Grunwald (00:38:17 - 00:38:20)

Naja, also weil ja jede Person mit jeder Person kommunizieren kann.

Wolfi Gassler (00:38:20 - 00:38:23)

Also du meinst jetzt im Team die Kommunikationslinien?

Andy Grunwald (00:38:23 - 00:38:24)

Ganz genau, ja.

Wolfi Gassler (00:38:24 - 00:38:31)

Und da gibt es eine klassische Formel, Andi, wenn man die hat, wie viele Connections gibt es zwischen einer Gruppe, in einer Gruppe?

Andy Grunwald (00:38:31 - 00:38:42)

Wenn du mir den Algorithmus gibst, kann ich dir sagen, welche Komplexität er hat, aber im Algorithmen-Design war ich schon immer schlecht, sonst hätte ich wahrscheinlich schon sehr viel Geld gehabt mit der Neuimplementierung von ganz vielen Algorithmen.

Wolfi Gassler (00:38:43 - 00:38:49)

Also wenn ich jetzt nicht falsch liege, ist es n mal n minus 1 halbe. Was ist denn die Komplexität, Andi?

Andy Grunwald (00:38:49 - 00:38:51)

Irgendwas Logo-Rhythmisches.

Wolfi Gassler (00:38:51 - 00:38:57)

Ich weiß es leider nicht. Okay, es sind auf jeden Fall viele Verbindungen.

Andy Grunwald (00:38:57 - 00:39:15)

Und das geht halt relativ schnell nach oben. Bei elf Personen in einem Team hat man 55 Verbindungen. Und das ist ja genau dieser Punkt, den Basecamp ja auch ein bisschen anspricht. und mit dem Team of three. Auf jeden Fall hat das eine direkte Auswirkung auf die Komplexität von Kommunikation innerhalb eines Teams.

Wolfi Gassler (00:39:15 - 00:40:29)

Wobei meine Erfahrung auch da jetzt wieder ist bei solchen Umstrukturierungen, wo es wirklich darum geht, wie arbeitet man zusammen, dass die eigentlich auch so langsamer eingeführt werden und auch sehr transparent und offen eingeführt werden. Also das waren selten solche klassischen Reorgs, wo irgendwo ganz oben an oberster Ebene irgendwelche Boxen verschoben wurden und Boxen rausgestrichen wurden und dann wurde von heute auf morgen umgestellt, sondern das war schon auch eher ein Prozess. Wir wollen agiler werden, wir wollen mal ausprobieren in irgendeiner kleinen Struktur, probieren wir jetzt mal irgendwie das Spotify Model aus, machen da eine Gilde. Das hat sich also immer so ein bisschen Eingeschlichen, würde ich fast sagen, oder einfach transparent ist es eingeführt worden und damit auch positiver normalerweise aufgefasst wurden, Feedback-Cycles. Also das war weniger eine ganz harte Re-Org, die halt passiert, wenn man oben wirklich Boxen verschiebt und Boxen rastreicht und ganze Teams rauskickt und so weiter. Was dann natürlich sehr viel härter aufschlägt dann bei den Teams, als jetzt irgendwie, wir werden agiler und wir haben jetzt da einen Agile-Coach mehr und ändern da vielleicht auf Scrum oder solche Dinge. Wenn wir mal jetzt weggehen von Spotify und Co. Auf was achtest du denn sonst noch oder was hast du sonst für Möglichkeiten jetzt, wenn es um Teamstrukturen geht? Auf was legst du da Augenmerk?

Andy Grunwald (00:40:30 - 00:42:02)

Ich hoffe nicht nur ich alleine, sondern auch ganz viele andere Leute. Aber im Endeffekt gibt es halt echt viel zu bedenken. Neben diesen zwei Gesetzen, die wir gerade hatten, kann man auch Gedanken gegen Gefühle führen, wie zum Beispiel, okay, mache ich denn ein funktionales Modell, also ich habe mal ein iOS-Team, ein Android-Team, ein Web-Team oder strukturiere ich die nach einem Domänenmodell, so nach dem Motto bei einem E-Commerce-Shop wäre es dann ein Suchteam, ein Checkout-Team, also interdisziplinäre Teams. Geht natürlich dann, hat alles Vor- und Nachteile. Ja, auf der einen Seite sind interdisziplinäre Teams schon autonomer. Auf der anderen Seite ist es natürlich schwierig, dass du, wenn du eine Programmiererin, einen Designer, einen Produktmanager drin hast, dann verliert der Designer natürlich Connection zu seinem Design-Core-Team. Ja, und er kann sich nicht weiterentwickeln oder bin nicht so schnell in den Design-Skills. Also es hat alles Vor- und Nachteile. Ein anderer Gedankengang wäre zum Beispiel, wie interagiert das Team denn überhaupt mit anderen Teilen dieser Firma, ist das eher so im Consultant Bereich, du hast ja in vielen größeren Firmen auch Consultant Teams, oder sind das Service Provider, wie zum Beispiel die Personalabteilung wäre ein Service Provider, wenn man so möchte eigentlich. Oder ist das wirklich ein Team, was alles alleine entscheiden kann? Wie gesagt, so ein Checkout-Team kümmert sich dann nur um den Checkout-Flow. Das wären dann zum Beispiel solche Geschichten. Die dritte Geschichte, die du dir überlegen musst, was bedeutet eigentlich Erfolg für ein solches neues Team? Was sind Erfolgsmetriken? Wie steuert dieses Team eigentlich zur Strategie der Firma bei?

Wolfi Gassler (00:42:02 - 00:42:21)

Dazu musst du natürlich auch wissen, was du eigentlich für ein Problem hast und was du erreichen willst, um überhaupt so Metriken aufzusetzen, beziehungsweise im Idealfall hast du davor vielleicht schon Metriken gehabt, wie schnell wird irgendwas umgesetzt, was hast du für Cycle Times, um das dann überhaupt im Nachhinein zu prüfen, hast du da eine Optimierung eigentlich überhaupt durchgeführt und weniger ein Bauchgefühl?

Andy Grunwald (00:42:22 - 00:42:41)

Klar, das ist sozusagen die Gegenprüfung. Wenn deine Gedankengänge richtig waren und wenn deine originalen Herausforderungen durch das neue Teamdesign gelöst wurden, dann solltest du auch in der Lage sein herauszufinden, wie ein einzelnes Team denn zur Top-Level-Strategie kontributet. Und wenn das nicht gegeben ist, bitte gehen Sie zurück an den Start.

Wolfi Gassler (00:42:42 - 00:43:32)

Da ist es natürlich dann auch wichtig zu sagen, das was du jetzt alles erwähnt hast, das ist natürlich wirklich die positive Seite, der Happy Path, eine RE-AUG ist entstanden, weil es Kommunikationsprobleme gibt, weil es zu langsam ist, du willst was verbessern. Du hast natürlich ganz viel andere Gründe, ich will jetzt gar nicht die ganze politische Richtung und so weiter einschlagen, aber das kann natürlich auch sein, dass da RE-AUGs entstehen, weil Du halt irgendwelche Personen an gewissen Positionen haben willst, irgendwas umshiftest, irgendwas umstrukturierst, was überhaupt gar nichts damit zu tun hat, die Kommunikation zu verbessern. Also das haben wir jetzt mal bewusst ausgeklammert, diese ganzen Gründe, sondern wir gehen davon aus, dass wir wirklich ein Problem lösen wollen und einen Pain Point haben und die Kommunikation verbessern, Delivery beschleunigen oder was es auch immer ist, Produktivität erhöhen. Weil sonst kannst du dir die Metriken natürlich sparen, weil die politische Metrik gibt es offiziell zumindest nicht.

Andy Grunwald (00:43:33 - 00:43:40)

Genau, dann solltest du aber auch keinen Re-Org machen, weil dann ist es einfach nur persönliches Ego-Kram und naja, gut.

Wolfi Gassler (00:43:40 - 00:43:46)

Aber gibt's in der Realität auch, muss man ganz klar dazu sagen, aber bleiben wir mal auf der positiven Seite.

Andy Grunwald (00:43:46 - 00:43:47)

Nicht in unserer Welt, Wolfgang.

Wolfi Gassler (00:43:47 - 00:43:49)

Ja, natürlich, wir sind ja positiv.

Andy Grunwald (00:43:50 - 00:44:54)

Ja, und die letzte Geschichte ist natürlich dann, okay, die Entscheidung, welches Modell nehme ich, und dann wirklich die Ausführung in der ganzen Geschichte. Und da ist es natürlich unglaublich wichtig, dass man einen klaren Kommunikationsplan hat, Milestones definiert, ab wann gilt diese neue Organisation, dann vielleicht einen Plan vorlegt, um von der alten Organisation in die neue zu gehen, eine sogenannte Transition Period, weil du hast natürlich Altlasten wie immer noch. Legacy verdient das Geld. Ein Kommunikationsplan macht natürlich auch Sinn, wie, wann, wo kommunizierst du das. Rufst du die Firma in einem All-Hands-Meeting zusammen, bietest du danach noch eine Question-Answer-Session an. Und wichtig auch bei dem Kommunikationsplan ist natürlich die Wortwahl, dass die einheitlich ist. auch wirklich über Management-Ebenen hinaus, dass halt auch Engineering-Manager wirklich, ich sag mal, dieselbe Wortwahl nutzen wie das Top-Level-Management und natürlich hoffentlich vorher gebrieft wurden und ganz klar das Warum erklären können. Weil wenn nämlich der Sub-Manager die ganze Sache nicht mitträgt, offengesprochen, dann ist Hopfen und Malz verloren.

Wolfi Gassler (00:44:54 - 00:47:06)

Und ich glaub, das ist eigentlich das Schwierigste, weil das, was du jetzt davor besprochen hast, also dass man sich irgendwie mal überlegt, was hat man für ein Problem, wie will man dieses Problem lösen, was für Optionen habe ich, und dann so den Execution-Plan aufstelle. Ab da bist du alleine in deinem Kämmerchen oder in deiner kleinen Gruppe, die entscheidet, was machen wir. Und dann gehst du nach außen. Also diese Execution, diese Ausführung, da musst du dann mehr Leute mit einbeziehen. alle unteres Management, die ganzen Teams, alle, was in irgendeiner Form involviert sind. Und ab da wird es dann schwierig. Also das ist, glaube ich, ein Knackpunkt, weil davor kannst du in einer kleinen Gruppe diskutieren. Und ab dann ist es aber schwierig, weil wenn du dann eine Re-Org hast und da sind alleine dann irgendwie, keine Ahnung, 30 Manager involviert irgendwie drunter. Wie schaffst du es, diese 30 Manager so hinzukriegen, dass die alle einverstanden sind? dass die deine einheitliche Kommunikation wählen, die gleichen Wörter und so, was du jetzt alles erwähnt hast. Wie schaffst du das? Und das ist dann schwierig, weil das kannst du nicht mit, ich habe da einen One-Pager und sende das zu allen aus und dann wird das schon funktionieren, weil wenn man das macht, dann läuft das sicher schief und dann hast du ein großes Problem. Also ich glaube, die Execution ist eigentlich dieser Bereich, wo man ganz viel Zeit investieren sollte und Das vergisst man dann, glaube ich, oft, weil man sich eben mit den Boxen oben beschäftigt und dann den unteren Teil, die Ausführung vergisst. Und da gibt es ja dieses klassische Beispiel, ich glaube von BMW oder Audi, wo es irgendwie darum geht, wenn dort Restrukturierungen passieren und eine Restrukturierung irgendwie, keine Ahnung, zum Beispiel in einem Werk in Brasilien jetzt ankommt und die Leute wirklich betroffen sind mit dieser Restrukturierung, Dann wurde die Restrukturierung ein Jahr im Vorhinein in München oder wo sind eure Autobauer? Vergiss ich immer. geplant. Also da ist ein Ja dazwischen, bis das unten ankommt. Und ich glaube, das unterschätzt mal, wie lange das eigentlich braucht, bis das wirklich durch alle Ebenen nach unten geht und bei den Teams ankommt. Und oben eine Box ist schnell verschoben, aber bis unten die Box dann wirklich in der Realität verschoben ist und positiv dann wahrgenommen wird und wieder funktioniert, das dauert extrem lang. Und da ist eigentlich das ganze Konfliktpotenzial und die negative Energie, die dann frei wird bei den Personen in den Teams.

Andy Grunwald (00:47:06 - 00:47:25)

Also ich glaube schon bei Großkonzernen dauert das locker mal ein Jahr und wenn du einen Re-Org weltweit machst, du hast gerade irgendwas von München und Brasilien erzählt, klar logisch. Auf der anderen Seite, das andere Extrem sind halt Start-Ups oder Scale-Ups, da ist eher so die Tendenz zwischen hart und schnell, dann tut es einmal richtig weh in einem sehr kurzen Zeitraum.

Wolfi Gassler (00:47:26 - 00:48:05)

Das stimmt, aber du hast das gleiche Problem, weil du kannst die Box nicht oben verschieben. Klar sind die Strukturen kürzer, aber es gibt ja auch diese Kurve, diese Change-Kurve, die Personen durchgehen in einer Änderung oder in einem Schock oder in einer negativen Erfahrung und das kannst du nicht beschleunigen. Also das braucht es. Du kannst nicht sagen, wir sind ein Startup, da müssen alle schneller reagieren. Vielleicht hast du im Idealfall Leute, die schneller reagieren können. Aber du hast trotzdem noch irgendwo Menschen, die sich daran gewöhnen müssen. Und das ist bei uns allen so. Du kannst dich nicht von heute auf morgen auf irgendwas umgewöhnen. Also das braucht eine gewisse Zeit, bis du das verarbeitest. Und das wird halt oft vergessen auf der Boxenverschiebungsebene.

Andy Grunwald (00:48:05 - 00:48:36)

Wir reden hier gerade von zwei verschiedenen Dingen. Die eine Geschichte ist die Ausführung der RE-ORG, die bei Großkonzernen naturell einfach länger dauert. Und die andere Geschichte ist, wann sich Menschen durch eine Änderung vom Schock, durch die Akzeptanz, Erkenntnis, Integration und Co., die klassische Change-Kurve, gekämpft haben. das sind für mich zwei verschiedene dinge denn in dem startup scale up ist das timing und die milestones und so weiter deutlich enger getaktet als jetzt wenn bmw eine weltweite restrukturierung macht.

Wolfi Gassler (00:48:37 - 00:48:53)

Ja, aber du musst es mit einberechnen und das braucht einfach, bis die Personen, die Teams sich daran gewöhnt haben und umso mehr Ebenen du dazwischen hast, umso länger dauert es. Und bis dorthin sind diese Teams nicht einsatzfähig und werden auch nicht produktiv sein. Das ist der wichtige Punkt.

Andy Grunwald (00:48:53 - 00:48:55)

Ah, da würde ich nicht mitgehen, bin ich ganz ehrlich.

Wolfi Gassler (00:48:55 - 00:48:59)

Ja, aber sie sind nicht produktiv. Sie sind nicht auf voller Leistung.

Andy Grunwald (00:49:00 - 00:49:13)

Und also ich denke ich denke ich denke sie sind produktiv ich bin bei dir sie sind nicht auf voller leistung und ja die die leistung wird zuerst zerstört und danach wieder aufgebaut das ist richtig, hatten wir schon am anfang gesagt ein reorg ist ein disruptives event.

Wolfi Gassler (00:49:14 - 00:50:10)

Ja aber eben wenn du das nicht auffängst dann kann sein dass deine teams, noch viel länger nicht produktiv werden, weil dann gibt's Personen, die dagegen arbeiten, die nicht gut aufgefangen wurden, die womöglich dann wirklich Gruppen bilden, die komplett sich dagegen wehren gegen diese Änderung. Und das ist dasselbe, wie was ich am Anfang erwähnt habe als Beispiel, irgendein neuer Engineering Manager geht in ein Team und will den eigenen Stempel aufdrücken. Alles, was du erreichst, ist, dass alle im Team gegen dich sind. Und das wird nicht funktionieren. Also das wird dann noch viel länger brauchen. Das heißt, du musst eben diese Execution sehr gut abfedern, damit du möglichst schnell wieder auf einem Pfad bist, wo du produktiv arbeiten kannst und der Großteil zumindestens zufrieden ist. Alle kannst du eh nicht glücklich machen, aber der Großteil. Und dieses Auffangen wird ganz oft vergessen. Und das muss, glaube ich, besser geplant werden, das Einbeziehen der ganzen Manager, der untere Management-Ebene, damit es dann eben sinnvoll implementiert wird.

Andy Grunwald (00:50:11 - 00:50:35)

Hundertprozentig, klar. Du hast immer die Herausforderung, wenn Submanager nicht mitziehen oder nicht daran glauben, ist Hopf und Malz verloren. Da kannst du die besten Intentionen von oben haben und alles so akribisch vorbereitet haben. Wenn unten jemand querschießt, also unten in dem Organigramm, dann machst du dann einfach gar nichts.

Wolfi Gassler (00:50:35 - 00:51:33)

Und wenn natürlich deine Teams an sich glücklicher sind und auch das Vertrauen haben an den Manager, an die Managerinnen oder an das Upper Management, was es dann auch immer ist, umso besser da natürlich deine Strukturen sind und umso gefestigter die sind, Umso leichter ist dann natürlich auch die Umstellung, weil wenn du jetzt als Manager, als Andi, jetzt großes Vertrauen in deinem Team genießt und dann vielleicht sagst, okay, wir haben da jetzt diese Umstellung, wir wissen nicht, was passieren wird, aber wir werden eine Lösung finden und ich persönlich bin dran und wir setzen uns da jetzt alle gemeinsam dran, hat das natürlich ein anderes Gewicht, als wenn da eh schon die ganze negative Energie in den Teams drin ist und dann kommt nochmal eine Umstrukturierung oben drauf. Man kann auch vorarbeiten und umso besser das natürlich zu, ich weiß mal, jetzt sollte man ja aktuell nicht zu Friedens- und Kriegszeiten die Begriffe zu nennen, aber ich verwende es mal trotzdem, umso besser du dich in den Friedenszeiten vorsorgst, umso leichter ist dann die Umstrukturierung, wenn es da mal hart hergeht.

Andy Grunwald (00:51:34 - 00:51:40)

Also bedeutet das, du erstellst nur Vertrauen zu deinen Teammitgliedern und zu deinen Managern, weil du weißt, okay, die nächste Reihe auch kommt bestimmt.

Wolfi Gassler (00:51:40 - 00:51:56)

Ja, grundsätzlich jetzt nicht nur die Re-Org, aber schwierigere Zeiten. Und ich glaube, du kannst dir sehr wohl vorsorgen. Und umso besser du vorsorgst, umso eher kommst du dann wieder durch die schwierigeren Zeiten. Und es ist halt immer ein Auf und Ab. Es muss ja keine Re-Org sein. Kann ja auch was anderes sein. Aber Vertrauen ist immer gut.

Andy Grunwald (00:51:56 - 00:52:42)

Ich glaube zum thema vorsorge rennst du bei den deutschen hier offene türen ein weil wir sind alle glaube ich hoffen oder im durchschnitt sind wir alle hoffnungslos überversichert von daher aber jetzt haben wir natürlich die ganze zeit diesen diesen prozess wie designt man eine reorg was passiert da eigentlich. Durchgesprochen und das ist natürlich so wir sind uns bewusst dass uns mehr software engineers und entwicklerinnen zuhören und wir sind uns auch bewusst, dass wahrscheinlich nicht alle eine reorg design werden dennoch, war das ziel der ganzen thematik hier eigentlich nur mal aufzuzeigen dass das keine nachmittagsaktion oder ein feierabendbier ist sowas durchzuziehen dass das auch aus management sicht eine sehr risikobehaftete.

Wolfi Gassler (00:52:42 - 00:52:48)

Aktion ist auch wenn es manchmal so aussieht als wäre es eine aktion die man nur bei einem bier geplant gewesen.

Andy Grunwald (00:52:48 - 00:52:51)

Ist genau aber vielleicht passiert es auch.

Wolfi Gassler (00:52:51 - 00:53:47)

Muss man auch dazu sagen also gerade In Startups habe ich die Erfahrung gemacht, in wirklich kleinen Startups, das sind ja oft Gründer und Gründerinnen und die haben keine Erfahrung, die haben noch keine Reorgs durchgemacht und plötzlich sind die irgendwie auf 30 Leute gewachsen oder 20 und sollen eine Reorg machen. Das ist ja ganz klassisch, du hast eine kleine Startup oder lass es 10 Leute sein. und du musst jetzt eine neue Ebene einziehen, du musst plötzlich Engineering Manager einführen, du machst eine Re-Org in deinem 10-Unternehmen-Team und hast keine Ahnung, wie das eigentlich läuft, hast das noch nie womöglich miterlebt, sollst das planen und bist eigentlich vielleicht einfach ein Business-Mensch oder Entwicklerin und musst jetzt plötzlich da in deinem Dev-Team eine Re-Org durchplanen. Wie sollst du das auch schaffen oder wissen, wie du es machst? Also man muss schon auch sagen, die Leute, die einfach schon länger in der Industrie unterwegs sind, sind meistens auch Erfahrene und können das vielleicht dann auch ein bisschen besser strukturiert machen. Also da sich Hilfe zu holen ist auch immer eigentlich eine gute Idee.

Andy Grunwald (00:53:47 - 00:54:07)

Also das war jetzt ein Prime-Example, womit ich hier jeden Tag zu kämpfen habe. Ich habe versucht, allen Hörerinnen und Hörern Mut zu machen und dass da echt viel Arbeit hinter steckt und dass sich da echt Leute Gedanken machen. Und dann kommt der Wolfgang einfach um die Ecke. Ja, es gibt ja auch Startups, die machen das bei einem Feierabendbier, ne? Also die haben noch keine Ahnung von dem, was sie da tun und die sollten mich als Consultant immer lieber hier anstellen, damit ich den nochmal erkläre.

Wolfi Gassler (00:54:08 - 00:54:12)

Also das finde ich natürlich sowieso sehr gut.

Andy Grunwald (00:54:12 - 00:54:43)

In der regel steckt da eine ganze menge arbeit hin und wir haben das alles jetzt mal hier so ausgebreitet damit ihr mal ein bisschen so ich sag mal behind the scenes einblick bekommt und ich weiß es kann immer noch shit show sein bei der ausführung verstehe ich alles und deswegen, wechseln wir mal jetzt ganz kurz noch in die engineering sicht mit der frage wie kann ich denn eigentlich die reorg supporten oder wie kann ich denn sicherstellen dass ich auf der in anführungszeichen richtigen seite der reorg lande denn so eine reorg moment gibt es.

Wolfi Gassler (00:54:43 - 00:54:45)

Eine falsche seite immer es gibt immer.

Andy Grunwald (00:54:45 - 00:54:46)

Eine richtige und eine falsche seite okay.

Wolfi Gassler (00:54:46 - 00:54:48)

Was ist die falsche seite Ich überlege.

Andy Grunwald (00:54:48 - 00:55:37)

Jetzt ganz lange, ich hab keine Ahnung. Wahrscheinlich irgendwie Layoffs oder so. Nein, aber der Punkt ist halt einfach nur, ihr als Entwicklerinnen und Entwickler könnt es in der Regel nicht verhindern. Die RE-AUG wird durchgezogen. Und jetzt kann man da trauernd sitzen, als Pessimist. Oder jetzt kann man sagen, okay, das ist außerhalb meiner Kontrolle und ich versuche das Beste daraus zu machen, denn es kann euch natürlich betreffen. Ihr könnt euren Manager wechseln. Kann sein, dass Teams durchgewürfelt werden, dass ihr an einem anderen Produkt bald arbeitet. Es gibt aber auch positive Chancen, wie zum Beispiel, dass ihr in ein neues Team kommt, weil ihr im aktuellen Team vielleicht nicht so glücklich seid, dass ihr vielleicht sogar eine neue Position bekommt. Wolfgang hat gerade Startups erwähnt. Vielleicht wird auf einmal ein Tech Lead benötigt oder ähnliches. Also ihr könnt da schon, ich sage mal, auch ein bisschen positiv in die Zukunft schauen.

Wolfi Gassler (00:55:38 - 00:57:21)

Und wir erwähnen das ja eigentlich immer wieder, jetzt im Recruiting zum Beispiel, wenn jetzt jemand zehn Jahre Berufserfahrung hat, sind es zehnmal ein Jahr immer dasselbe machen oder sind es wirklich zehn Jahre, wo man immer wieder andere Dinge gemacht hat? Und ganz hart gesprochen, umso mehr Reorgs man durchgemacht hat, umso mehr Dinge hat man gesehen, erlebt und hat vielleicht auch gelernt, damit umzugehen. Und umso wertvoller ist eigentlich diese Erfahrung, dass man mit solchen Dingen umgehen kann und einfach vielleicht auch nicht mehr so schlimm reagiert. Weil es ist zwar ganz nett, Andi, wenn du jetzt sagst, bleib mal ruhig und es wird eh alles gut und man kann eh nichts dagegen machen. Aber wenn man wieder unsere Change-Kurve anschaut, die halt jeder Mensch eigentlich durchlebt, wenn er irgendwie was Negatives erfährt, dann braucht es einfach eine gewisse Zeit. Da helfen einfach keine, es wird schon wieder besser und so weiter von oben. Das hilft dir in dem Moment einfach nichts. Und ich habe auch bei Reorg schon miterlebt, dass Leute schluchzend, weinend, ewig lang in den Offices gesessen sind. Und das kann mir niemand erzählen, dass das gut durchgeplant war. Und das waren größere Firmen. Also das endet teilweise wirklich in viel Tränen, aber umso mehr man erlebt hat, umso locker man darauf zugeht, ist natürlich schwierig, umso einfacher wird es am Ende. Und ich persönlich zum Beispiel habe eigentlich aus allen Reorgs schlussendlich, auch wenn es teilweise negativ war, dann am Ende schon gesehen, dass das sehr positive Auswirkungen gehabt hat. Und wie gesagt, man sieht sie nicht immer, aber man kann zumindest hoffen, dass es in die Richtung geht. Und im schlimmsten Fall ist es wenigstens eine Erfahrung im CV, die man reinschreiben kann. Ich habe da ein Team gewechselt, anderes Team. Oder ich habe vielleicht sogar, wie du sagst, einen Engineering Manager Boston dann bekommen oder habe etwas Neues ausprobiert, was es dann auch immer ist.

Andy Grunwald (00:57:21 - 00:57:29)

Du stellst dir auch vor bei einer reorg laufe ich so durch durch das büro und und laufe immer so auf jede schulter klopfen ach das wird schon wieder das wird schon wieder.

Wolfi Gassler (00:57:29 - 00:58:26)

Ja eben genau das funktioniert eben nicht aber wenn du einen vertrauenswürdigen engineering manager hast oder engineering managerin, Und die das auffangt für dich, weil die kennt das Team perfekt. Die weiß genau, wer in meinem Team kann gut umgehen mit Change, wer ist offener, wen brauche ich überhaupt nicht behandeln. Und welche Leute, die sind einfach da Träger, würde ich mal sagen, haben ihr Spezialgebiet und können einfach nicht mit Change so gut umgehen oder mit Stress. Und die muss ich dann eher auffangen. Und du brauchst diese Leute, die die Re-Org durchführen. Und die musst du eigentlich probieren, mit an Bord zu nehmen, möglichst früh und damit es schnell umgesetzt wird und wirklich die Leute aufgefangen werden. Weil sonst hast du einfach die Leute, die kündigen, also ich habe das auch erlebt in einer schlechten Re-Org, wo dann wirklich Leute gesagt haben, die gar nicht betroffen waren, kündigt. Das war einfach so schlecht und da haben reihenweise die Leute gekündigt. Nur wegen der schlecht durchgeführten Re-Org.

Andy Grunwald (00:58:27 - 00:59:44)

Ja, verstehe ich. Aber hey, ich bin jetzt auf der Kontraseite von dir, denn folgendermaßen. Ich denke, was man als IC machen kann, ist zu akzeptieren, dass manche Dinge außerhalb seiner Kontrolle sind. Und ich denke, auch ist es wichtig zu sagen, dass eine Re-Org für jeden etwas anderes bedeutet. Du hast ja auch gerade von von Leuten gesprochen, die vielleicht ein paar Tränen vergossen haben. Ja, und vielleicht ging es auch an die mentale Gesundheit von diesen Leuten, weiß ich nicht. Aber Fakt ist, Reh-Orgs sind in der Regel nichts Persönliches. Also, sie gehen nicht auf dich als Mensch. Und deswegen sage ich, fokussiere dich auf das, was in deiner Kontrolle ist. Und wenn du, Achtung, hart gesagt, unpopular Opinion, jeder hat eine Wahl. Wenn du selbst sagst, okay, Ich möchte keine weitere Re-Org mit dieser Firma mitmachen, dann such dir bitte was Neues. Da wird dir keiner böse sein. Ist zwar schade für dich als Manager, verstehe ich, aber fokussiere dich auf das, was du selbst als Softwareentwicklerin in deiner Kontrolle hast. Und wenn du denkst, dass in einer anderen Firma das besser ist, dann versuch es. Ich denke, es ist nicht besser, sondern du tauschst nur ein Problemset mit dem anderen und überlegst dir dann, mit welchem Problemset du besser klarkommst. Aber ich denke immer noch, fokussiere dich auf das, was du unter deiner Kontrolle hast. Und wo du arbeiten möchtest, hast du in der Regel, ja, zu einem Großteil natürlich, unter deiner Kontrolle.

Wolfi Gassler (00:59:45 - 01:00:17)

Ja, aber es gibt schlecht, meiner Meinung nach schlecht durchgeführte Re-Orgs und gut durchgeführte Re-Orgs. Und ich hab beides erlebt. Darum bin ich sicher, dass es da einen Unterschied gibt. Und klar, wie du richtig sagst, die Leute sollen sich das überlegen. Aber ich muss natürlich dann auch als durchführende Person von so einer Re-Org damit umgehen dass denn das resultat ich auch tragen muss weil wenn ich bei einer reorg 20 prozent meiner guten leute verliere, dann ist es meine schuld und dann kann ich jetzt sagen ja die leute die die haben halt keine ahnung und sind nicht gut geeignet.

Andy Grunwald (01:00:18 - 01:00:49)

Also eine reorg ist ein disruptives event was hochkomplex ist ja nicht nur mental sondern auch business technisch nicht nur kommunikativ, Es sind so viele Leute involviert. Und ja, das Risiko, dass du Leute dabei verlierst, ist immer gegeben. Deswegen sagten wir ja auch, oft wird das von unten gesehen als, was war das denn für eine Shitshow hier. Und das kommt ja nicht von irgendwo her. Aber um mal wieder zum Positiven zu kommen. Denn der Pessimist Wolfgang sagt mal wieder hier, was alles schiefgehen kann. Also ich denke, was kannst du...

Wolfi Gassler (01:00:49 - 01:01:08)

Kurze Frage noch, wenn wir gerade beim Pessimismus sind. Prozentuell, von deinen ganzen Reacts, die du durcherlebt hast, ich glaube übrigens nicht, dass es nur sechs sind, weil wir haben ja gemeinsam schon mehr als sechs Reacts durcherlebt. Prozentuell, wie viele waren gut durchgestylt und durchgeplant und wie viele schlecht? Deine eigenen waren natürlich alle perfekt, das ist eh klar.

Andy Grunwald (01:01:09 - 01:01:36)

Logisch, aber ich denke, man kann ohne Probleme sagen, dass in jeder REOG, die ich mitgemacht hab, irgendwo ein Teil der Shitshow war. Also, ist es völlig egal, vielleicht nicht global. Also, ich mein, in der Ausführung, dass irgendetwas immer hinten runtergefallen ist. Sei es bei mir im Team oder in anderen Teams. Ich hatte auf jeden Fall sehr oft die Aufgabe, dass ich Fragen bekommen hab, die ich oft nicht beantworten konnte, die ich hinterher aufräumen musste. Also, irgendwas fällt immer runter.

Wolfi Gassler (01:01:37 - 01:02:23)

Also bei mir waren sicher, würde ich mal sagen, 30 Prozent der Reorgs, die ich miterlebt habe, waren beschissen durchdesignt und da war ich auch null involviert oder nur ganz, ganz am Rande, aber habe da wirklich schlechte Sachen miterlebt. Würde mal sagen, die Hälfte war sicher gut. Und wie du richtig gesagt hast, man muss danach aufräumen und gerade die Engineering Manager Innen trifft es eigentlich, weil die müssen dann wirklich die Leute auffangen und das durchdrücken. Und da kann man, glaube ich, sehr viel bewegen und sehr viel bewirken. Und ich glaube, da muss man einfach auch in die positive Richtung dann arbeiten. Aber ich glaube, der Erfolg einer Reorganisation, also die Execution, hängt dann wirklich von den Personen ab, die sie durchführen. Und das ist, glaube ich, ein Key-Kriterium.

Andy Grunwald (01:02:23 - 01:03:51)

Also ein Punkt, den jeder in dem Unternehmen machen kann, ist auf jeden Fall zu versuchen, das neue Organigramm, das neue Org-Chart zu verstehen, die neue Wertschöpfungskette zu verstehen. Und eigentlich auch wirklich mit der Frage, welche Probleme sollen denn eigentlich gelöst werden? Und da kannst du natürlich deine Vorgesetze fragen oder halt, was ich viel besser finde, die Möglichkeit in einer Q&A oder einem Ask-Me-Anything-Channel zu fragen. Stell die Frage einfach. Das ist nicht böse gemeint. Das Management ist darauf vorbereitet, solche Challenges und Fragen zu bekommen. Und die Org-Challenges werden nicht aus Langeweile gemacht, sondern aus einem guten Grund. Und es ist wirklich, wirklich, wirklich essenziell, dass jeder das warum dahinter versteht. Und es ist eine Aufgabe des Top-Level-Managements, dies zu erklären, damit nämlich das Tal der Tränen in der Change-Management-Kurve so gering wie möglich bleibt. Und zumindest, dass die Akzeptanz relativ schnell kommt. Denn ich denke, wenn man versteht, warum man etwas macht, dann heißt das nicht immer, dass man damit einverstanden ist oder dass man denselben Gedanken hat. Es heißt aber, hey, okay, da haben sich Leute Gedanken gemacht. Und wenn du wirklich proaktiv sein möchtest, dann kannst du natürlich deine Vorgesetze auch fragen. Hey, ich habe gehört beim Andi und bei Wolfgang, nach einer Re-Org müssen ganz viele Scherben zusammengekehrt werden und aufgeräumt werden müssen. Wie kann ich denn dir helfen? Ich hätte mir als Engineering Manager sehr oft gewünscht, dass Leute diese Frage zu mir gestellt hätten, weil das wäre so ein Traum. Ich hätte die Leute gerne umarmt, dachte, danke, hier hast du ein Kerblech.

Wolfi Gassler (01:03:51 - 01:04:25)

Also, man muss auch sagen, ganz oft, und das gerade bei den Rehawks, wo ich jetzt nicht involviert war und eben so eher vom Rande zugeschaut hab, teilweise hilft's auch einfach mit den Leuten, dann was trinken zu gehen und sich einfach das mal anzuhören und denen irgendeine Form zu bieten, dass die sich ausheulen können auf gut Deutsch und mal auskotzen. Und das hilft auch schon. Weil, wie gesagt, da sind wir halt in der Change Curve dann einfach in dem Anfangsstadium Schock und Verneinung und Einsicht und da hilft es auch, wie gesagt, einfach mal was gemeinsam zu trinken und zuzuhören.

Andy Grunwald (01:04:26 - 01:04:31)

Wolfgang, ich habe mal gehört, ich glaube von einem Alkoholiker, dass Trinken... Ich habe.

Wolfi Gassler (01:04:31 - 01:04:39)

Eben Trinken gesagt, ich habe extra kein Bier erwähnt, keinen Alkohol, es könnte auch ein Kaffee sein, ein Kaffee, weil das ist eine gute positive Lebensentscheidung.

Andy Grunwald (01:04:39 - 01:04:58)

Umgangssprachlich, wenn wir sagen, lasst mal was trinken gehen, das ist sozial anerkannt, dass in der westlichen Gesellschaft, lasst mal was trinken gehen, echt oft Alkohol im Arbeit ist. Und jetzt halte ich fest, ich habe mal, ich glaube, von einem Alkoholiker gehört, trinken bringt eigentlich gar nichts, weil die Probleme, die können schwimmen.

Wolfi Gassler (01:04:58 - 01:04:59)

Und die bleiben immer oben.

Andy Grunwald (01:05:01 - 01:05:06)

Auch wenn du nüchtern bist, sind die Probleme halt immer noch da. Aber summa summarum.

Wolfi Gassler (01:05:06 - 01:05:09)

Kaffee trinken oder auch vielleicht Mate oder was es auch immer ist.

Andy Grunwald (01:05:09 - 01:05:12)

Ja, auch Koffein wirkt die Probleme nicht.

Wolfi Gassler (01:05:13 - 01:05:19)

Naja. Aber zuhören kann Probleme zumindest einfacher verdauen zu lassen.

Andy Grunwald (01:05:19 - 01:05:58)

Ich glaube, da sind wir d'accord. Summa summarum kann man aber auch sagen, und das gilt für alles und jeden in diesem Sinne, was Rehawks betrifft, es ist nicht einfach, eine Rehawk durchzuführen und es ist auch nicht einfach, das Beste daraus zu machen. Es ist für jeden hart und es wird auch, bin ich ganz ehrlich, mit der Zeit nicht leichter. Auch wenn Wolfgang und ich 6, 7, 8, weiß ich nicht, wie viele Rehawks durchgemacht haben, irgendwann akzeptiert man diese und weiß, okay, dann machen wir die ganze Sache halt jetzt nochmal durch, aber Solange man akzeptiert, dass das eigentlich für was Gutes gedacht ist. Ja, es wird nicht einfach. Also, Daumen drücken, durchhalten. Ich wäre am Ende.

Wolfi Gassler (01:05:58 - 01:06:02)

Für dieses Wort am Sonntag, danke Andi.

Andy Grunwald (01:06:02 - 01:06:12)

Kein Problem. Und falls ihr auch mal so eine Horror-Story aus euren Re-Orgs mit uns teilen wollt. Wir haben noch so eine Discord-Community. Da könnt ihr reingehen, könnt uns das alles mitteilen. Und da sind ganz viele tolle Leute.

Wolfi Gassler (01:06:12 - 01:06:14)

Die auch alle so ein Scheiß-Doc erlebt haben.

Andy Grunwald (01:06:14 - 01:06:44)

Die ihr auch so scheiße seht. Nein, da geht's halt mal darum, okay, Butter bei die Fische, lasst mal über die Probleme sprechen. Unsere Discord-Community ist 24-7 offen, auch an Feiertagen. Und kommt einfach mal vorbei. Und falls bei euch grad ne Reh-Org war oder ihr habt durch den Flurfunk gehört, dass eine ansteht, teilt diese Folge doch mal mit eurem Bestie auf der Arbeit, damit ihr beide zusammen durch den Sturm geht. Ansonsten würde ich sagen, vielen Dank Wolfgang für deine pessimistische Meinung.

Wolfi Gassler (01:06:45 - 01:06:46)

Immer gerne.

Andy Grunwald (01:06:46 - 01:07:00)

Bedenkt immer, der Wolfgang ist der Böse hier, weil der Wolfgang ist Consultant und wie er am Anfang gesagt hat, Consultants werden oft berufen, um Änderungen herbeizuführen. Das bedeutet, eure Verbindung im Kopf, Wolfgang gleich Re-Org.

Wolfi Gassler (01:07:00 - 01:07:03)

Und die Negative natürlich, immer nur negative Erfahrungen.

Andy Grunwald (01:07:03 - 01:07:06)

Das war's, bis nächste Woche und tschüss. Ciao.

Shownotes / Worum geht's?

Links

Sprungmarken

Hosts

Feedback

Transkript

Andy Grunwald (00:00:04 - 00:00:57)

Wolfi Gassler (00:00:57 - 00:01:04)

Andy Grunwald (00:01:04 - 00:02:10)

Wolfi Gassler (00:02:10 - 00:02:21)

Andy Grunwald (00:02:21 - 00:02:24)

Wolfi Gassler (00:02:25 - 00:02:41)

Andy Grunwald (00:02:42 - 00:03:03)

Wolfi Gassler (00:03:04 - 00:03:27)

Andy Grunwald (00:03:27 - 00:03:36)

Wolfi Gassler (00:03:36 - 00:03:48)

Andy Grunwald (00:03:49 - 00:04:09)

Wolfi Gassler (00:04:09 - 00:04:44)

Andy Grunwald (00:04:45 - 00:04:49)

Wolfi Gassler (00:04:49 - 00:04:56)

Andy Grunwald (00:04:56 - 00:05:19)

Wolfi Gassler (00:05:19 - 00:05:23)

Andy Grunwald (00:05:23 - 00:05:42)

Wolfi Gassler (00:05:43 - 00:05:51)

Andy Grunwald (00:05:51 - 00:05:56)

Wolfi Gassler (00:05:57 - 00:06:13)

Andy Grunwald (00:06:13 - 00:07:40)

Wolfi Gassler (00:07:40 - 00:08:17)

Andy Grunwald (00:08:17 - 00:09:14)

Wolfi Gassler (00:10:37 - 00:11:24)

Andy Grunwald (00:11:25 - 00:11:57)

Wolfi Gassler (00:11:57 - 00:11:58)

Andy Grunwald (00:11:59 - 00:12:05)

Wolfi Gassler (00:12:06 - 00:12:36)

Andy Grunwald (00:12:37 - 00:12:39)

Wolfi Gassler (00:12:40 - 00:13:15)

Andy Grunwald (00:13:15 - 00:14:06)

Wolfi Gassler (00:14:06 - 00:14:11)

Andy Grunwald (00:14:12 - 00:14:58)

Wolfi Gassler (00:14:58 - 00:15:04)

Andy Grunwald (00:15:05 - 00:15:08)

Wolfi Gassler (00:15:09 - 00:15:13)

Andy Grunwald (00:15:13 - 00:15:41)

Wolfi Gassler (00:15:41 - 00:15:44)

Andy Grunwald (00:15:45 - 00:15:59)

Wolfi Gassler (00:16:00 - 00:16:31)

Andy Grunwald (00:16:32 - 00:17:09)

Wolfi Gassler (00:17:10 - 00:18:07)

Andy Grunwald (00:18:07 - 00:19:27)

Wolfi Gassler (00:19:27 - 00:19:42)

Andy Grunwald (00:19:43 - 00:20:31)

Wolfi Gassler (00:20:31 - 00:20:44)

Andy Grunwald (00:20:44 - 00:22:06)

Wolfi Gassler (00:22:06 - 00:23:25)

Andy Grunwald (00:23:25 - 00:25:09)

Wolfi Gassler (00:25:09 - 00:26:46)

Andy Grunwald (00:26:47 - 00:27:32)

Wolfi Gassler (00:27:32 - 00:27:40)

Andy Grunwald (00:27:40 - 00:27:41)

Wolfi Gassler (00:27:42 - 00:27:47)

Andy Grunwald (00:27:48 - 00:28:50)

Wolfi Gassler (00:28:50 - 00:29:09)

Andy Grunwald (00:29:09 - 00:30:08)

Wolfi Gassler (00:30:08 - 00:30:14)

Andy Grunwald (00:30:14 - 00:30:18)

Wolfi Gassler (00:30:18 - 00:30:21)

Andy Grunwald (00:30:22 - 00:30:25)

Wolfi Gassler (00:30:25 - 00:30:48)

Andy Grunwald (00:30:48 - 00:32:16)

Wolfi Gassler (00:32:16 - 00:32:53)

Andy Grunwald (00:32:53 - 00:35:11)

Wolfi Gassler (00:35:11 - 00:35:19)

Andy Grunwald (00:35:19 - 00:35:24)

Wolfi Gassler (00:35:24 - 00:35:27)

Andy Grunwald (00:35:27 - 00:35:28)

Wolfi Gassler (00:35:28 - 00:35:30)

Andy Grunwald (00:35:30 - 00:36:07)

Wolfi Gassler (00:36:08 - 00:36:18)

Andy Grunwald (00:36:18 - 00:36:27)