Von 40 auf 120 Entwickler: Der CTO-Survival-Guide

Ihr Engineering-Team ist in 18 Monaten von 20 auf 40 Entwickler gewachsen, und die nächste Welle steht bevor: 80, 100, vielleicht 120 Developer in den nächsten 12–18 Monaten. Der Vorstand drängt auf mehr Feature-Output, neue Märkte sollen bedient werden.

Sie spüren es längst: Was bei 40 Leuten funktioniert, bricht bei 120 zusammen. Meetings explodieren. Deployment-Konflikte häufen sich. Kommunikation zwischen Teams wird chaotisch. Sie selbst arbeiten 60–80 Stunden pro Woche, entscheiden alles – und haben keine Zeit mehr für Strategie.

Die Phase von 40 auf 120+ Entwickler ist der härteste organisatorische Sprung, den ein Scale-up durchläuft – härter als der von 5 auf 20. Hier entscheidet sich, ob Ihr Unternehmen High-Performance-Engineering aufbaut oder im Chaos versinkt.

Dieser Guide zeigt, wie Sie diese Transition meistern – basierend auf über zwölf Scale-ups, die ich durch genau diese Phase begleitet habe.

Für wen dieser Artikel relevant ist: CTOs, VPs Engineering und Tech-Founder in Scale-ups zwischen Series A und Series C, die Team-Größen zwischen 30 und 150 Entwicklern verantworten und vor dem Einführen einer zweiten Management-Ebene stehen.

Warum 40–120 die kritischste Phase ist

Vier Gründe machen diese Phase einzigartig hart:

1. Die zweite Management-Ebene wird unverzichtbar

Bei 40 Entwicklern reichen 4–6 Tech-Leads, die direkt an Sie reporten. Bei 80+ geht das nicht mehr. Sie brauchen einen Engineering-Manager-Layer zwischen sich und den Tech-Leads. Diese Transition ist schmerzhaft:

• Ihre Rolle ändert sich: Sie führen nicht mehr direkt Teams, sondern coachen Manager
• Neue Skills nötig: Hiring, Entwicklung und Retention von Engineering-Managern
• Machtverlust-Gefühle: Viele CTOs erleben dies als "Kontrollverlust"

2. Informelle Kommunikation skaliert nicht mehr

Bei 40 Entwicklern kennt noch jeder jeden. Informationen verbreiten sich durch Flurgespräche, Slack und Ad-hoc-Meetings. Bei 100+ Entwicklern funktioniert das nicht mehr:

• Wissenssilos entstehen: Teams wissen nicht, woran andere arbeiten
• Redundante Arbeit: Team A baut, was Team B schon hat
• Inkonsistenzen: Jedes Team hat eigene Standards, Tools, Praktiken

3. Architektur muss neu gedacht werden

Der Monolith, der bei 40 Entwicklern noch performt, bricht bei 100+ zusammen:

• Deployment-Konflikte: 20+ PRs täglich können nicht mehr koordiniert werden
• Code-Ownership unklar: Zu viele Hände im selben Code
• Technologie-Entscheidungen: Nicht mehr möglich, dass "der CTO entscheidet"

4. Sie selbst sind das Problem

Die härteste Wahrheit: Ab 40 Entwicklern ist der CTO oft der größte Bottleneck. Jede Architektur-Entscheidung läuft über Sie. Jeder Hire braucht Ihre Freigabe. Jede strategische Frage landet auf Ihrem Schreibtisch. Sie arbeiten 80 Stunden pro Woche – und das Team wartet trotzdem.

Sie müssen Ihre Rolle neu definieren – vom "Super-Tech-Lead, der alles entscheidet" zum "Strategic Leader, der Rahmenbedingungen schafft". Mehr dazu in Dimension 4.

Das Framework: 4 Dimensionen der Skalierung

Erfolgreiche Skalierung von 40 auf 120+ Entwickler erfordert parallele Arbeit in vier Dimensionen:

