„Nach der Re-Org ist vor der Re-Org“ – Change in Tech-Teams

Joel Kaczmarek: Hallo Leute, heute wird es wieder mal technisch. Und zwar ist der liebe Björn Wagner wieder am Start. Ihr wisst ja, der ist VP Engineering bei SAP Signavio und der hat den lieben Till Reiter im Gepäck. Und Till ist mittlerweile CPO bei Integrity Next. Und wenn die beiden da sind, dann reden wir immer fleißig über Product und IT. Also Engineering, was passiert eigentlich so unter der technischen Oberfläche? Was ist da so los? Und heute haben wir so zusammengesetzt und dachten, naja, irgendwie ist ja manchmal auch der Fall gegeben, dass man auch mal eine Firma transformiert und dann natürlich auch die Technologie transformiert. und Wie geht denn das eigentlich? Was sind denn so die wichtigsten Fragen, die man sich dabei stellen sollte? Dann haben wir uns überlegt, die zehn wichtigsten Fragen in dem Bereich. Also die erste Frage sind eigentlich nur Buchtipps, kann ich euch schon mal vorwegnehmen. Aber es sind noch neun andere Fragen dabei, die es richtig in sich haben. Zum Beispiel so Fragen wie, sollte ich das Top-Down oder Bottom-Up machen? Brauche ich neue Leute? Also all diese Dinge wirst du heute mitnehmen. Von daher steigen wir richtig ein. Es geht los, praxisnah wie immer. Hallo lieber Björn, moin lieber Till. Hi Joel.

Björn Wagner: Hi.

Joel Kaczmarek: Und ich meine, vielleicht mal Frage an euch vorneweg. Ich glaube, man könnte schon sagen, dass ihr auch selber Transformation durchgemacht habt, oder? Mit Signavio, als ihr dann gekauft wurdet von SAP und wahrscheinlich auch vorher so die eine oder andere Stufe. Gehe ich da richtig in der Annahme, Björn?

Björn Wagner: Ja, absolut. Wir sind sehr, sehr stark gewachsen über die letzten vier Jahre, sowohl vor der Akquisition als dann auch nach der Akquisition. Und wenn man stark wächst, das heißt die Organisation mehr oder weniger so verdoppelt jedes Jahr, dann ist man eigentlich in einer kontinuierlichen Transformation drin, weil immer Sachen kaputt gehen, die vorher sehr gut funktioniert haben. Und ja, deshalb haben wir da, glaube ich, einige Geschichten zu erzählen.

Till Reiter: Mein Lieblingszitat hierzu von einem Ex-Kollegen von der SAP ist Nach der Transformation ist vor der Transformation. Das ging um Re-Orgs in dem Kontext, aber ich denke, das trifft es ganz gut. Und auch bevor wir schon Teil der großen SAP-Familie waren, war eigentlich kein Jahr so wie das Jahr davor.

Joel Kaczmarek: Also ich merke mir, nach der Re-Org ist vor der Re-Org, das klingt nochmal cooler.

Till Reiter: Genau.

Joel Kaczmarek: Alles klar, so und jetzt habe ich von euch beiden gelernt im Vorgespräch, dass es so ein Standardwerk gibt, auf das ihr euch beide sofort verständigen konntet, wo ihr der Meinung seid, wenn ich transformiere im technischen Bereich, dann gehört das gelesen und zwar von Marty Kagan. Was hat es denn damit auf sich? Holt mich mal ab als jemand, der nicht so technisch ist wie ihr.

Björn Wagner: Also es ist auf jeden Fall Marty Kagan, glaube ich, sehr beliebt in der Community und es gibt so einen gewissen Hype und ich glaube, heute können wir ein bisschen darauf eingehen, inwiefern er halb gerechtfertigt ist und wie das so in der Realität aussieht. Aber grundsätzlich, also ich könnte jetzt zwei Stunden darüber erzählen, wir haben aber schon auch, glaube ich, in den letzten Folgen sind wir mal sehr, sehr viel auf viele dieser Prinzipien eingegangen. Aber am Ende des Tages ist dieses, das neueste Buch, was es, glaube ich, jetzt seit Anfang des Jahres gibt, sehr praxisorientiert, zeigt halt, was sind so Prinzipien, die alle erfolgreichen Tech-Firmen, die halt am Markt sehr, sehr erfolgreich sind, eigentlich anwenden und was denn quasi Implikationen daraus auf die Organisation sind. Und eigentlich im Kern, wie gesagt, sehr, sehr kurz zusammengefasst, gibt es halt eigentlich so, die Prinzipien drehen sich um drei Hauptfragestellungen. Das heißt, wie entscheide ich denn, welche Kundenprobleme ich löse? Das ist so Produktstrategie, quasi mehr in die Breite geschaut. Dann, wenn ich ein Problem ausgesucht habe, wie wird das Problem gelöst? Und dann ist dieses Konzept Import-Product-Teams, wo wir auch schon viel drüber gesprochen haben, cross-funktionale Teams, wie versteht man Kundenprobleme, wie löst man die, wie baut man viele Prototypen, um möglichst viel zu lernen, bevor man quasi das in Code gießt. Und dann geht es natürlich auch darum, wie baut man Software effizient und effektiv, dass man halt schnell und in, sag ich mal, kurzen Zyklen zum Beispiel shippen kann. also da steht sehr, sehr viel dahinter und im Kern geht es dann auch wieder um diese cross-funktionalen Teams und Rollen und im Wesentlichen sind halt da dann nochmal im Detail quasi so vier Hauptrollen ausformuliert, da geht es halt um den Product Manager, UX Designer, Tech Lead, die so als Powertrio sich dann auf die verschiedenen quasi Bereiche fokussieren, der Problemlösung und dann noch ganz wichtig das Thema auch Product Leader, die dann quasi die jeweiligen Leute coachen, mentoren und weiterentwickeln an der Stelle. Und das ist halt sehr gut ausgeführt, relativ kurzweilig und ist aus meiner Sicht halt eine sehr, sehr gute Zusammenfassung und auch ein sehr guter Einstieg, wenn man sich mit dem Thema beschäftigen möchte.

