Von den bisherigen Interviews bei Mindlytics haben insbesondere die Beiträge zum Thema Führung und (agile) Organisation („getting things done“) viele Leser erreicht (u. a. das Interview mit Matthias von Amazon). In diesem Interview wollen wir an diesen Themen anknüpfen. Konkret geht es in diesem Beitrag um das Thema Organisationsaufbau aus der Tech Sicht. Wir sprechen hierzu mit Michael Alers, der langjähriger CTO in einem Teilbereich von Axel Springer war und aktuell in der Rolle des Director of Platform Engineering bei Smava tätig ist. Wir sprechen mit ihm unter anderem über die folgenden Themen:
- Was ein CEO im Jahr 2020 über das Thema Softwareentwicklung wissen muss.
- Warum eine effiziente Governance-Struktur wichtig ist.
- Warum „so sein wie Amazon“ in der Regel nicht klappt.
- In welche Fallstricke viele Personen laufen, wenn sie ihre Organisation agiler gestalten wollen.
- Warum ein Team mehr als eine Arbeitsgruppe ist.
- Wie man agile Organisationen skaliert und welche Modelle es gibt.
- Warum Michael ein Fan von LESS ist und warum es aus seiner Sicht viele Vorteile bringt.
Viel Spaß beim Lesen.
Christian/Rene: Was muss ein CEO im Jahr 2020 aus Deiner Sicht über das Thema Softwarearchitektur und Entwicklung wissen?
Michael: Ich denke, jeder CEO, der an der Spitze einer digitalen Unternehmung steht, sollte ein zumindest grobes Wissen über die Entwicklung von Software- und Systemarchitekturen haben. Natürlich muss er hier kein Experte sein. Ich erwarte aber, dass er eine gewisse technische Neugier an den Tag legt. Die Digitalisierung wird eher früher als später für jedes Unternehmen überlebenswichtig. Umschreiben wir es so: Von einem Arzt erwarte ich, dass er eine Grippe von einer Lungenentzündung unterscheiden kann. Wenn das stimmt, dann muss auch ein CEO im Jahr 2020 mit den Grundlagen im Digitalgeschäft vertraut sein, um richtige Entscheidungen treffen zu können. Die Technik ist da einfach eine ganz wichtige Komponente, ob es einem gefällt oder nicht. Man darf und kann diesbezüglich heute nicht mehr komplett blind agieren.
Christian/Rene: Was rätst du tendenziell betriebswirtschaftlich orientierten Entscheidern, wie sie sich diesem Thema nähern sollen?
Michael: Der CEO sollte sich mit anderen CEOs zu diesem Thema austauschen und Vergleiche anstellen. Wo geht die Reise grundsätzlich hin? Wie viel geben andere Unternehmen heute für IT aus und wie viele Entwickler beschäftigen sie? Was sind Best Practices? Wie arbeiten andere Unternehmen auf der operativen Ebene? Dies sind wichtige Grundlagen, da sich gerade die Arbeitsweise von Digitalunternehmen deutlich von der Arbeitsweise traditioneller Unternehmen unterscheidet. Letztendlich sollte er sich natürlich auch einen erfahrenen CTO einstellen, auf den er sich einerseits verlassen, von dem er andererseits aber auch lernen kann.
Christian/Rene: Worauf kommt es bei der Organisation des Tech-Bereichs vor diesem Hintergrund vor allem an?
Michael: Es ist heutzutage sehr wichtig, eine effiziente Governance-Struktur aufzubauen. Da denke ich vor allem an die Produkt- und Tech-Organisation und die dort verankerten Rollen und Strukturen. Es gibt allerdings keinen One-Size-Fits-All-Ansatz. Du musst in jedem Unternehmen hinterfragen, was für die jeweiligen Business-Ziele mit den bestehenden Mitarbeitern am besten funktioniert. Manche Unternehmen setzen z. B. auf People Leader, die mit dezidierten Tech-Spezialisten zusammenarbeiten. Andere Unternehmen kombinieren beide Rollen in einer Funktion. Das sind dann sogenannte Tech-Leads mit disziplinarischer Verantwortung. Dann ist immer eine Frage: Wie viele Agile-Coaches brauchst du? Auf welchem Level und auf welchem Reifegrad? Und wie crossfunktional stellst du die Teams auf? Wie groß sollen sie sein? Mein Favorit ist hier die „fraktale“ Organisation, in der sehr kleine, unabhängige und autonom arbeitende Teams organisiert sind. Diese arbeiten eigenständig an ihren Zielen und sämtliche für die Zielerreichung notwendigen Rollen sind darin besetzt. Das sind quasi kleine Business Units im Gesamtunternehmen, im besten Fall mit eigenem Budget. Es gibt natürlich auch viele Best Practices von den großen Firmen wie Facebook, Google, Spotify und Amazon, an denen man sich orientieren kann. Ein bekanntes Beispiel sind die „Two-Pizza-Teams“ von Amazon: Ein Team sollte nur so groß sein, dass sie von zwei amerikanischen Pizzen satt werden.
Christian/Rene: Lassen sich diese Regeln pauschal auf den deutschen E-Commerce-Player oder Händler übertragen?
Michael: Es ist wichtig, sich immer wieder vor Augen zu führen, dass Amazon & Co. reine Tech Companies mit einer entsprechenden DNA sind. Gerade bei den organisatorischen Gestaltungsprinzipien, also im Hinblick auf die Rolle und Arbeitsweise des Tech-Bereichs, bestehen hier massive Unterschiede zu „normalen“ Unternehmen in Deutschland. Diese Arbeitsweise funktioniert nur mit den richtigen Leuten und der richtigen Kultur, erst dann wird aus den einzelnen Teilen ein Motor. Die Abschaffung des „Siezens“ oder ein CEO, der plötzlich im Hoodie herumläuft, ist in keiner Weise digital fortschrittlich.
Insofern sollte man die Best Practice-Beispiele immer gründlich hinterfragen und sich selbst die Frage stellen, wer bin ich als Unternehmen eigentlich und wohin möchte ich? Wenn du so sein willst wie Amazon, dann musst du halt jedes Jahr viel in Tech investieren und dich weniger auf die Dividendenausschüttung konzentrieren. Man kann sehr viel von den großen Unternehmen lernen, aber sollte nicht 1:1 kopieren. Hier gilt es, den richtigen Weg für das eigene Unternehmen zu identifizieren und diesen zu gehen. Zalando, Otto mit AboutYou und Outfittery sind als deutsche E-Commerce-Player diesbezüglich ja z. B. auf einem guten Weg.
Christian/Rene: Was sind die typischen Fallstricke, über die man beim Aufbau einer solchen Organisation stolpern kann?
Michael: Der größte und häufigste Fehler besteht darin, die falschen Leute auf bestimmte Positionen zu setzen und die Teams falsch zusammenzustellen. Wenn du viele Junior-Leute hast und einen Junior auf die Lead-Position setzt, dann geht es häufig schief. Du musst die richtige Balance zwischen Seniorität und Juniorität in der Belegschaft haben. Diese Balance ist auch wichtig im Hinblick auf das Verhältnis zwischen externen und internen Mitarbeitern. Wie viele Freelancer hast du an Bord? Hast du ggf. wichtige Bereiche zu IT-Dienstleistern ausgelagert? Grundsätzlich halte ich es für keine gute Idee, Kerntechnologien von Service-Providern ohne eigenes Inhouse-Know-how zu haben. Natürlich musst du auch dafür sorgen, dass die Teams oder crossfunktionalen Teams, je nachdem wie du sie strukturierst, auch wirklich zu Teams werden. Die meisten Teams, die ich sehe, sind eher Arbeitsgruppen, bestehend aus Individuen. Das ist natürlich nicht Sinn der Sache. Das Coaching der Teams kommt häufig zu kurz, obwohl es so wichtig ist. Ich bin fest davon überzeugt, dass ein echtes Team sehr viel mehr Outcome als eine Arbeitsgruppe von Individuen liefern kann. Zudem ist es auch wichtig, dass die Teams auf Teamebene gut zusammenarbeiten. Die sogenannte „Collaboration“ bekommt häufig zu wenig Beachtung. Das gilt auch über Abteilungen hinweg. Diese müssen ebenfalls zusammenarbeiten und nicht gegeneinander. Hier gilt es, das sogenannte „Silodenken“ aufzulösen.
Christian/Rene: Wie coache ich ein Team richtig?
Michael: Zunächst musst Du definieren, was ein Team genau ist. Ich vergleiche Teams immer gerne mit Sportteams. Da sind nämlich einige Sachen gewährleistet. Ein Team hat klare gemeinsame Ziele und eine Vorstellung über die Zukunft. Wie im Fußball müssen die Teammitglieder nicht zwingend beste Freunde sein, allerdings müssen sie sich vertrauen. Jeder muss seine Meinung sagen dürfen und keine Angst haben, dass er anschließend Ärger bekommt. Das ist extrem wichtig und eine grundsätzliche Kulturfrage. Außerdem ist es wichtig, dass Teammitglieder sich gegenseitig „challengen“. Man darf nicht nur auf sich selbst achten: Hey, mache ich jetzt gerade das Richtige? Bin ich gerade wertschöpfend unterwegs? Nein, ich muss es auch für die anderen übernehmen, das ist wie im Fußball. Der Verteidiger achtet auch auf den Mittelfeldspieler und umgekehrt. Hier gilt es natürlich, die Fehlerkultur im Auge zu behalten. Fehler dürfen gemacht werden. Allerdings muss darüber gesprochen und reflektiert werden und im Idealfall passiert ein bestimmter Fehler nur einmal. Das gehört für mich zum Team dazu. Diese Kultur leben die Chefs aber häufig nicht vor, das ist dann ein riesiges Problem. Aber wenn du ein richtiges Team hast, bringt es mehr Outcome als die Summe der einzelnen Teammitglieder bringen würde.
Christian/Rene: Wie baut man eine solche Kultur auf?
Michael: Die Kultur ist ja immer ein Spiegelbild von einem System. Diese zeigt sich in der Stimmung der Mitarbeiter, deren Motivation, ob sie morgens gerne zu ihrem Arbeitgeber fahren oder eher widerwillig, wird viel gelacht oder eher gar nicht.
Meiner Erfahrung nach wird eine Kultur nur top-down beeinflusst. Wenn man neue und ggf. agile Arbeitsstrukturen einführt, müssen diese vom Top-Management verstanden werden. Es muss die dahinterstehenden agilen Werte und Prinzipien verstehen. Und ich gehe jetzt noch einen Schritt weiter: Es muss sie nicht nur verstehen, sondern sie in sich tragen und vorleben. Und genau daran scheitert es meistens. Viele sagen sich einfach: Okay, ich habe jetzt also eine agile Beratung mitgemacht und mir das erklären lassen. Nein, das reicht nicht! Wenn du die Werte nur verstehst, aber nicht lebst, wird es immer zu Problemen kommen. Es fängt immer oben an, nur dann hast du eine Chance, solche Ansätze weiter auszurollen. Ich bin kein Fan von Bottom-up-Ansätzen an dieser Stelle. Die funktionieren meistens nicht. Du kannst nicht auf Teamebene agil arbeiten, wenn die Ebenen darüber eher gegenteilig unterwegs sind.
Damit ein Team beispielsweise motiviert und effizient arbeiten kann, benötigt es eine gewisse Autonomie. Diese wiederum kann es nur bekommen, wenn ihm vom Topmanagement Vertrauen entgegengebracht wird.
Christian/Rene: Wenn ein Unternehmen richtig gestartet ist und die Ansätze von der Führung mitgetragen werden, wie skaliere ich dann eine moderne Produktentwicklung von einem Team zu mehreren?
Michael: Es gibt verschiedene skalierende, agile Modelle wie z. B. LESS oder SAFE. Im Prinzip geht es immer um die gleichen Fragen: Wie arbeiten die Teams zusammen? Hat jedes Team einen eigenen PO oder gibt es einen PO für mehrere Teams? Und so weiter. Ich persönlich mag den LESS-Gedanken, wonach die POs für mehrere Teams zuständig sind, die auf ein großes Backlog zugreifen. In diesem Fall gibt es wenige POs, wenn nicht sogar nur einen. Das ist ein sehr schlankes Modell.
Christian/Rene: Warum findest du dieses Modell gut?
Michael: Dem PO steht – wenn er mehrere Teams hat – weniger Zeit für jedes Team zur Verfügung. Das hört sich zunächst schlecht an. Allerdings müssen in diesem Fall die Teammitglieder bestimmte Epics oder Stories mit den Stakeholdern klären, wenn sie z. B. noch unklar sind oder es zu Änderungen kommt. Die Teams sind dadurch gezwungen, Dinge für sich zu klären und auch mitzuentscheiden. Der PO gibt die grobe Richtung und Priorisierung vor, die Teams arbeiten es gemeinsam mit den Stakeholdern aus. Das hat den großen Vorteil, dass ein Entwickler den Stakeholder deutlich besser versteht und welchen Wert und Sinn das Vorhaben für das Unternehmen hat. Das ist aus meiner Sicht der große Vorteil. Wenn ein PO als Proxy zwischen Team und Stakeholder sitzt, gelangt das „Why“ mitunter gar nicht ins Team. Und dann hast du den Effekt, dass die Teammitglieder eigentlich nur die Stories herunterschrubben und nicht genau wissen, warum sie die Dinge eigentlich umsetzen. Deswegen präferiere ich dieses Modell.
Christian/Rene: Lass uns diese Themen gerne in einem folgenden Interview vertiefen.
Michael: Klar, lass uns das gerne machen!
In einem weiteren Interview werden wir mit Michael besprechen, wie man auf der technisch organisatorischen Seite richtig skaliert. Im Kern wird es dort um das Thema gehen, was Teams motiviert, wie man sie skaliert und warum „You build it, you run it, you own it“ so wichtig ist. Einfach meinem Profil folgen, dann verpasst ihr kein Interview.
