Erfolgreich Vertikalisieren (Teil 3) - Digitalisierung

In den ersten beiden Artikeln zur Vertikalisierung Teil 1 und Teil 2 haben wir uns angeschaut, wie sich IT organisatorisch effizient skalieren lässt. Manchen Unternehmen hilft dieser Ansatz bereits, um ihre organisatorischen Skalierungsschmerzen zu lindern: Sie können so zumindest in der IT ausreichend schnell werden.

Aber häufig ist die schnelle Umsetzung in der IT nur ein Teil der Skalierungsschmerzen eines Unternehmens. In der klassischen Organisationsform wird an anderer Stelle entschieden was und manchmal sogar wie die IT etwas baut. Wenn diese Prozesse langsam oder die resultierenden Entscheidungen häufig nicht gut sind, ist nur wenig gewonnen. Wir hätten dann eine schnelle IT, die aber nicht die richtigen Dinge baut. Vertikalisierung bietet auch für die Was-Entscheidungen eine wichtige Option, diese Prozesse zu verbessern - allein schon durch starke Beschleunigung. Das sichert zwar noch nicht, dass man die wertvollsten Dinge zuerst baut, aber man kann es deutlich wahrscheinlicher machen.

Bei der Weiterentwicklung der digitalen Seite eines Unternehmens orientiere ich mich gerne am 3-Horizonte-Modell von McKinsey. In diesem dritten Teil der Blog-Reihe erkläre ich, warum ich die Vertikalisierung für Horizont 1 und 2 (aktuelles Geschäftsmodell und Integration von Erweiterungen des Geschäftsmodells) für einen hervorragenden Weg halte, um die Geschwindigkeit und die Qualität von Entscheidungen in diesen beiden Horizonten zu beschleunigen.

(Wie sich Vertikalisierung zu Horizont 3 verhält ist Stoff für einen weiteren Artikel.)

Hierarchie

Ein kurzer Ausflug in die Arbeitsstruktur der meisten Unternehmen:

Wenn ein Unternehmen eine relativ stabiles Marktumfeld hat, bietet eine Hierarchie viele Vorteile. Sie ist weniger von den Personen abhängig, weil in der Hierarchiestruktur die Arbeitsorganisation (Abteilungen), Schwerpunkte (Größe von Abteilungen) und benötigten Fähigkeiten (Tätigkeiten in Abteilungen) konserviert sind. Außerdem ist eine Steuerung durch wenige zentrale Personen in der Führung einfacher möglich als ohne Hierarchie.

Diese Stabilisierung von Fähigkeiten eines Unternehmens und seiner Steuerbarkeit ist gleichzeitig der Grund, warum hierarchische Organisationsformen nicht gut geeignet sind, um sehr schnell viele Entscheidungen zu treffen - insbesondere über die eigene Struktur. Und je steuerungsfreudiger (im Sinne des Wie) ein Unternehmen in den höheren Hierarchiestufen ist, desto mehr werden diese Hierarchiestufen zu Entscheidungszentren (Stichwort "Micromanagement"). Entscheidungen werden in solchen Unternehmen häufig zu den höheren Ebenen verschoben, bzw. die höheren Ebenen wollen sich mehr bei Entscheidungen tieferer Ebenen engagieren und lassen sich detailliert informieren. Als Reaktion darauf besteht keine hohe Entscheidungsfreudigkeit in den tieferen Hierachieebenen. Das heißt, Entscheidungen brauchen sehr lange und werden weiter entfernt von denjenigen getroffen, die den Entscheidungsbedarf und -kontext vor sich sehen.