Till Reiter: Ja, vielleicht hier als Add-on. Marty Kagan ist ja schon bekannt, wie du sagst, Jordan, in der Product-Community. Ich glaube, sein erstes Buch hieß Inspired, das viel so auf diese Daily-Doing-Prozesse von Product-Teams fokussiert hat. Und Transformation ist jetzt halt wirklich den Fokus auf schon Organisationen, die weiter sind in ihrer Phase. Und ist auch angereichert mit ein paar Praxisbeispielen, zum Beispiel wie jetzt Adobe von Boxed-Products zu einer SaaS-App transformiert hat, ja. Und das ist natürlich bei Unternehmen von so einer Größe schon ein größeres Brett. Deswegen ist es eigentlich ganz spannend.

Joel Kaczmarek: Gut. Und wie schon angedroht, erste Frage gleich noch in die Kerbe hauend. Was sind denn sonst so drei, vier Bücher, die ihr den Leuten mal empfehlen würdet, wenn sie das Thema beschäftigt, was sie vielleicht über die Feiertage mal sich zur Hand nehmen könnten?

Björn Wagner: Ja, also wie gesagt, für mich ist dieses Buch ein guter Einstieg und so eine gute Klammer. Was ich eigentlich immer empfehle, sind noch so vier andere Sachen, die teilweise sogar referenziert werden. Das ist einmal natürlich, es fängt alles mit Strategie an. Da gibt es ein, ich glaube, schon sehr, sehr altes Buch, Richard Rummelt, Good Strategy, Bad Strategy. Da sind so ein paar einfache Kernprinzipien, mit denen man, glaube ich, sehr gut erklären und halt auch dann umsetzen kann an der Stelle. Dann ein wichtiges Thema, gerade halt immer für die Leadership-Seite, wird viel angesprochen, das Thema Team-Topologies. Also wenn ich jetzt eine größere Organisation habe, welche Teams definiere ich denn? Wie teile ich denn quasi verschiedene Probleme denn den Teams zu? Wie schneide ich das effizient, etc.? Da gibt es von Matthew Skelton, auch relativ neu, gibt es einen guten Web-Content, aber auch ein gutes Buch, heißt direkt Team-Topologies. Dann, ich hatte gerade schon mal drüber gesprochen, das Thema Tech-Lead, was ja sehr, sehr stark und was, glaube ich, auch einer der Kernaspekte ist, dass man Engineers nicht als die Code-Monkeys sieht an der Stelle, die dafür da sind, irgendwie eine Spezifikation, die jemand anders definiert hat, runterzuprogrammieren, sondern dass auch die Engineers sehr früh im Product Discovery Prozess, im Problemlösen quasi mit den Designern und so weiter involviert sind. Hier ist, finde ich sehr gut, das Staff Engineer Path. Das ist ein sehr gutes Buch, das beschreibt so, hey, wie kann ich mich als Engineer denn weiterentwickeln? Was sind so die Anforderungen und so weiter? Und das Letzte, wenn man so in Richtung Management Leadership gehen will, gibt es so etwas Neues, das heißt Leading Effective Engineering Teams. Hier sehr spannend, Google hat sehr, sehr viele Experimente gemacht und wirklich Studien intern, die so zeigen aus Leadership und Management Sicht, was sind denn Erfolgsfaktoren für Teams und halt genau sehr, sehr spannend, kann man glaube ich viel mitnehmen und auch sehr, sehr praxisbezogen am Ende. Also das sind so die Sachen, wenn man viel lesen möchte über die Feiertage, dann kann ich alle empfehlen. Ich glaube aber, wie gesagt, das Thema Transform ist ein guter Einstieg, gerade wenn man sich halt fragt, hey, macht es vielleicht Sinn, Produkte anders zu entwickeln an der Stelle? Also gibt es einen besseren Weg, wie man Produkte baut, wie wir Kundenprobleme lösen, dann ist das ein super Einstieg.

Till Reiter: Ich will noch einen Klassiker in den Ring werfen. Lead to Change von John P. Cotta heißt der gute Mann, glaube ich. Das ist so das Standardwerk im Change Management, wo er auch irgendwie, glaube ich, vier oder acht Schritte darlegt. Kann man auch gut googeln. Da gibt es ein Institut, würde ich eben nahelegen. Gut, mega.