1. Organisatorische Struktur (Team Topologies)
2. Technische Architektur (Modulare Systeme, APIs)
3. Prozesse & Tooling (DORA-Metriken, DevOps)
4. Leadership & Kultur (Ihre eigene Transformation)

Lassen Sie uns jede Dimension durchgehen.

Dimension 1: Organisatorische Struktur (Team Topologies)

Das Problem mit funktionalen Teams

Bei 40 Entwicklern haben viele Unternehmen funktionale Teams: Frontend-Team, Backend-Team, Infrastructure-Team, QA-Team. Das funktionierte eine Weile, aber jetzt sehen Sie:

• Endlose Abstimmung: Um ein Feature zu liefern, brauchen Sie 4 Teams
• Ownership-Vakuum: Niemand ist end-to-end für ein Feature verantwortlich
• Deployment-Chaos: Koordination zwischen 4 Teams für ein Release

Die Lösung: Stream-Aligned Teams

Team Topologies (Buch von Skelton & Pais) bietet das beste Framework für diese Phase. Die Kernidee:

Stream-Aligned Teams = Cross-funktionale Teams, die end-to-end Features liefern können, ohne ständig auf andere Teams zu warten.

Wie das aussieht:

Statt:

Frontend-Team (12 Devs)
Backend-Team (15 Devs)
Infrastructure-Team (8 Devs)
QA-Team (5 Devs)

Machen Sie:

Product-Team "Onboarding" (8 Devs: 3 FE, 4 BE, 1 DevOps)
Product-Team "Payments" (10 Devs: 4 FE, 5 BE, 1 DevOps)
Product-Team "Analytics" (7 Devs: 2 FE, 4 BE, 1 DevOps)
Platform-Team (15 Devs: Infrastruktur, Tooling, Developer-Experience)
Enabling-Team (5 Devs: Unterstützen andere Teams, Coaching)

Key-Prinzipien:

1. Klein genug: 6-10 Personen pro Team ("Two Pizza Teams")
2. Autonomy: Teams können Features deployen ohne andere Teams
3. Clear Interfaces: Platform-Team bietet Self-Service-Tools
4. Cognitive Load Management: Jedes Team hat klar definierte Verantwortlichkeiten

Wie Sie die Transition durchführen

Phase 1: Assessment (2-3 Wochen)

• Mapping: Welche Features/Domänen haben Sie?
• Dependencies analysieren: Wo sind die größten Abhängigkeiten?
• Team-Skills auditieren: Wer hat welche Skills?

Phase 2: Team-Design (2-3 Wochen)

• Stream-Aligned Teams definieren (basierend auf Domänen)
• Platform-Team Scope festlegen
• Team-Komposition planen (Skills-Mix pro Team)

Phase 3: Migration (8-12 Wochen)

• Schritt für Schritt: Nicht alle Teams gleichzeitig umbauen
• Start mit einem Pilot-Team: Lernen, iterieren
• Clear Charters kommunizieren: Was ist das Team verantwortlich für?

Phase 4: Stabilisierung (12+ Wochen)

• Dependencies monitoren: Wo gibt es noch zu viele Abhängigkeiten?
• Team-Topologie iterieren: Anpassen basierend auf Learnings
• Platform-Investments: Welche Tools brauchen alle Teams?

Dimension 2: Der Engineering-Manager-Layer

Warum Sie Engineering-Manager brauchen

Bei 40 Entwicklern: 4-6 Tech-Leads reporten an Sie. Das ist handhabbar.

Bei 80+ Entwicklern: 8-12 Tech-Leads reporten an Sie? Unmöglich.

Sie brauchen Engineering-Manager – eine Ebene zwischen sich und den Tech-Leads.

Was ist ein Engineering-Manager?

Engineering-Manager ≠ Tech-Lead.

• Tech-Lead: Technische Führung, Architektur-Entscheidungen, Code-Reviews (70% hands-on, 30% Leadership)
• Engineering-Manager: Menschen-Führung, Hiring, Performance-Management, Karriere-Entwicklung (20% hands-on, 80% Leadership)

Typische Struktur bei 100 Entwicklern:

