Tech Turnaround

Die Firefighting-Falle

Du baust nichts mehr. Du überlebst nur noch.

Jedes Deployment fühlt sich an wie Russisches Roulette und die On-Call-Rotation brennt Leute aus - Entwickler sind genervt weil sie am Wochenende Calls bekommen. Der “temporäre Fix” von vor zwei Jahren ist jetzt tragende Infrastruktur. Deine besten Engineers verbringen mehr ihrer Zeit mit Incidents statt Features. PLUS der CEO fragt, warum alles so lange dauert - und jedes Quartal noch länger dauert. Du hast keine gute Antwort (schau dir mein Eisberg-Beispiel für eine Antwort an!)

Das ist Tech Turnaround Territory. Siehe meine persönliche Geschichte - ich war mehrfach da, been there, bought the t-shirt.

Wie Systeme unter Wachstum brechen

Es gibt ein Muster, das ich ständig in wachsenden Startups sehe. Das System, das mit 1.000 Usern perfekt funktioniert hat, beginnt bei 100.000 Usern zu bröckeln - ein typisches Skalierungsproblem. Nicht weil jemand etwas falsch gemacht hat - weil die Architektur für eine andere Größenordnung designed war - und Unknown Unknowns wie ORM-Verhalten nicht vorhergesagt werden konnten.

Die Warnsignale:

Deployments werden zu Events. Alle haben jetzt Angst vor Deployments. Leute vermeiden es, Freitags zu deployen. Dann Donnerstags. Dann an jedem Tag, der nicht absolut notwendig ist.

Incidents clustern. Ein Ausfall führt zum nächsten. Der Fix für das gestrige Problem verursacht das morgige. Dein Monitoring-Dashboard sieht aus wie ein Weihnachtsbaum - und nicht im guten Sinne. Niemand schaut überhaupt noch auf DataDog (und das bei den Kosten!) oder Grafana (aber dein Dashboard ist nice).

Velocity-Todesspirale. Jeden Sprint wird weniger erledigt. Das Backlog wächst (oder sogar die Backlogs). Features, die mal Tage gedauert haben, dauern jetzt Wochen. Deine Engineers sind frustriert, und die Guten updaten ihr LinkedIn. Jedes Feature ist eine Emergency und hat Top-Priorität (nächste Woche was neues), weil der CEO denkt, das ist der einzige Weg, irgendetwas bewegt zu bekommen.

Technical Debt akkumuliert. Du weißt, dass du das Fundament fixen solltest, aber es gibt immer etwas Dringenderes. Also patchst du und hoffst. Die Schulden akkumulieren mit Zinsen.

Das Blame Game

Manchmal erbst du diese Probleme. Der vorherige CTO hat ein Chaos hinterlassen. Die Gründer haben in den frühen Tagen opportunistische Entscheidungen getroffen (zu Recht - sie mussten überleben - und nicht vergessen, der Code hat das Unternehmen wachsen lassen, sodass sie dich einstellen konnten!) Das System ist organisch gewachsen ohne Plan - weil es keine Business-Strategie oder Tech-Strategie gab.

Niemanden interessiert’s - jetzt ist es dein Problem.

Und wenn Dinge kaputt gehen, schauen alle Augen auf dich. Egal dass du sechs Monate hier bist und diese Architektur vor drei Jahren gebaut wurde. Egal dass du genau vor diesem Risiko gewarnt hast, seit du angekommen bist (du hättest einen Feature Freeze machen und das Chaos in deinen ersten drei Monaten fixen sollen, nein jetzt wirst du als Teil des Problems wahrgenommen). Du bist der CTO. Die Technologie ist am A*.

Das ist der einsamste Teil von Tech Turnaround. Du kennst die Probleme. Du weißt, was getan werden muss. Aber du kannst nicht alles auf einmal machen, und alles brennt.

Was wirklich funktioniert

Ich habe Tech Turnarounds in mehreren Unternehmen geleitet. Das Playbook ist nicht kompliziert, aber es erfordert Disziplin und Willenskraft.