Joel Kaczmarek: Und dann mal wirklich reingetaucht. Also wir hatten ja eben in der Anmoderation auch schon mal so die erste zentrale Frage, wenn ihr transformiert, was ist so eure Hypothese? Sollte Change Top-Down erfolgen oder Bottom-Up? Also entweder von der Führungsriege oder vom Team, was vielleicht manchmal an der Front ja sogar ein bisschen mehr mitkriegt als die da oben, wie man so schön immer sagt.

Björn Wagner: Also ich glaube, so große Changes, die müssen schon von oben, also von Top-Down getrieben werden. Also da braucht man, in typischen Firmen wäre das wahrscheinlich der CTO, Chief Technology Officer, Chief Product Officer, die solche Transformationen voranbringen. Man braucht auch dann natürlich, gerade weil ja im Viel Teil der Transformation ist halt auch, wie arbeitet man eigentlich mit Kunden? Was sind so die Interaktionen? Wie viele Kunden-Commitments gibt man eigentlich raus oder besser nicht raus und so weiter? Es geht natürlich auch viel in das Thema Go-To-Market-Sales rein. Also man braucht quasi auch Buy-In vom CEO, dass man quasi eigentlich in die Richtung gehen möchte. Also für mich fängt es dort an. Und dann ist aber natürlich wichtig, dass man die gesamte Organisation mitnimmt dabei. Weil am Ende optimiert man ja immer für, wie man so schön sagt, das Team of Ten. Also da will man ja die richtige Umgebung schaffen, dass die Leute irgendwie Probleme lösen können, Produkte bauen, die Wert schaffen für die Kunden. Und das ist irgendwie der Fokus. Aber man kann halt nur erfolgreich sein, wenn man das, glaube ich, top-down dort eine gemeinsame Richtung definiert.

Joel Kaczmarek: Wie ist denn so der CPO-Blick darauf, Till?

Till Reiter: Ja, ich stimme hier großteils zu. Also große Transformation ohne eine Zielrichtung oder eine Vision von oben, dann weißt du nicht, in welche Richtung du laufen sollst oder bottom-up die Leute laufen sollen. Deswegen geht das eigentlich schon von der Definition hier nicht. Wie Björn schon gesagt hat, auch in diesem Kotter-Framework zum Beispiel, du brauchst dann auch sozusagen eine Volunteer-Army, Leute am Ground, die überzeugt sind oder im positiven Sinne verhaftet sind, diese Transformation zum Verfolg zu treiben und das dann eben auch auf ihren Levels pushen und fortführen. Aber ohne Vision und einem Sense of Urgency von oben wird das nicht funktionieren.

Joel Kaczmarek: Also gar nicht kommt es von oben oder von unten, sondern der Visionsteil von oben und ich sage mal das Empowerment quasi vom Botten ab. Da kann man ja eigentlich dann quasi schnell einen Haken hinter machen. Was dann die zweite Frage aufwirft, was sind so deine Erfahrungen, wenn ich transformiere, nachdem ihr ja auch schon durch seid quasi mehrfach, brauche ich dafür eigentlich neue Leute, braucht es andere Talente und verlieren halt vielleicht auch manche Menschen, die bis dato da waren, so ein bisschen den Zugang, wenn sich Dinge ändern, weil manche Sachen werden ja so ein Stückchen industrieller, anonymer. Oder sagst du, nee, kann man eigentlich gut aus dem Bestandsteam bauen?

Björn Wagner: Hier auch die klassische Antwort, it depends. Also glaube ich, kann man nicht so beantworten. Was wichtig ist, also wenn man schon eine starke Tech-Organisation hat, dann braucht man nicht zwangsläufig gute Leute. Und so diese Standard-Ausreden, die man nur hört, ja, aber Google bezahlt halt die Leute viel besser und deshalb kann Google nur so Produkte bauen. Ich glaube, das stimmt halt nicht am Ende des Tages. Ich würde sagen, es gibt so ein paar Sachen, die sehr, sehr wichtig sind. Also man sollte die Engineering-Teams zum Beispiel oder grundsätzlich die Leute, das sind teils Product-Teams, halt nicht outsourcen. Es sollte irgendwie keine Also Outsourcing sein, dass man sagt, okay, ich hole mir jetzt irgendwie 50 Leute von Accenture und die bauen das dann für mich nach dem Motto. Das heißt, die Leute müssen schon Teil der Organisation sein. Das heißt, wenn man das hat, dann ist es eigentlich nur noch wichtig, dass man auch diese verschiedenen Rollen, die ich auch angesprochen habe, Designer, Product Manager und Engineers halt auch in der richtigen Zahl vorhat. Also es hilft nichts, wenn man jetzt dieses Modell adoptieren möchte, aber dann zum Beispiel nicht genug Product Manager hat oder nicht genug Designer, die dann wirklich die Zeit haben, mit den Teams dran zu arbeiten. Und dann braucht man vielleicht einfach mehr Leute und ausbalancierte Teams, dass man dann diese Rollen auch füllen kann. Grundsätzlich geht es aber eher darum, wirklich die Umgebung zu schaffen, in dem die Leute, die Engineers, die Designer halt dann auch ihre beste Arbeit machen können und man die Leute motiviert. Und halt mitnimmt, und das ist ja genau dieses Thema Empowerment, viel Autonomie geben, aber auch gleichzeitig Alignment in Richtung, was ist unsere Strategie, was ist der Kontext, den Guardrails, in dem wir uns bewegen. Und dann, wenn man die richtige Anzahl an Leuten hat und die Teams richtig mixen kann und auch nicht riesige Teams hat, dann braucht man keine neuen Leute, aber da muss man halt schon schauen, dass man diesen Mix halt hinbekommt.