Sie (CTO)
 ├─ VP Engineering (oder Head of Engineering)
 │   ├─ Engineering-Manager "Product Teams A-C" (3 Teams, 25 Devs)
 │   ├─ Engineering-Manager "Product Teams D-F" (3 Teams, 25 Devs)
 │   └─ Engineering-Manager "Platform & Infrastructure" (2 Teams, 20 Devs)
 └─ Head of Quality/Security (2 Teams, 10 Devs)

Wie Sie Engineering-Manager rekrutieren und entwickeln

Option 1: Von innen entwickeln

• Vorteil: Kennen Kultur, Kontext, Technologie
• Nachteil: Brauchen Training, machen Fehler, dauert 6-12 Monate

Option 2: Von außen hiren

• Vorteil: Bringen Erfahrung und Best-Practices mit
• Nachteil: Kulturelle Integration schwierig, teuer

Best Practice: Mix aus beiden. Entwickeln Sie 2-3 Ihrer besten Tech-Leads zu Engineering-Managern (Innen), und hiren Sie 1-2 erfahrene EMs von außen (die als Mentoren fungieren).

Ihre Rolle: From Manager to Leader

Was sich für Sie ändert:

Vorher (40 Devs):

• Direktes Management von 5-6 Tech-Leads
• Involvement in täglichen Entscheidungen
• Hands-on bei kritischen Projekten

Nachher (100+ Devs):

• Coaching von 3-4 Engineering-Managern
• Fokus auf Strategy, Vision, Kultur
• Involvement nur bei strategischen Entscheidungen

Das ist schwer. Viele CTOs kämpfen mit dieser Transition. Sie vermissen das "in the trenches"-Gefühl. Sie haben Angst, den Kontakt zur Technologie zu verlieren.

Die Wahrheit: Loslassen oder selbst Bottleneck bleiben. Delegation ist keine Option, sondern Ihre einzige Skalierungs-Strategie.

Dimension 3: Prozesse & Metriken (DORA)

Das Problem: Intransparente Produktivität

Bei 40 Entwicklern spüren Sie noch, ob das Team performt. Bei 100+ ist das unmöglich. Sie brauchen Metriken.

DORA-Metriken: Der Goldstandard

DORA (DevOps Research and Assessment) hat vier Kernmetriken identifiziert, die Elite-Engineering-Organisationen von Average unterscheiden:

1. Deployment-Frequenz: Wie oft deployen Sie zu Production?
2. Lead Time for Changes: Wie lange von Commit bis Production?
3. Change Failure Rate: Wie viele Deployments verursachen Incidents?
4. Mean Time to Recovery (MTTR): Wie schnell recovern Sie von Incidents?

Warum DORA-Metriken wichtig sind:

• Objektiv: Keine subjektiven Meinungen, sondern Daten
• Benchmarkable: Sie können sich mit Elite-Teams vergleichen
• Actionable: Verbesserungen sind klar messbar

Elite vs. Average: Die Benchmarks

Metrik	Elite-Performer	Average	Ihr Ziel bei 100 Devs
Deployment-Frequenz	Multiple/Tag	1x/Woche	5-10x/Tag
Lead Time	< 1 Stunde	1 Woche	< 1 Tag
Change Failure Rate	< 5%	15-20%	< 10%
MTTR	< 1 Stunde	1-7 Tage	< 4 Stunden

Wie Sie DORA-Metriken implementieren

Phase 1: Baseline erstellen (Woche 1-2)

• Aktuellen Stand messen: Wo stehen Sie heute?
• Tools aufsetzen: DataDog, New Relic, oder Custom-Dashboards
• Baseline kommunizieren: Transparent mit Team teilen

Phase 2: Quick Wins identifizieren (Woche 3-4)

• Wo ist der größte Hebel? (z.B. Deployment-Pipeline optimieren)
• Low-Hanging Fruit: CI/CD-Optimierung, Feature-Flags, Monitoring

Phase 3: Systematische Verbesserung (Monat 2-6)

• Wöchentliche Reviews: Wie entwickeln sich die Metriken?
• Experiments: Was funktioniert, was nicht?
• Team-Ownership: Jedes Team trackt eigene DORA-Metriken