1. Stoppe zuerst die Blutung. When in a hole stop digging. Bevor du etwas Neues bauen kannst, brauchst du Stabilität. Das könnte einen Feature Freeze bedeuten. Es könnte bedeuten, Monitoring und Observability hinzuzufügen anstatt Features. Es bedeutet höchstwahrscheinlich, dem CEO für ein Quartal nein zu sagen und Pushback zu geben. Stabilisierung ist Voraussetzung für jeden Fortschritt.
2. Triage gnadenlos. Nicht alles Technical Debt ist gleich. Manches ist tödlich, manche ist hässlich. Und obwohl ich verstehe, dass niemand durch hässlichen Code waten will - der Unterschied ist wichtig. Fix was kritisch ist. Dokumentiere was akzeptabel ist. Ignoriere was nicht zählt. Ich habe Teams gesehen, die Monate damit verschwendet haben, Code “aufzuräumen”, den niemand tatsächlich anfasst - oder schlimmer: Einen Rewrite zu pushen der am Ende auch nicht besser ist.
3. Mach Deployments wieder langweilig. Wenn deine Deploys scary sind, fix das zuerst. Hands-Off CI/CD heute ist der minimale akzeptable Standard (+ Build on Trunk + Feature Flags).
4. Baue Observability vor Features. Du kannst nicht fixen, was du nicht siehst. Bevor du eine weitere Zeile Feature-Code schreibst, stell sicher, dass du tatsächlich verstehen kannst, was dein System macht. Gutes Monitoring ist eine Versicherung.
5. Schaffe Raum für echte Arbeit. Die größte Falle im Turnaround-Modus ist, dass Firefighting alles andere verdrängt. Du musst Zeit für tatsächliche Verbesserung aufwenden. Das könnte explizite “No-Meeting”-Tage bedeuten. Es könnte bedeuten zu rotieren, wer Incident Duty hat, damit andere fokussieren können. Finde einen Weg, Fortschritt zu machen, auch während die Feuer brennen.

JEDE KRISE IST DIE CHANCE AUF POSITIVE VERÄNDERUNG. Was in normalen Zeiten nicht möglich ist, wird jetzt möglich. Was nicht denkbar an Veränderung ist, ist jetzt akzeptabel.

Die Timeline-Frage

Jeder will wissen: Wie lange dauert ein Tech Turnaround?

Ich: Länger als du willst.

Was auch immer du tust: Versprich nicht zu viel. Ich habe das gemacht, und später ist es sehr schwer, deine Versprechen nach dem Rewrite zu beweisen - Performance ist meistens nicht merklich besser.

Eine echte Plattform-Stabilisierung dauert typischerweise 6-12 Monate, um echte Ergebnisse zu sehen. Die ersten 30 Tage geht es darum, die Verschlechterung zu stoppen und den vollen Umfang zu verstehen. Monate 2-4 geht es darum, das Fundament zu bauen - CI/CD, Monitoring, das langweilige Zeug, das alles andere möglich macht. Monate 5-12 sind, wenn du anfängst, compound returns zu sehen. Deploys werden einfacher. Incidents nehmen ab. Bugs gehen runter. Website-Speed steigt. Build-Zeiten sinken. Tests sind mehr und funktionieren. Engineers fangen wieder an Spass zu haben.

Ein Fehler ist es, sofortige Ergebnisse zu erwarten und zu viel zu versprechen. Die Plattform ist nicht über Nacht dahin geraten. Sie wird auch nicht über Nacht heilen.

Wann um Hilfe bitten

Tech Turnaround ist einer der härtesten Jobs im Engineering Leadership. Du triffst Entscheidungen mit hohem Einsatz bei unvollständigen Informationen, während das Gebäude brennt. Du managst nach oben (den CEO ruhig halten), managst nach unten (das Team motiviert und dabei halten), und managst nach außen (Kunden vom Gehen abhalten oder wiedergewinnen) - alles gleichzeitig.

Die meisten CTOs, mit denen ich in Turnaround-Situationen spreche, haben die technischen Skills, die Probleme zu fixen. Was ihnen fehlt, ist Perspektive und Willenskraft den Turnaround durchzusetzen. Wenn du mitten in einer Krise bist, ist es schwer, klar zu sehen. Du brauchst jemanden, der das durchgemacht hat, der dir helfen kann zu priorisieren, der dir sagen kann, welche Feuer zu bekämpfen sind und welche brennen zu lassen (erstmal ;-)

Das ist keine Schwäche.

Tech Turnaround ist brutal. Du wirst für Probleme beschuldigt, die du geerbt hast. Es wird erwartet, dass du sofort alles fixst. Du triffst karrieredefinierende Entscheidungen jede Woche.

Die CTOs, die in Turnaround-Situationen Erfolg haben, sind nicht unbedingt schlauer oder erfahrener als die, die scheitern. Sie sind die, die Hilfe holen. Die jemanden finden, der diese Muster schon gesehen hat. Die ihr Denken validieren lassen und helfen lassen zu priorisieren, wenn alles dringend erscheint.

Wenn deine Plattform instabil ist und du nicht weißt, wo anfangen - genau dann zählt externe Perspektive am meisten.

Ich habe selbst Tech Turnarounds geleitet und CTOs durch Plattform-Stabilisierung gecoacht bei Unternehmen von Seed bis Series B und darüber hinaus. Wenn du im Firefighting-Modus bist und jemanden brauchst, der dort war - lass uns reden.

Mehr über CTO Coaching