Joel Kaczmarek: Gut, jetzt haben wir uns ja, Stück für Stück hangeln wir uns ja durch. Also erstmal gefragt, gucke ich von oben oder gucke ich von unten? Nein, von oben Vision, von unten Empowerment. Dann brauche ich dafür neue Teams, hast du ja gerade ganz schön gesagt, dass es im Prinzip so diese Ermächtigung wichtig ist. Und jetzt ist ja noch die Frage, Stichwort Ermächtigung, Frameworks ist ja so ein großes Thema. Also OKRs zum Beispiel, würdet ihr sagen, dass das ein essentieller Bestandteil davon ist? Oder ist es vielleicht manchmal hier und da, wenn ich Transformation fahre, auch ein Stück weit überbewertet?

Till Reiter: Ich habe mittlerweile relativ stark die Meinung, dass Frameworks überbewertet sind. Auch wenn ich Leute interview, schaue ich immer, erzählen sie mir Frameworks runter oder haben sie die wirklich auch schon in der Praxis gesehen und angewendet? Denn oft läuft man Gefahr, hier sich ein Bürokratiemonster aufzubauen. Klar brauchst du eine Vision, du willst Ziele, dass die kaskadieren auf die einzelnen Teams runter. Aber ich habe das halt erlebt, dass es komplette Arbeitstage oder Wochen lahmgelegt hat. Review, wie waren jetzt die OKRs, Definition der OKRs für das nächste Jahr. Und am Ende des Tages sind das dann doch wieder einfach die Teams, wo die Mission klar ist, wo die Vision klar ist, die eben, wie jetzt Björn sagt, auch empowert oder gut zusammenarbeiten, die die besten Results liefern. Und da kannst du dich vielen Definitionen verlieren, aber ich glaube, das darf man nicht überbewerten. Und auch, es gibt diesen Klassiker von John Doerr, der OKRs bei Google eingeführt hat, aber mittlerweile arbeiten die auch nicht mehr so rigide nach diesem Framework, wie das da dargestellt ist.

Björn Wagner: Also ich glaube, man muss ja nur mal Change Management Framework googeln. Da kriegt man, glaube ich, die Top 10, die Top 15, was sind die besten Frameworks. Für mich immer so der Punkt, es ist eine gute Checklist und am Ende muss man halt das machen, was für die Organisation passt. Und man kann es ein bisschen inspirieren lassen, aber gibt es jetzt das eine Framework, dem man genau by the book folgen muss? Nein. Ich glaube, im Change ist immer ganz wichtig, dass man am Ende Zum einen eine gute Vision hat, eine gute Geschichte erzählen kann, warum das jetzt die richtige Richtung ist und dann den Leuten viel zuhört und halt versteht, was sind denn die Bedenken, was sind die Sorgen und halt diesen Kanal offen hält und dann das halt gemeinsam adressiert am Ende. Und ja, ob es jetzt das Cotter-Modell ist oder die, ich glaube, die sieben S's von McKinsey, I don't know.

Joel Kaczmarek: Okay, also ich höre raus, mit Augenmaß da arbeiten und so ein Stück weit auf die eigene Organisation individualisieren. Und jetzt haben wir ja irgendwie schon ein paar Mal so das Wort Empowerment auch in den Mund genommen. Vielleicht können wir ja dazu auch nochmal eine Zuspitzung fragen. Was glaubt ihr denn, kann eine Organisation, die so gar kein Empowerment hat, also die Teams nicht voll empowert sind, kann denen das überhaupt gelingen zu transformieren? Also ist das so eine notwendige Bedingung? Oder gibt es manchmal auch Pfade, die da hinführen, wo das gar nicht so gegeben ist mit dem Empowerment?

Till Reiter: Ich denke, du hast es schon sehr spitz formuliert, Joel. Also wenn du keine Teams hast, die gut zusammenarbeiten, wenn man das empowert nennt, ja, empowert finde ich an sich immer so ein Es gibt nicht die tolle deutsche Übersetzung dafür und jeder wird es ein bisschen anders definieren, aber da kannst du oben machen, was du willst. Wenn die Teams nicht funktionieren, wird auch deine Transformation nicht funktionieren.