Phase 4: Kultur-Transformation (Monat 6+)

• DORA-Metriken in Performance-Reviews integrieren
• Celebrations: Teams mit besten Verbesserungen featuren
• Continuous Improvement: Nie aufhören zu optimieren

Dimension 4: Ihre eigene Transformation

Das CTO-Time-Audit: Wo verlieren Sie Zeit?

Exercise: Tracken Sie eine Woche lang jede Stunde.

Typisches Ergebnis bei überlasteten CTOs (40-80 Devs):

• 40% Meetings: 1-on-1s, Team-Meetings, Planning, Sync-Calls
• 25% Operative Arbeit: Code-Reviews, Firefighting, Support-Tickets
• 20% Hiring: Interviews, Recruiting, Onboarding
• 10% Strategische Arbeit: Roadmap, Architektur-Planung, Vision
• 5% Overhead: Email, Admin, HR-Kram

Das Problem: Nur 10% strategische Arbeit! Bei 100+ Entwicklern brauchen Sie mindestens 60% strategische Zeit.

Das Delegations-Framework

Was können Sie delegieren?

Aufgabe	An wen delegieren	Wann
Code-Reviews (non-critical)	Tech-Leads	Sofort
Routine-Interviews	Engineering-Manager	Ab 60 Devs
Incident-Response	On-Call-Rotation + SRE	Ab 50 Devs
Feature-Priorisierung	Product-Owner + Eng-Manager	Ab 80 Devs
Architektur (Modul-Ebene)	Tech-Leads	Ab 60 Devs
Tool-Evaluationen	Platform-Team	Ab 70 Devs

Was können Sie NICHT delegieren?

• Vision & Strategie
• Kulturelle Werte
• Kritische Hiring-Decisions (Director+)
• Board-Präsentationen
• Budgeting

Ihre Wochenstruktur bei 100 Devs

Ziel-Verteilung:

• 60% Strategisch: Roadmap, Architektur (High-Level), Org-Design, Hiring-Strategie
• 20% Coaching: 1-on-1s mit Engineering-Managern, Mentoring
• 10% Operational: Kritische Incidents, CEO-Requests
• 10% Extern: Board-Meetings, Recruiting (Senior-Level), Konferenzen

Konkrete Woche:

• Montag: Strategy Day (4h tiefe Arbeit: Roadmap, OKRs, Architektur)
• Dienstag: 1-on-1s mit Engineering-Managern (3x 1h), Team-All-Hands (1h)
• Mittwoch: Hiring (2x Senior-Interviews), Architektur-Review-Meeting (2h)
• Donnerstag: External (Board-Meeting 2h, Recruiter-Meeting 1h), Deep Work (Strategie-Dokument schreiben)
• Freitag: Town-Hall (1h), OKR-Review mit Leadersship-Team (2h), Freie Zeit für Unvorhergesehenes

Das Ergebnis: Sie arbeiten 40-50h/Woche (statt 80h), haben aber 10x mehr Impact.

Die 3 häufigsten Fehler (und wie Sie sie vermeiden)

Fehler #1: Zu spät mit Umstrukturierung anfangen

Symptom: Sie merken erst bei 80 Entwicklern, dass die Organisation chaotisch ist. Jetzt müssen Sie unter Zeitdruck umbauen.

Vermeidung: Antizipieren Sie Schwellen. Bei 50 Devs sollten Sie bereits planen für 80 Devs. Bauen Sie die Strukturen bevor Sie sie brauchen, nicht nachdem es brennt.

Fehler #2: Technologie vor Organisation

Symptom: Sie investieren in Microservices, Kubernetes, Platform-Engineering – aber die Teams sind chaotisch organisiert.

Vermeidung: Conway's Law ernst nehmen. Ihre Architektur wird Ihre Organisation widerspiegeln. Erst Organisation, dann Technologie.

Fehler #3: Keine klaren Ownership

Symptom: Bei Incidents fragt jeder "Wer ist dafür verantwortlich?" – und niemand weiß es.

