Herausforderungen von stark wachsenden Unternehmen aus CTO-Perspektive

Peter Minev beschäftigte sich auf dem Digitale Leute Summit 2022 mit Hyperwachstum. Dieser Artikel basiert auf seinem Vortrag. Minev ist ein vielfach ausgezeichneter Experte, Berater und Buchautor. Derzeit arbeitet er als CTO beim Versicherungsmakler Clark.

Wie können Start-Ups mit wenigen Angestellten den Weg zu einem Unternehmen mit mehreren 100 oder 1000 Angestellten innerhalb von wenigen Jahren erfolgreich meistern? Peter Minev stellt dafür ein paar Regeln auf, die alle auf Grundlage seiner langen Erfahrung bei der Begleitung solcher Prozesse basieren.

• In diesem Text lernt ihr:
• Welche Herausforderungen in Phasen starken Wachstums bestehen
• Warum Produktbereiche statisch bleiben sollten
• Warum autonome Teams richtig konzipiert sein sollten
• Warum der Wandel von einem Top-down- zu einem Buttom-up-Ansatz wichtig ist
• Warum „Quick&Dirty“ in Wahrheit „Slow&Dirty“ ist
• Wie Teams zusammengesetzt sein sollten
• Warum das Organisationskonzept kontinuierlich weiterentwickelt werden sollte

Welche Herausforderungen in Phasen starken Wachstums bestehen

Warum brauchen Start-Ups z.B. mit fünf Mitarbeitern für kleinere Veränderungen zwei Tage, wofür größere Unternehmen plötzlich mehrere Sprints benötigen? Es wirkt so, dass mit mehr Personal das Ergebnis häufig schlechter wird und länger dauert. Das sind Probleme, die sich gerade auch aus dem sehr schnellen Wachstum eines Unternehmens ergeben können und mit dem sich Führungskräfte konfrontiert sehen.

Sowohl die Produktentwicklung als auch die Technologieentwicklung ist sehr komplex, es gibt keine einfachen Fragen und keine einfachen Antworten nach dem Schema, wenn A gewünscht ist, dann passiert B. Es ist aber sehr wichtig, dass diese eine kollaborative Partnerschaft eingehen, denn dann entsteht dadurch eine Win-Win-Beziehung.

Es gibt in der Produktentwicklung viele Frameworks, die dabei helfen, wie man die Produktentwicklung vereinfachen kann. Im Kern werden dabei technische Probleme behandelt und viele Unternehmen versuchen nun herauszufinden, wie man das strukturieren kann. Die Unsicherheit darüber führt zu vielen Schwierigkeiten beim Entwickeln durch die technischen Teams.

Peter Minev stellt anhand seiner jahrzehntelangen Erfahrung in der Begleitung solcher Prozesse 9 Regeln auf.

Warum Produktbereiche statisch bleiben sollten

Wie organisiert man die Produktbereiche, wenn ein Unternehmen wächst? Es ist wichtig, das von Anfang an richtig zu organisieren. Die Gründe:

• Es ist Produktexpertise in jedem Team erforderlich.
• Die Softwarekomponenten sollten vom gleichen Team verantwortet werden.
• Verantwortlichkeiten sollten beständig geregelt werden.

Bei häufigen Veränderungen fühlt sich niemand mehr richtig verantwortlich für eine Komponente – denn wenn alle drei Monate jemand anderes die Softwarekomponente erbt, dann lohnt sich individuell kein Investment.  Eine häufige Veränderung verhindert auch den Aufbau einer spezifischen Expertise und kostet einfach auch viel Zeit.

Als Konsequenz sollten sich Produktbereiche nur dann verändern, wenn sich das komplette Geschäftsmodell ändert (Regel 1). Ansonsten sollten die Produktbereiche statisch bleiben.

Warum autonome Teams richtig konzipiert sein sollten

Der Einsatz von autonom agierenden Teams ist ein Mantra agiler Methoden. Aber: In den frühen Phasen der Agilität wurde eine Übersimplifzierung eingeführt. Das hat dann nicht zum Erfolg geführt, weil die Situation sehr viel komplexer ist.

Das Gleiche gilt für die Idee, autonome Teams aufzubauen. Es ist nicht damit getan, einfach die Teams einfach in verschiedene Bereiche – etwa Frontend und Backend – aufzuteilen. Denn die Autonomie existiert nur dann, wenn jegliche Abhängigkeit verhindert wird. Nur dann können diese Teams den vollen Nutzen entfalten. Eine Abhängigkeit ist zum Beispiel auch schon dann vorhanden, wenn ein anderes Team die Softwarekomponente oder auch die Infrastruktur der einen Softwarekomponente begutachtet und verantwortet. Sofern nicht automatisierte Absprachen getroffen werden, verhindert das die Autonomie der Teams. Agile und Lean-Methoden können dabei helfen, die Flaschenhälse zu erkennen – und abzubauen.

Jede Abhängigkeit verhindert aber autonomes Arbeiten, etwa, wenn die Softwarekomponente außerhalb des Teams kontrolliert wird. Und diese Abhängigkeiten abzubauen oder zu verhindern, ist eine schwierige Herausforderung. Eine Hilfe kann hier sein, im Rahmen von Servicevereinbarungen die Zusammenarbeit zu definieren und vor allem zu automatisieren und so die Autonomie zu ermöglichen (Regel 2).

Warum der Wandel von einem Top-down- zu einem Buttom-up-Ansatz wichtig ist