Björn Wagner: Ich glaube, einer der Hauptgründe ist ja so dieses Thema wie motiviert man Leute und wie stellt man halt auch sicher, dass irgendwie quasi die Leute möglichst viel, also quasi oder andersrum gedacht, wenn man den Leuten Freiheit gibt, dann gibt es ja verschiedene Studien und auch Modelle, die halt zeigen, dass Leute dann motivierter sind, engager sind, als wenn der Job die Aufgabe bis ans Kleinste durchdefiniert ist und man nur noch die ausführende Kraft ist. Und dann ist natürlich die Frage Autonomie alleine gerade in großen Gruppen, Unternehmen funktioniert halt nicht, deshalb braucht man immer noch diese zweite Dimension dazu, Alignment, dass man halt ein gemeinsames Verständnis hat, das ist die Vision, das ist die Ziele, dort wollen wir als große Organisation hin. und dann aber, hey, das ist jetzt die Box, in dem ich als Team oder als Individuum dann auch quasi arbeite. Probleme lösen kann und halt selbstständig agieren kann. Und dieses selbstständige Agieren, dabei kontinuierlich zu lernen, ich glaube, das ist halt ein ganz entscheidender Punkt, um halt, wie gesagt, die richtige Umgebung für die Teams zu schaffen. und das steht eigentlich dahinter. Kann man auch anders erfolgreich sein? Ja, also ich glaube, es bedingt es nicht am Ende des Tages, aber da steckt schon sehr viel dahinter, Warum man mit vielen dieser Prinzipien, ich würde es nicht Framework nennen, aber mit den Prinzipien schon auch Teams bauen kann oder Teams formen kann, die sehr, sehr gute Produkte bauen am Ende.

Joel Kaczmarek: Und ich meine jetzt, lass uns doch ruhig auch mal ein Stück weit blasphemisch werden, weil ich glaube, so Alltagsfan ist das gar nicht. Was mache ich denn eigentlich, wenn ich Widerstand kriege? Also aus so einem High-Performance-Team, wenn das sagt, gehe ich nicht mit, teile ich nicht, wie gehe ich damit um?

Till Reiter: Ja, da kann ich jetzt auch wieder nur wahrscheinlich relativ offensichtliche und langweilige Antwort geben, Kommunikation. Also und wir haben das in der Vergangenheit auch erlebt, dass auf mir High-Performer sich dachten, nee, das war alles schön und gut so, ich habe jetzt keine Lust, XY-Fat aufzumachen oder in einem neuen Team zu arbeiten. Wenn man hier das Verständnis nicht schafft, wieso das nötig ist, dann fährt man damit gegen die Wand. Das heißt aber nicht, dass jeder mitgeht. Also zehn Jahre durchzutransformieren und dass jeder Mitarbeiter in dem Setup, das dann gegeben ist, gut performen kann und zufrieden ist, ist auch keine Voraussetzung. Es gibt dann halt oft, wenn dann bestimmte Leute sich unterscheiden, intern zu wechseln oder ein anderes Unternehmen zu wechseln, wenn das dann halt nicht mehr passt in der neuen Arbeitsweise, wie man sich aufstellen will.

Björn Wagner: Also ich finde es eigentlich sehr spannend. In meiner Erfahrung habe ich immer gesehen, dass High-Performing-Teams eher natürlich zu diesem Modell und zu diesen Prinzipien hintendieren. Also die Teams, die am besten performen, die arbeiten auch häufig nach den Prinzipien. Wie gesagt, das ist nicht by the book genau so, wie es hier vielleicht beschrieben ist, aber man sieht dann gewisse Verhaltensmuster, die, selbst wenn die Umgebung das vielleicht nicht super strukturiert bereits vordefiniert, die dann natürlich zu so einer Arbeitsweise tendieren. am Ende des Tages, ja, weil, dass man quasi nah am Kunden ist, die Probleme versteht, die Probleme durchdenkt und dann irgendwie gemeinsam mit guten Lösungen um die Ecke kommt, das ist ja der Kern des Ganzen. am Ende des Tages, ja, und High-Performing-Teams tendieren, also meiner Erfahrung nach in der Regel, häufig dahin, diese Verhaltensweisen, Verhaltensmuster von alleine zu adoptieren. Deshalb steht das in der Regel nicht so viel im Widerspruch von dem, was ich bisher gesehen habe.

Till Reiter: Ja, ich denke schon, du hast trotzdem, wenn du jetzt sagst, du gehst von 120 Mann, du skalierst 500 Leute hoch, werden die Transformationen auch oft mehr Prozesse, mehr Alignment, mehr Struktur beinhalten. Und es gibt einfach Leute, die dann da natürliche Abwehrreaktionen haben. Das ist eigentlich der Punkt, den ich davor meinte. Aber wie Björn schon sagt, es gibt die Top-Performer, die sich dann auch den neuen Gegebenheiten und die guten Teams eigentlich automatisch anpassen.

Joel Kaczmarek: Ich meine, wir kommen jetzt so langsam auch wirklich an die neuralgischen Themen. Also einerseits Widerstand und das andere große Thema bei Transformation im Technologiebereich ist ja immer das Thema Legacy. Also wenn ich Legacy-Systeme habe, wie gehe ich denn damit um? Die kann ich ja jetzt entweder komplett neu schreiben oder ich kann sie so inkrementell verbessern. Was ist so eure Arbeitshypothese, was der richtige Pfad ist?