In einigen Unternehmen hat der Entscheidungsdruck, also der Bedarf an Geschwindigkeit, mit der Entscheidungen getroffen werden müssen, enorm zugenommen. Besonders hoch ist der Entscheidungsdruck häufig in den Teilen eines Unternehmens, die direkten Kontakt mit dem Markt (Kund:innen) haben. Denn hier muss ein Unternehmen am dynamischsten reagieren. Wird ein Unternehmen hier zu langsam bzw. wird die Dynamik des Marktes zu groß, kann es sich seinem Markt nicht mehr gut anpassen. Da sich kein Hardwareprodukt so schnell ändern lässt wie Software, sind digitale Schnittstellen eines Unternehmens, häufig die mit dem höchsten Bedarf an Entscheidungen in kurzer Zeit.

Darum ist der E-Commerce heutzutage häufig ein Unternehmensbereich mit extremen Anforderungen an die Geschwindigkeit von Entscheidungen.

Entscheidungen

Am schnellsten können Entscheidungen dort getroffen werden, wo sie benötigt werden. Für viele Entscheidungen des Alltags passiert das auch: Softwareentwickelnde treffen viele Entscheidungen bzgl. der Codemodellierung selbst oder in ihrem Team. Aber mir ist im Kontext von Softwareentwicklung häufig das Muster begegnet, dass viele Entscheidungen, was ein Team baut und in welcher Reihenfolge und in welcher fachlichen Qualität, nicht im Team getroffen werden können. Bis hin zu der “klassischen” Arbeitsteilung, dass jemand anderes die Software ausrollt und betreibt. In den Arbeitsteilungen um Softwareentwicklung unterscheide ich zwei Arten von Entscheidungen:

Klassische technische Entscheidungen

Typisch für IT-Abteilungen in Tech-Teams sind "technische" Entscheidungen:

• Welche Datenbank? MySQL, PostgreSQL, MongoDB, Cassandra,...
• Welche Sprache? Java, C#, Scala, Elixir...
• Welche Security-Level? OAuth2, JWT
• ...
• UND - seit einigen Jahren - : Welche Microservice-Schnitte machen wir?

Diese Entscheidungen können IT-Abteilungen häufig selbst treffen. Manchmal sogar Teams in den IT-Abteilungen. Aber da die Techniker in solchen Unternehmen keine fachliche Verantwortung tragen, sind ihre Entscheidungen von allerlei technischen Argumenten geleitet, aber nicht davon eigene Fachlichkeit "auf die Straße zu kriegen". Denn sie verantworten nur Umsetzung und (evtl.) Betrieb, entscheiden aber nicht selbst, welche Fachlichkeit sie bauen. Dementsprechend ist es als IT-Mitglied völlig natürlich, sich an erster Stelle mit technischen Schmerzen zu beschäftigen.

Die heutigen Möglichkeiten, um mit Microservices alte monolithische Systeme abzulösen, bieten die Grundlage für organisatorische Skalierung. Ohne fachliche Verantwortung eines Teams wird sich bei der Aufteilung in Services aber an bekannten (Micro-)Architekturmustern orientiert: Also an Aspekten von funktionaler Separation wie in einem Monolithen. Ein Team fragt sich in so einem Kontext bei der Arbeitsteilung nicht: "Wie erzeuge ich am effizientesten/effektivsten Mehrwert für die Gruppe meiner Nutzenden (z.B. Kund:innen)?". Stattdessen fragen sich Architekt:innen in solchen Settings häufig: “Wie kann man Redundanz vermeiden?” oder “Wie kann man etwas leistungsfähiger machen?” oder “Wie kann man die Konsistenz erhalten?”. Dabei wird aber übersehen, wie kostspielig die aus den Antworten resultierende organisatorische Kopplung zwischen Teams ausfällt.

IT-Abteilungen versuchen natürlich auch ihre Effizienz zu steigern und ahnen, dass der fachliche Schnitt wichtig ist, aber ohne die fachliche Verantwortung kommen sie über die Ansätze von Feature-Teams, "Geschäftsfähigkeiten", crossfunktionale-Teams (DevOps) u.ä. nicht hinaus. Die Technik steht natürlicherweise im Vordergrund.

Erst, wenn sie die fachliche Verantwortung haben, kann sich das ändern.

Klassische fachliche Entscheidungen