Vermeidung: Explizite Ownership-Modelle. Jedes System, jeder Service, jedes Team hat einen klaren Owner. Publizieren Sie das in einer Service-Registry.

Der Erfolgsfall: Was passiert, wenn es klappt

Wenn Sie die Skalierung von 40 auf 120 Entwickler erfolgreich meistern, sehen Sie:

Organisatorisch:

• ✅ Deployment-Frequenz: 1x/Woche → 8-10x/Tag
• ✅ Lead Time: 4 Tage → 8 Stunden
• ✅ Change Failure Rate: 15% → 4%
• ✅ Team-Fluktuation: 25% → 12%/Jahr
• ✅ eNPS (Employee Net Promoter Score): +15 → +40

Für Sie persönlich:

• ✅ Arbeitszeit: 70-80h → 45-50h/Woche
• ✅ Strategische Zeit: 10% → 60%
• ✅ Burnout-Risiko: Hoch → Niedrig
• ✅ Job-Satisfaction: Sie lieben Ihre Arbeit wieder

Für das Business:

• ✅ Feature-Velocity: +55%
• ✅ Time-to-Market: -60%
• ✅ Engineering-Kosten/Dev optimiert: -15% (höhere Produktivität)
• ✅ Customer-Satisfaction: +20 NPS-Punkte

Architektur bei Skalierung: Warum Teamstruktur und Systemarchitektur zusammenhängen

Conway's Law ist in der Phase von 40 auf 120 Entwickler keine akademische Theorie, sondern tägliche Realität. Ihre Team-Struktur bestimmt Ihre Software-Architektur – ob Sie es wollen oder nicht. Wenn Ihr Monolith von 15 Teams gleichzeitig bearbeitet wird, entstehen Merge-Konflikte, Deployment-Blockaden und undefinierte Ownership. Die Lösung ist keine rein organisatorische: Sie müssen Team-Topologie und System-Architektur gemeinsam redesignen.

Mein Ansatz: Definieren Sie zuerst die gewünschte Team-Topologie (Stream-Aligned, Platform, Enabling Teams). Leiten Sie daraus die Ziel-Architektur ab (Domain-Boundaries, API-Contracts, Service-Ownership). Und nutzen Sie das Strangler-Fig-Pattern, um den Monolithen schrittweise entlang der Team-Boundaries zu dekomponieren. So wachsen Organisation und Architektur synchron.

Fazit: Evolution statt Verlust

Die Phase von 40 auf 120 Entwickler ist brutal. Viele CTOs zweifeln, ob sie der Rolle noch gewachsen sind.

Die Wahrheit: Diese Phase ist objektiv schwer und verlangt andere Skills als die Phasen davor. Das hat nichts mit Ihrer Eignung zu tun.

Konkret heißt erfolgreiche Transition:

• Team-Topologie vor Architektur festlegen – Conway's Law nicht ignorieren, sondern aktiv nutzen
• Engineering-Manager einstellen oder entwickeln, bevor die Tech-Leads zu Ihrem Engpass werden (typischerweise bei 50–60 Devs planen, nicht erst bei 80 reagieren)
• DORA-Metriken als gemeinsame Sprache zwischen Teams und Leadership etablieren
• Ihre eigene Kalender-Struktur radikal umbauen – Strategie wird zum Default, Operational die Ausnahme

Starten Sie nicht mit allem parallel. Starten Sie mit einem Pilot-Team nach Team-Topologies-Logik und einer ehrlichen Wochen-Analyse Ihrer eigenen Zeit. Alles Weitere baut darauf auf.

Nächste Schritte

• Passende Landing Page: Team-Skalierung: Von 40 auf 120+ Entwicklern
• Passende Landing Page: CTO-Sparring für Scale-up-CTOs
• Verwandter Artikel: CTO-Time-Audit: Wo verlieren Sie 20 Stunden pro Woche?
• Verwandter Artikel: DORA Metrics: Warum sie für CTOs immer wichtiger werden
• Gespräch vereinbaren: 60-Min-Strategiegespräch