Björn Wagner: Also das ist ja auch ein Thema, was viele dem Marty Kagan vorwerfen, was er ja nicht so richtig beantwortet oder wo er nicht so eine richtige Antwort drauf hat. Auch hier wieder, wenn man halt ein Legacy-System hat, es gibt halt so viele Variablen, man kann es nicht pauschal sagen, was die richtige Art und Weise ist. Meiner Erfahrung nach ist es immer gut zu schauen, wie komplex ist die Änderung oder wie stark ist die Änderung und wo kann man es am Ende effektiver und schneller umsetzen und was sind denn die Kosten? halt auch, um vielleicht von der Legacy dann auf die neue Lösung zu migrieren. Es hilft vor allem, also wenn man sehr alte Legacy-Systeme hat, dann, dass man sich schon mal Teile rauspickt, vielleicht einen kleinen Teil mal als Pilot, mal neu baut, einfach mal experimentiert, auch wenn man komplett neue Technologie vielleicht verwenden kann, ob das jetzt Sinn macht, quasi nochmal neu anzufangen und man dann aber viel, viel schneller quasi sich bewegen kann und dann am Ende wieder diesen Catch-Up hat. Auf der anderen Seite habe ich auch schon gesehen, dass man es geschafft hat, dann in bestimmten Situationen hat man alles neu gebaut, hat dann Mission Accomplished gefeiert, Und dann kommen dann aber die großen Kunden, die dann doch sehr viele Anforderungen haben, die in der neuen Version auch nicht funktionieren. und dann braucht man teilweise für die erste Version ein Jahr, aber bevor es dann alle Kunden nutzen können, arbeitet man nochmal zwei, drei Jahre, bevor man dann quasi alles wieder vom alten ins neue System geschoben hat. Also gibt es, glaube ich, auch hier leider keinen goldenen Pfad, den man quasi definieren kann, wo man sagen kann, das ist immer das Richtige. Man muss halt schauen, Legacy, was heißt das? Wo möchte ich technologisch auch hin? Und was ist der beste Weg? Und dann immer kleine Experimente laufen lassen, um zu schauen, okay, wie schnell komme ich denn vielleicht auch mit einer neuen Technologie voran? Und dann halt die Entscheidung treffen. Und ich meine, ein großes Beispiel ist ja jetzt AI. Jeder redet über AI. Ist ja auch erstmal nur eine Technologie, da zeugt man ja nicht automatisch viel Mehrwert mit, aber auch hier muss man natürlich schauen, kommen sehr, sehr viele technologische Änderungen, auch Herausforderungen, wie man denn auch denn sicher die Kundendaten in die neue Technologie halt integriert und so weiter. Und hier gibt es dann schon einige Bereiche, wo man sagt, okay, dann macht es Sinn, doch mehr wirklich mal neu zu bauen, weil man damit am Ende des Tages einfach schneller ist, ja.

Joel Kaczmarek: Till nickt bedächtig, also scheint ihr da wieder Einheit hergestellt zu haben. Und was mir auch noch so als Überlegung kam, ich bin ja auch so Design Thinking ausgebildet und da hieß es ja immer Fail Early and Fail Often oder in eurer Tech-Welt heißt es gerne mal Fail Fast, also als Kultur. Wie weit ist denn das eigentlich überhaupt noch kompatibel, wenn ich jetzt so eine wirklich groß angelegte Transformation baue?

Till Reiter: Ich stehe mittlerweile auf persönlichem Kriegsfuß mit Fail Fast. In irgendeinem Podcast hat mal einer gesagt, es gibt einfach ein paar Akronyme, die haben sich festgesetzt, ohne dass die Leute das kritisch hinterfragen. Fail Fast klingt einfach gut. Ich weiß nicht, ob viele Leute sagen würden, Fail Quickly ist unser Mantra. Ich weiß auch, dass mittlerweile Companies, Facebook war ganz prominent bei Fail Fast, das auch mittlerweile schon gar nicht mehr als eins ihrer Prinzipien haben. Learn and adapt, da stimme ich dir zu, Joel. Das ist ja auch so dieser Design-Thinking-Ansatz. Aber ohne Plan in eine Transformation reinzugehen mit dem Ansatz, wir fliegen hier wahrscheinlich auf die Schnauze, macht auf jeden Fall überhaupt keinen Sinn. Man sollte schon von vornherein versuchen, so viele Blocker, Roadblocks, Risiken etc. abzufangen und dann natürlich während der Transformation zu adaptieren, wenn man sieht, das läuft jetzt anders als gedacht.

Björn Wagner: Hier ist vielleicht nochmal, gerade im Kontext vom Transformed auch nochmal, die Idee von Product Discovery ist ja schon, dass man möglichst günstig Sachen validiert, also dass ich nicht sage, ich baue jetzt das Feature komplett in der vollen Komplexität im Code, sondern dass man halt möglichst früh in kleinen Schritten mit Prototypen, angefangen von irgendwie Klick-Prototypen bis dann vielleicht zu ersten auch Prototypen im Code, die ein sehr kleines Teil abdecken, dass man möglichst früh lernt, was funktioniert, was funktioniert nicht, ohne halt schon die gesamte Lösung zu bauen und dass man quasi das Risiko dadurch eigentlich minimiert. Also es gibt quasi, das ist ja das Hauptthema von Project Discovery, Die Hauptrisiken, können wir das bauen? Das ist so das Thema Feasibility, erzeugt das Wert für den Kunden und ist auch profitabel für die Firma. Das ist so das Thema Value. Kann ich es in einer Art und Weise bauen, dass die Nutzer das halt auch quasi verstehen und auch gerne nutzen am Ende und wiederkommen? Und dann der letzte Punkt, Viability, wie gesagt, ist das halt aus Business-Sicht halt auch tragbar. Auch hier wieder, das ist ein Riesenthema bei AI. In SaaS und Cloud war eigentlich immer die Marge so hoch, dass man eigentlich sehr, sehr viel bauen konnte und Viability nicht so das große Thema war. Aber wenn man sich jetzt anschaut, Wie auch, ich glaube jetzt wurde gerade announced, dass ChatGPT hat ja jetzt eine neue Modellgeneration und da gehen ja jetzt auch plötzlich dann die Preise für Entwickler von 20 Dollar auf 200 Dollar hoch. Und dann ist natürlich das Viability dann schon ein Thema. Egal wie gut die Technologie ist, aber erzeugt sie auch genug Wert, dass es sich für mich lohnt, das halt zu nutzen? Und das sind halt Fragen, die sollte man möglichst früh beantworten. Nicht, dass man irgendwie zwei Jahre entwickelt und dann hat man die perfekte Lösung, aber man merkt am Ende des Tages, oh, aber vom Preis kriegen wir quasi den Wert gar nicht materialisiert am Ende des Tages.