Die klassischen Stakeholder der IT befinden sich häufig in anderen Organisationsstrukturen eines Unternehmens. Z.B. kann es in einer Geschäftsleitung einen CTO für den IT-Teil in der Unternehmensstruktur geben und einen CMO für den Marketing-Teil, der die Stakeholder beheimatet. Die Stakeholder entscheiden, welche Features und mit welcher Priorisierung von der IT gebaut werden sollen. Manchmal entscheiden sie sogar über das Wie. Stakeholder arbeiten in so einem Setting nicht direkt in einem eigenen spezifischen Techteam mit. Und sie wetteifern außerdem mit anderen Stakeholdern um Priorisierung bei Auswahlprozessen für Roadmaps/Portfolioboards. Dementsprechend testen sie ihre Feature-Ideen nicht iterativ per MVP bzw. MMP, sondern planen sie als Hochglanzvariante mit aufwändigen Präsentationen für den Wettbewerb mit den anderen Stakeholdern. Und weil bei so viel Aufwand der Nutzen nicht ausbleiben darf, wird dieser später entweder gar nicht geprüft oder im Negativfall nicht weiter beachtet.

Unter diesen Umständen gewinnt Entwicklungseffizienz keine (oder die falsche) Aufmerksamkeit, weil Planung und Organisation der Teams so viel zeitliche Reibung verursachen, dass der Entwicklungsanteil innerhalb der Teams im Gegensatz zu dem durch die Arbeitsorganisation verursachten Zeitverlust vernachlässigbar ist. Wenn dann der Fehlschuss passiert, die wahrgenommene Ineffizienz der IT hätte etwas mit der Technik zu tun, werden unter solchen Umständen gerne neue oder mehr Spezialist:innen und neue oder mehr Rollen eingeführt, die alle helfen sollen die Entwicklungseffizienz zu verbessern. In Wirklichkeit wird nur alles weiter verlangsamt.

Langsamkeit

Das heißt, so lange nicht die beiden Verantwortlichkeiten (Technik und Fachlichkeit) bei einem Team liegen, kann es lokal keine schnellen fachliche Entscheidungen treffen.

Hinzu kommt noch der Bias zur technischen Verantwortung: Wenn ein Team die fachliche Verantwortung nicht hat, könnte es zwar die fachlichen Ziele kennen und verstehen, aber sie sind am Ende ein Problem von jemand anderem. So ein Team ist inhaltlich auf technische Verantwortung und Tätigkeit fokussiert und das führt zu einer Verschiebung der Gewichtung von Kriterien, wenn Entscheidungen zu fällen sind. So ein Team investiert völlig rational viel in letzte Quäntchen an Geschwindigkeit, Sicherheit, technische Skalierbarkeit, Konsistenz, Resilienz in der Technik, auch wenn diese Quäntchen im konkreten Fall alle zukünftige Softwareentwicklung nur weiter verlangsamen und keinen unternehmerischen Mehrwert mehr bieten: E-Commerce-Software muss z.B. nicht so fehlerfrei sein, wie die Software eines Autopiloten für Autos.

Liegt die fachliche Verantwortung nicht bei den Teams, werden zur fachlichen Entscheidungsfindung technische Implikationen immer über viele Banden der Hierarchie gespielt und fachliche in die andere Richtung. Insbesondere ist auf diese Weise ein IT-Team ein Spielball von miteinander konkurrierenden Stakeholder-Interessen. Es wird im Falle von klassischen Projektansätzen niemals stabil und fachlich nicht erfahren werden, weil Teams dauernd mit nicht nachvollziehbaren Entscheidungen konfrontiert werden.

Postbürokratie

Besetzt ein Unternehmen eine Nische mit wenig Marktdruck, ist die Geschwindigkeit und Qualität der Entscheidungen für den digitalen Bereich evtl. nicht besonders relevant. Aber wenn ein Unternehmen auf der Ebene digitaler Services des Geschäftsmodells in einem harten Wettbewerb zu Konkurrent:innen steht, ist die Notwendigkeit schnell wettbewerbsrelevante Features zu entwickeln ggfs. so wichtig, dass die o.g. klassische organisatorische Teilung von fachlicher und technischer Arbeit in einem Unternehmen das Überleben gefährdet.