Es ist notwendig, von dem Top-Down-Ansatz der frühen (Start-Up)-Zeit zu einem Bottom-Up-Ansatz zu wechseln. Hindernisse sind hier die Gründer selbst, die womöglich weiterhin sehr kleinteilig das Unternehmen leiten wollen. In den Anfängen ist es erforderlich, dass die Gründer eine starke Vision haben und sich stark an allen Entscheidungen beteiligen.

Allerdings wird das Produkt, die Technik und das Business im Hyperwachstum sehr schnell immer komplexer. Und diese Komplexität kann nicht alleine von der Führungsebene erfasst werden, es kann nicht mehr alles top-down entschieden werden.

Aber: Hier zu einem Bottom-up-Ansatz umzuschwenken, bei dem auch unten Entscheidungen getroffen werden können, ist unumgänglich für das erfolgreiche Wachstum eines Unternehmens (Regel 3). Allerdings ist es sehr schwer, das umzusetzen, weil sich damit auch die Unternehmenskultur komplett verändern muss. Und das gelingt nicht über Nacht.

Warum „Quick&Dirty“ in Wahrheit „Slow&Dirty“ ist

Häufig ist in Unternehmen die Anforderung an den technischen Bereiche, dass etwas sehr schnell (und unfertig) ausgeliefert werden soll und erst später Verbesserungen durchgeführt werden. Aber es ist ein Irrglaube, dass man in der Zukunft mehr Zeit für etwas hat als jetzt. Denn die Ziele, Herausforderungen und Anforderungen an die Profitabilität wachsen und machen die Zukunft deutlich komplexer.

Studien zeigen so, dass ein sauberer, guter Code, auf den gesamten Entwicklungszyklus betrachtet, am Ende schneller realisiert ist, als die „quick&dirty“-Variante mit späteren Verbesserungen.

Deshalb stimmt es auch nicht, dass „quick&dirty“ schneller ist – das Gegenteil ist der Fall: Dieser Code ist „slow&dirty“. Guter Code ist sowohl kurzfristig als auch langfristig schneller entwickelt, als schlechter Code, zeigen Studien. Die eigentliche Frage ist deshalb, ob man die Entwicklung sauber und schnell oder unsauber und langsam vorantreiben will. Langsam bleibt damit langsam, sowohl kurz-, als auch langfristig (Regel 4).

Entscheidend ist, dass die Entwicklung in einen guten Prozess eingebunden ist, der eine rationale Entscheidung ermöglicht, was priorisiert werden sollte, in welche technischen Komponenten oder Produktfeatures welche Kapazitäten fließen sollen. Hier ist eine Balance wichtig.

Wie Teams zusammengesetzt sein sollten

Es ist wichtig, bei der Teamzusammensetzung und der Einstellung von Personal mehr auf das Verhalten – das Mindset – zu setzen, als auf die formale Qualifikation. Teammitglieder sollten verstehen, dass

• das Unternehmen sehr schnell wächst und sich schnell wandelt (Adaption),
• ein kontinuierliches und schnelles Lernen erforderlich ist, denn Wissen existiert nur begrenzt (Learning),
• das jeder verantwortlich ist, denn es gibt kein Sicherheitsnetz, welches einen bei einer Fehlentwicklung auffängt (Ownership),
• der Servicegedanke – gegenüber den Kollegen und den Kunden – im Vordergrund steht (Be of Service).

Die Erfahrung ist, dass es viel schwieriger ist, die Einstellung der Angestellten zu verändern, als ihnen die notwendigen formalen Qualifikationen zu vermitteln. Ein Vorstellungsgespräch sollte das berücksichtigen.

Warum das Organisationskonzept kontinuierlich weiterentwickelt werden sollte

Je stärker ein Unternehmen wächst, desto komplexer ist die Organisation. In kleinen Unternehmen treffen einige wenige Personen Entscheidungen für kleinere Gruppen, zum Beispiel für 10 Personen. Aber diese Entscheidungsebene kann nicht einfach immer weiter vergrößert werden, etwa, wenn für 1000 Angestellte dann 100 Seniors notwendig wären.

Es ist deshalb sehr wichtig, zu reflektieren, wie konkret jeder Bereich des Produktingenieur-Teams organisiert werden soll (Regel 6). Dabei spielt zum Beispiel auch eine Rolle, wie Remote-Arbeiten und hybrides Arbeiten sinnvoll integriert werden können.

Hier gibt es keine perfekte Lösung, sondern jedes Unternehmen muss das für sich herausfinden (Regel 7). Es hat auch Jahrzehnte gebraucht, bis große Tech-Unternehmen für sich das optimale Büro entwickelt haben. Deshalb sollte hier so viel wie möglich experimentiert werden.

→ Hier findest du die komplette Aufzeichnung seines Talks

Über Peter Minev: Im Jahr 2019 wurde Peter Minev mit dem ESMT Leadership Achievement Award für die Gründung des Unternehmens Careem ausgezeichnet, welches später von Uber für 3,1 Milliarden US-Dollar übernommen wurde. Beim Versicherungsmakler Clark ist er als CTO sowie Vorstandsmitglied des digitalen Erbschaftsdienstes DGLegacy und als Berater für Start-Ups und Venture-Capitalists tätig.

Auf dem Digitale Leute Summit 2022 beschrieb Peter Minev, welche Regeln zu beachten sind, wenn ein Unternehmen erfolgreich schnelles Wachstum meistern möchte.

Autor: Jörg Stroisch