Joel Kaczmarek: Welche Rolle spielen denn für euch eigentlich Metriken, wenn ihr auf sowas schaut, auf Change?

Till Reiter: Meiner Meinung nach wichtig, darf aber auch wieder nicht überbewertet werden. Denn vor allem sowas wie kulturellen Change etc. lässt sich sehr schwer verändern. oft oder nur in ähnliche Metriken quantifizieren. Deswegen glaube ich, eine absolute Fixierung auf Metriken macht keinen Sinn und sollte mit Bedarf genutzt und interpretiert werden. Mit Vorsicht meine ich.

Björn Wagner: Also für mich ist so Metriken immer, ist so der magische Moment, wenn man in so vielen Diskussionen drin ist, man holt sich, was sind die Probleme, die man lösen möchte, was ist das Ziel eigentlich, was man erreichen müsste und das sind meistens Diskussionen, da sind die Leute sich relativ schnell einig, aber wenn man dann fragt, okay, wie messen wir denn jetzt den Erfolg? Dann kommt man plötzlich in so ein Gedankenspiel rein, wo dann die spannenden Diskussionen stattfinden, wo die Leute sagen, Moment, aber ich habe das eigentlich ganz anders verstanden. Ich würde das ja so und so messen. Und das heißt, Metriken können, also allein die Diskussion kann irgendwie helfen, ein gemeinsames Verständnis davon zu erzeugen, wo wollen wir eigentlich hin? Weil auch über diese Transformation, über die wir hier sprechen, es ist ja wahnsinnig viel Aufwand und wahnsinnig, wahnsinnig teuer. Das heißt, und wie stellen wir denn sicher am Ende des Tages, dass das, was wir machen, dass das auch erfolgreich ist? Und man sagt ja auch sehr häufig, auch in Transformationen, eigentlich dasselbe wie in der Produktentwicklung, sagt man, ich nehme jetzt halt nicht 100 Leute, 1000 Leute und sage, hey, von heute auf morgen, so arbeitet ihr jetzt, sondern man sagt halt, okay, lasst uns mal mit einem kleinen Team, was irgendwie schon ziemlich genau passt, vielleicht erstmal einen Piloten machen, lasst uns doch mal ein halbes Jahr probieren, funktioniert das? Wenn man einen Piloten macht, dann muss man natürlich auch ein Kriterium haben, wonach man den evaluieren kann, ne? Und ich glaube, in dem Zusammenhang ist es schon sehr, sehr wichtig, weil es gibt so ein Verständnis, weil sonst transformiert man halt des Transformationszwecks und das soll am Ende nicht das Ziel sein. Da interpretieren die Leute wieder sehr, sehr verschiedene Sachen rein, was wir eigentlich erreichen wollen und das ist dann in der Regel schwierig. Also Metriken ja, quantitativ irgendwie das messbar zu machen, aber für mich ist auch selbst in der Diskussion am Anfang, um so das Ziel abzustecken, immer sehr, sehr spannend, weil dann sieht man, wie einig man sich eigentlich wirklich ist, was man erreichen möchte.

Till Reiter: Mein alter Chef hat ja immer Peter Drucker zitiert, mindestens eine Quote pro Tag. What's measured improves, ist so einer dieser Zitate gewesen. Und ich glaube, das bildet ganz gut ab, was Björn jetzt auch meint. Also um es zu messen, musst du eben die Konversation und die Diskussion führen, was willst du eigentlich messen? Und dann, wenn du das auf dem Radar hast, kannst du hier auch Verbesserungen herbeiführen.

Joel Kaczmarek: Ich habe auch gerade gedacht, ich glaube dieses Gespräch über, das macht schon ganz viele Dinge auf, selbst wenn die Metrik am Ende in der Messung gar nicht so wichtig ist, aber sich eigentlich mal hinterfragt zu haben, worauf optimiere ich und wie könnte das aussehen und wie könnte ich das messen, alleine das Gespräch darüber macht wahrscheinlich schon ganz viel auf. und jetzt überlege ich so, habt ihr beide denn mal ein Gefühl dafür gewonnen? wann Change eigentlich auch überfordert? Also ab welchem Punkt ist es eigentlich so, dass es die Produktivität senkt, die Teams eher ausbrennt und wo es dann heißt, okay, ich brauche da wieder eine Balance. Also wo ist der Punkt und wie balanciert ihr dann?