In Unternehmensteilen, die solch eine erhöhte Geschwindigkeit benötigen, überwiegen die Vorteile vieler Hierarchiestufen und fachlicher und technischer Separation nicht mehr die o.g. Nachteile. Insbesondere ein iterativer Anpassungsprozess von Software (Build-Measure-Learn) wird erst möglich, wenn die fachlichen Expert:innen direkt mit Teams zusammen sitzen und letztere (bzw. die Product-Owner) ihr Backlog selbst verantworten.

Auch datengetriebenes Optimieren ("Herumprobieren") von Software wird erst möglich, wenn Teams über ihre Backlogs selbst bestimmen.

Vertikalisierung

Mit einer Vertikalisierung können Teams den wesentlichen Teil der fachlichen Verantwortung übernehmen und somit ihre Software wie ein Produkt managen, dass sie verantworten und weiterentwickeln. Sie können also ihr Nutzendenproblem wirklich aus Unternehmenssicht “ownen” und werden somit verantwortlich. Damit fällen sie alle Entscheidungen bzgl. der Weiterentwicklung ihrer Vertikale selbst.

Dazu müssen die fachliche Expert:innen nah an oder in das Team rücken und die jeweils für das Produkt notwendigen Kompetenzen zusammengezogen werden.

• Auf der fachlichen Seite muss ein Product-Owner vorhanden sein, der unternehmerisch denkt und anhand von Kosten und Nutzen (Mehrwert für das Unternehmen) abwägen kann.
• Insbesondere liegt hier dann auch die Verantwortung für nicht-funktionale Anforderungen (NFAs) an Qualitäten wie Verfügbarkeit, Geschwindigkeit, Sicherheit.
• Je nach Größe des Produkts und Komplexität des fachlichen Feldes sind weitere fachliche Expert:innen Teil des Teams
• Auf der technischen Seite muss ausreichend Expertise vorhanden sein, um ein nachhaltiges Softwareprodukt langfristig weiter zu entwickeln und zu betreiben.

Um die Verantwortungsübernahme strukturell zu gewährleisten, müssen Vorgesetzte in der Regel viel stärker als bisher ihre Rolle im Sinne von “servant Leadership” ausbauen. Es geht nicht mehr vorwiegend um Reporting und Steuerung, sondern um Alignment und Unterstützung. Aus diesem Grund müssen idR. auch mehrstufige Hierarchien über solchen Teams in Teilen abgebaut werden, weil die Stufen deutlich weniger zu tun haben, weil der Zyklus aus Reporting und Steuerung möglichst weit reduziert werden muss. Dieser Stufenabbau ist sehr wichtig für den Wandel, denn es darf gerade nur so viel Raum bei Vorgesetzten sein, dass sie nicht wieder anfangen Reporting einzuholen und sich (steuernd) in Entscheidungen einzumischen.

Ein gutes Muster ist nach unserer Erfahrung mit solchen Strukturen einen fachlichen und einen technischen Gesamtleitenden unterhalb der Geschäftsleitung zu haben ("HeadOfTech" und "HeadOfProduct"), um teamübergreifende Themen in einer Rolle zu verankern. Deren Aufgaben sind:

• Alignment sicher zu stellen
• Vision für die Entwicklung des gesamten Geschäftsmodells
• Steuerungsaspekte außerhalb der Fachlichkeit (z.B. DSGVO, Budget)
• Enabling der Teams zu organisieren oder selbst zu leisten
• Die strukturellen (systemischen) Effekte im Auge zu behalten
• Hindernisse für die Teams zu beseitigen

Flankieren kann man diese Führung mit speziellen Stabsstellen für Enabling (Dezentralisierung von: DSGVO-Prozessen, Security, Ops), die nur eine begrenzte Zeit benötigt werden.

Ab einer bestimmten Größenstruktur (ca. 10 Teams) können diese Rollen nicht mehr von einer Person ausgefüllt werden und es ist eine fachliche Separation notwendig mit der dann (erst einmal eine) zusätzliche Hierarchiestufe notwendig werden kann. Will man ein ganzes Unternehmen vertikalisieren, liegen z.B. Separationen nach Einkauf, Verkauf, Logistik, Controlling etc. auf der Hand, die gut etablierte fachliche Schnittmuster darstellen.

Der fachliche Schnitt macht es möglich

Da bei einer Vertikalisierung schon nach fachlichen Problemclustern der Nutzenden die Organisationsstruktur gebaut wurde, haben wir bereits alles vorbereitet, um fachliche und technische Verantwortung zusammen zu legen. Ein Team ist für alle digitalen Use-Cases rund um einen Problemcluster zuständig und braucht dementsprechend "nur noch" die Fachexpert:innen ins Team zu holen und die Verantwortung für das Befüllen des Backlogs selbst zu übernehmen.

Zum Beispiel kann in einer E-Commerce-Plattform ein Team, das sich um das "Kaufproblem" der Kund:innen kümmert, permanent autark auf neue Zahlungswege (z.B. Apple-Pay), geändertes Kund:innenverhalten (z.B. "Warenkorb wird zur Merkliste") oder Abbruchverhalten (z.B. ML-Alogrithmen zur Erkennung von Abbruchwahrscheinlichkeiten) einstellen. Es kann auch experimentieren und an Bestellabbrecher:innen Erinnerungen verschicken, um sie zu motivieren den Kaufprozess doch noch zu beenden. Oder ein Team, das sich mit Suchproblemen der Kund:innen beschäftigt, kann z.B. mit visuellen Navigationen (Bilder statt Begriffe) experimentieren. Und wenn sich dieser Lösungsansatz für das "Suchenproblem" in diesem Kontext als erfolgreich erweist und es genug für Weiterentwicklung zu tun gibt, könnte man sogar ein neues Team nur für dieses Produkt gründen.

Meine Beobachtungen bisheriger Projekte zeigen, dass man aus dieser Option der fachlichen Verantwortungsübernahme eine Pflichtübung machen muss, wenn man die Vertikalisierung stabilisieren möchte. Sonst erodiert die geschaffene IT-Organisations-Struktur wieder, weil die nicht vertikalisierte fachliche Organisation andere Verantwortungsstrukturen hat, die sich nicht an den Vertikalenteams orientiert. Ohne die fachliche Verantwortung fehlt die primäre ordnende Kraft, um die Vertikalen vor dem “Verwässern” der Kopplung zu schützen:
Es ist für Teams dann nicht mehr natürlich warum sie unter Zeitdruck nicht einfach auch Features in ihr Produkt bauen, die eigentlich zu einem anderen Usecase-Cluster eines anderen Teams gehören (“Muss halt gebaut werden, ist doch nicht so wichtig, wer…”).
Der genannte Fokus ist auf die Technik dann viel stärker und die Teams tun Dinge, die aus Unternehmenssicht “Overengeneering” sind und wegen Kopplung unnötig verlangsamen.
Ohne das Bewusstsein der Stakeholder für eine vorhandene Vertikalisierung, können ihre Vorteile nicht genutzt werden. Die Möglichkeit in den Teams extrem schnell iterativ Features zu entwickeln und fortwährend den Nutzen zu kontrollieren/validieren ist zwar da, aber wird nicht genutzt.
Und so gehen die Vorteile einer Vertikalisierung schnell wieder verloren, weil die fachlichen Zwänge nicht da sind. Ergo ziehen andere Muster in die Diskussionen der Tech-Teams ein und alte Muster von Redundanzvermeidung etc. werden wieder zu starken Attraktoren.

Das Immunsystem von Strukturen