Björn Wagner: Also ich glaube Für mich ist immer ganz wichtig, man kann sehr viele Bücher lesen, man kann die besten Konzepte, Prozesse haben. Am Ende des Tages geht es halt immer um die Menschen, die Leute im Team, Vertrauen, wie arbeitet man zusammen, wo vertraut man sich, was sind die Werken des einen, des anderen und wie kann man eigentlich ein starkes Team formen. Also egal, welche Optimierung man jetzt erreichen möchte, das darf man halt nicht vergessen. Und da sind halt, da ist so im Kern wichtig, die Beziehung halt den Leuten zu der Manager, aber auch die Beziehung von den Leuten im Team. Also ich kann jetzt nicht anfangen und nur weil ich alle halbe Jahre irgendwie den neuesten Blogartikel eine Verbesserung gemacht hat, irgendwie die ganze Organisation von links auf rechts ziehen. Und gerade wenn man halt schnell wächst, dann gibt es natürlich bei Design sehr, sehr viele Änderungen und sehr, sehr viele Möglichkeiten, Neue Leute, die man kennenlernen muss, mit denen man zusammenarbeiten muss. Und hier muss man, glaube ich, schon ein Gefühl dafür haben, wie stabil sind die Teams und den Leuten genug Raum geben, halt auch gegenseitig Vertrauen aufzubauen und dann halt gemeinsam an irgendwie Problemen zu arbeiten. Und da gibt es dann halt schon so eine, sage ich mal, untere Grenze, wo man halt aufpasst, Jetzt nicht zweimal im Jahr, nur weil man gerade wieder die nächste Optimierung machen möchte, quasi dieses Vertrauen wieder zu resetten und zu zerstören am Ende des Tages. Und das ist halt schon wichtig. Das heißt, man muss sich quasi immer fragen, da kommen wir wieder auch zu dem Thema Metriken zurück, was wir gerade hatten. Was sind denn die Kosten des Changes? ist die Organisation gerade an der Stelle, dass wir das machen können? oder haben wir gerade so viel geändert, dass die Organisation erstmal durchatmen muss und irgendwie Stabilität braucht, um erfolgreich zu sein, weil sonst geht die Transformation vielleicht auch eher nach hinten los, dass man halt dann die gewünschten Ziele gar nicht erreichen kann am Ende.

Till Reiter: Ja, ich glaube, da kann ich auch nicht mehr viel hinzufügen, stimme ich dir voll zu. Wir alle wissen, dass Konstanter Change, das neu normal ist sozusagen, aber trotzdem, wie Björn sagt, überlegt und in richtigen Dosen und Zyklen, ohne dass du die Organisation und die Mitarbeiter damit überfracht hast.

Björn Wagner: Und ein gutes, also wie kann man das in der Praxis umsetzen? Da gibt es ja jede Menge so Mitarbeiter-Feedback-Tooling, wo man halt so Leadership-Trust, Engagement, da gibt es ziemlich gute SaaS-Lösungen. Die Guten machen das einmal im Monat, stellen den Leuten Fragen und dann kriegt man da sehr gutes Bild eigentlich über die Organisation, wo die genau stehen, wo die Probleme sind. Und dann kriegt man auch so ein bisschen datengetrieben, quantitativ einen Einblick, gerade in größere Organisationen, ob denn jetzt gerade eine gute Zeit ist, die nächste Veränderung zu machen.

Joel Kaczmarek: Gut, also heute war uns ja wichtig, mal in einer knackigen halben Stunde so die wesentlichen Fragen in Sachen Change zusammenzufassen. Und ich fasse das nochmal zusammen, was wir da für Fragen hatten. Nämlich als erstes haben wir diskutiert, welche Bücher sollte ich eigentlich dazu gelesen haben. Dann sollte Change von oben oder von unten kommen. Brauche ich dafür eigentlich neue Leute? Sind Frameworks wie zum Beispiel OKRs eigentlich überbewertet, wenn es darum geht, die Transformation voranzubringen? Kann eine Organisation überhaupt erfolgreich sein, wenn sie keine Empowered Teams hat? Wie gehe ich mit Widerstand um, wenn mein Team dagegen rebelliert? Wie ist es mit Legacy-Systemen? Also sollte ich die neu schreiben oder Stück für Stück verbessern? Ist dieser Fail-Fast-Ansatz eigentlich kompatibel, wenn ich eine große Transformation mache? Welche Rolle spielen Metriken und wie viel Change ist eigentlich zu viel? So, sollten wir heute noch Fragen vergessen haben, ihr Lieben da draußen, dann kommentiert uns doch gerne mal fleißig oder schreibt uns Nachrichten. Dann kann man ja auch nochmal über ein Addendum nachdenken. Aber für den Moment glaube ich, schöner runder Ritt und ihr beiden, dann drücke ich euch mal die Daumen. Also vielen, vielen Dank. erstmal und ich habe ja schon gelernt, Change ist bei euch jetzt sozusagen Alltag und nach der Reorg ist vor der Reorg, dann dafür viel Kraft und ansonsten erstmal noch eine schöne Weihnachtszeit.

Till Reiter: So ist es. Bis bald Joel. Danke.

Björn Wagner: Danke dir. Ciao, ciao.