Es liegt auf der Hand: Wenn solch eine x-funktionale, technisch-fachliche Arbeitsstruktur noch nicht etabliert ist, "drohen" viele Veränderungen. Wir rütteln an diversen Entscheidungsprämissen eines Unternehmens. Insbesondere bedroht man Arbeitsformen (Arbeitsteilung und Verantwortung).

Mit dem Immunsystem eines Unternehmens meine ich genau die Vorteile von einer gewachsenen Arbeitsteilungsstruktur in Form einer Hierarchie. Sie ist sehr widerstandsfähig gegen Veränderungsversuche, denn sie ist gewachsen und hat ihren Erfolg an vielen Stellen bewiesen. Eine starke strukturelle Veränderung wird demnach bekämpft und missverstanden werden, allein schon, weil sie einen Kontrapunkt zur bisherigen Struktur darstellt.

Wenn wir also eine Vertikalisierung inkl. der fachlichen Verantwortung wollen, wird es sehr herausfordernd: Weder haben alle technischen Spezialist:innen Können und Lust dazu, stark in die fachliche Verantwortung einzusteigen. Noch haben alle Fachexpert:innen die Fähigkeiten und das Interesse von einem großen Projektplanungsprozess auf einen iterativen Produktentwicklungsprozess nach dem Build-Measure-Learn-Muster umzusteigen. Der verlangt zwangsläufig mehr technisches und analytisches Knowhow (AB-Testing etc.) und Verantwortungsübernahme. Auch haben nicht alle bisherigen Vorgesetzten das Interesse völlig neue Aufgaben zu übernehmen, weil in der neuen Arbeitsform ihre Rolle nicht mehr existiert.

Der Weg zu so einer neuen Arbeitsform setzt also in der Regel so viele Veränderungen und Entscheidungen voraus, dass er mit vielen Risiken verbunden ist. Die Not oder die Voraussicht, dass ein Unternehmen schneller und besser bei den Entscheidungen für Horizont 1 und 2 werden muss, muss also entsprechend groß sein. Und in der Regel ist auch die Überzeugung für solche Veränderungen auf den höchsten Ebenen einer Hierarchie notwendig, denn manche Veränderungen lassen sich nur mit mächtigen Vorgesetztenentscheidungen angehen. Solch ein struktureller Organisationsumbau braucht darum auch einen langfristig starken Schutz, damit die neue Struktur lange genug trotz des Immunsystems überleben kann, um zu zeigen, was sie kann.

Wenn es gelingt

Wenn der organisatorische Umbau gelingt und es möglich ist entsprechend eigenständige Teams zu formen, ist eine noch deutlich bessere digitale Lern- und Leistungsfähigkeit eines Unternehmens erreicht. Dann können Teams nicht nur technisch unabhängig arbeiten, sondern vor allem auch autark die Fachlichkeit weiter entwickeln. Die Vorteile bei Effizienz und Effektivität dieses Vorgehens sind enorm, weil nun viel schneller iteriert und experimentiert werden kann.

Da man in diesem Fall von einer stark steuernden Führung zu einer unterstützenden, Alignment organisierenden Führung wechselt, müssen viele Themen wie Teamentwicklung, Risikomanagement (mehr Entscheidungen werden nicht von Vorgesetzten getroffen) und Organisationsentwicklung anders angegangen werden als bisher. Es muss Raum für Selbstorganisation und Orientierung über Prinzipien und Beratung, statt über Regeln und Steuerung gegeben werden.

Wir reden hier natürlich eher von Jahren des Wandels und nicht von Monaten.

Fazit

Wenn ein Unternehmen seine digitale fachliche Änderungsgeschwindigkeit in einem Bereich rechtzeitig als einen kritischen Überlebensfaktor erkennt, ist eine vertikalisierte technische und fachliche Verantwortung sehr häufig die beste Arbeitsform, um die wertvollsten Dinge am schnellsten (und damit am günstigsten) in der erforderlichen Qualität auszurollen.