Sie haben gerade als CTO angefangen (Vollzeit oder Fractional). Die nächsten 100 Tage entscheiden, ob Sie erfolgreich sind.
Hier ist der Playbook.
Warum die ersten 100 Tage kritisch sind
Für Sie:
- Sie lernen das Unternehmen, Tech-Stack, Team
- Sie bauen Vertrauen auf (Team, Geschäftsführung, Stakeholder)
- Sie identifizieren die größten Probleme
Für das Unternehmen:
- Sie erwarten Quick Wins (Beweis, dass die Hire richtig war)
- Sie brauchen Klarheit (Was ist der Plan?)
- Sie wollen sehen, dass Sie "hands-on" sind, nicht nur strategisch
Die Balance: Lernen + Liefern + Strategie.
Was mir in den ersten 100 Tagen hilft: Ich führe immer ein "Schattentag"-Format ein. einen Tag lang begleite ich Mitarbeiter in verschiedenen Abteilungen. Die Erkenntnisse sind unbezahlbar.
Die 3 Phasen der ersten 100 Tage
Phase 1: Learn (Tage 1-30)
Ziel: Verstehen, wo Sie sind.
Fokus: 80% Listening, 20% Doing.
Phase 2: Assess & Quick Wins (Tage 31-60)
Ziel: Probleme identifizieren, erste Erfolge liefern.
Fokus: 50% Assessment, 50% Quick Wins.
Phase 3: Plan & Execute (Tage 61-100)
Ziel: Strategie setzen, Roadmap definieren, Team alignen.
Fokus: 30% Strategie, 70% Execution.
Phase 1: Learn (Tage 1-30)
Woche 1: Das Tech-System verstehen
Tag 1-2: Setup & Access
- Dev-Environment aufsetzen (lokal Code laufen lassen)
- Zugriff auf alles (Repos, Cloud, Monitoring, Docs)
- Credentials, VPN, Tools
Ziel: Am Ende von Tag 2 können Sie den Code lokal starten.
Tag 3-5: Code-Walkthrough
- Code-Review-Session mit Senior-Entwicklern
- Architecture-Overview (wie hängt alles zusammen?)
- "Wo tut es weh?"-Fragen (Team fragen: Was nervt am meisten?)
Ziel: Sie verstehen die Hauptkomponenten und größten Pain Points.
Woche 2: Das Team verstehen
1-on-1s mit jedem Team-Member (30-60 Min pro Person):
Fragen:
- Was machst du aktuell?
- Was läuft gut im Team/Prozess?
- Was läuft schlecht? (Top 3 Frustrationen)
- Wenn du CTO wärst, was würdest du sofort ändern?
- Wie lange bist du hier? Was hält dich hier?
Ziel: Trust aufbauen, Pain Points verstehen, Champions identifizieren.
Wichtig: Nur zuhören. Nicht sofort "Das ändern wir!". Notizen machen.
Woche 3: Das Business verstehen
Meetings mit Stakeholdern:
- CEO/Geschäftsführung: Geschäftsziele, Wachstumspläne, Erwartungen an Tech
- Sales/Marketing: Kundenversprechen, Roadmap-Wünsche, größte Bottlenecks
- Customer Success: Häufigste Kundenbeschwerden, Feature-Requests
- Product: Roadmap, Priorisierung, Tech-Abhängigkeiten
Ziel: Verstehen, wie Tech das Business unterstützt (oder blockiert).
Woche 4: Die Tech-Infrastruktur verstehen
Deep Dive:
- Architektur-Diagramme (falls vorhanden, sonst erstellen!)
- Deployment-Prozess (wie kommt Code in Production?)
- Monitoring & Alerting (was wissen wir? was nicht?)
- Incident-History (letzte 6 Monate: Was ist schiefgegangen?)
- Tech-Debt-Assessment (bekannte Probleme, "Wir müssten mal.."-Liste)
Tools:
- Postmortem-Docs lesen
- Monitoring-Dashboards anschauen
- Jira/Linear/GitHub Issues durchgehen (was stapelt sich?)
Ziel: Sie wissen, wo die kritischen Risiken liegen.
Ende Woche 4: Synthesis
Zusammenfassung erstellen (für sich):
- Top 5 Tech-Probleme
- Top 5 Team-Probleme
- Top 5 Business-Blocker (wo blockiert Tech das Business?)
- Quick-Win-Kandidaten (was kann man in 1-2 Wochen fixen?)
Nicht: Noch nichts kommunizieren. Erst sammeln, dann priorisieren.
Phase 2: Assess & Quick Wins (Tage 31-60)
Woche 5-6: Quick Wins ausführen
Was sind Quick Wins?
- Sichtbare Verbesserungen in 1-2 Wochen
- Hoher Impact, niedriger Aufwand
- Beweist Ihre Hands-on-Kompetenz
Beispiele:
1. Deployment-Zeit reduzieren
- Vorher: Deployment dauert 2 Stunden (manuell)
- Nachher: CI/CD-Pipeline, Deployment in 10 Minuten
2. Critical Bug fixen
- Das eine nervige Bug, das seit Monaten existiert
- Sie fixen es in 1 Tag
3. Monitoring-Dashboard
- Team sieht nicht, wie das System performed
- Sie bauen ein simples Dashboard (Grafana, Datadog)
4. Documentation Quick Win
- Onboarding-Doc ist veraltet
- Sie updaten es (1-2 Tage)
5. Code-Review-Prozess
- Kein formaler Prozess
- Sie etablieren: "Mindestens 1 Approve vor Merge"
Regel: Max 1-2 Wochen pro Quick Win. Sonst ist es kein Quick Win.
Warum wichtig:
- Team sieht: "Der neue CTO liefert."
- Geschäftsführung sieht: "Das war die richtige Hire."
- Sie bauen Credibility auf (wichtig für Phase 3, wo Sie größere Änderungen pushen)
Woche 7-8: Assessment finalisieren
Tech-Health-Assessment erstellen:
1. Code-Qualität:
- Test-Coverage: X%
- Tech-Debt-Level: Hoch/Mittel/Niedrig
- Code-Review-Kultur: Ja/Nein
2. Infrastruktur:
- Deployment-Frequency: X/Woche
- MTTR (Mean Time to Recovery): X Stunden
- Monitoring-Coverage: Hoch/Mittel/Niedrig
3. Team:
- Team-Größe: X Entwickler
- Senior/Junior-Ratio: X/Y
- Turnover: X% (letztes Jahr)
- Moral: Gut/OK/Schlecht (basierend auf 1-on-1s)
4. Prozesse:
- Sprint-Velocity: X Story Points
- Bug-vs-Feature-Ratio: X%
- Release-Frequency: X/Monat
5. Architektur:
- Skalierbarkeit: Kritisch/OK/Gut
- Security: Kritisch/OK/Gut
- Complexity: Zu hoch/Angemessen
Output: Dokument (5-10 Seiten) mit Ist-Zustand + Top-Problemen.
Zielgruppe: Sie selbst, CEO, Leadership-Team.
Phase 3: Plan & Execute (Tage 61-100)
Woche 9: Strategie-Workshop
Meeting mit CEO + Leadership:
- Präsentieren Sie Assessment (Ist-Zustand)
- Diskutieren Sie Business-Ziele (nächste 12 Monate)
- Ableiten: Was braucht Tech, um das zu supporten?
Output: Alignment auf Prioritäten.
Beispiel:
Business-Ziel: 3x Umsatz in 12 Monaten
Tech-Implikationen:
→ System muss 5x Traffic verkraften
→ Neue Features für Enterprise-Kunden
→ Team muss von 10 auf 20 wachsen
Prioritäten:
1. Skalierungs-Infrastruktur (Q1)
2. Enterprise-Features (Q2)
3. Team-Hiring & -Struktur (Q1-Q2)Woche 10-12: Roadmap erstellen & kommunizieren
Tech-Roadmap (12 Monate):
Q1:
- Stabilität & Skalierung (Infra-Upgrades)
- Team-Wachstum (5 neue Hires)
- Quick-Debt-Reduction (Top 3 Tech-Debt-Items)
Q2:
- Enterprise-Features
- Security-Audit & Compliance
- Prozess-Optimierung
Q3:
- Innovation / AI-Integration (falls relevant)
- Performance-Optimierung
- Team-Upskilling
Q4:
- Review & Planning für nächstes Jahr
Kommunikation:
1. Mit dem Team (Town Hall):
- "Hier ist, was ich gelernt habe"
- "Hier sind unsere Prioritäten"
- "Hier ist, wie wir uns organisieren"
Wichtig: Transparent sein. Team einbeziehen. Nicht Top-Down diktieren.
2. Mit Stakeholdern:
- "Hier ist der Tech-Plan für die nächsten 12 Monate"
- "So unterstützen wir die Business-Ziele"
- "Das brauchen wir (Budget, Headcount, Zeit)"
Woche 13-14: Execution starten
Initiativen kicken:
- Hiring-Prozess starten (falls nötig)
- Erste Infrastruktur-Upgrades
- Prozess-Änderungen einbauen (z.B. neues Sprint-Setup)
Rhythmus etablieren:
- Weekly Tech-Leadership-Meeting (mit Leads)
- Bi-weekly All-Hands (mit gesamtem Team)
- Monthly Stakeholder-Update (CEO, Product, etc.)
Die kritischen Dos & Don'ts
DO:
1. Liefern Sie Quick Wins
Credibility > Strategie. Beweisen Sie erst, dass Sie liefern können.
2. Hören Sie zu (viel)
Das Team weiß, wo es weh tut. Fragen Sie. Dann handeln Sie.
3. Seien Sie hands-on
Code-Reviews machen, selbst mal was fixen. Keine Ivory-Tower-CTO.
4. Bauen Sie Allianzen
Product, Sales, CEO. Sie brauchen sie. Investieren Sie in Relationships.
5. Dokumentieren Sie
Assessment, Roadmap, Decisions. Write it down.
DON'T:
1. "Alles ist schlecht, wir machen alles neu"
Das demoralisiert das Team. Würdigen Sie, was funktioniert.
2. Zu schnell zu viel ändern
Change-Fatigue ist real. Priorisieren. Nicht 10 Initiativen parallel.
3. Im Elfenbeinturm bleiben
"Ich bin jetzt CTO, ich mache keine Code-Reviews mehr". Falsch.
4. Versprechen machen, die Sie nicht halten können
Unter-promise, over-deliver. Nicht umgekehrt.
5. Das Team ignorieren
Ohne Team-Buy-In scheitern Sie. Punkt.
Die 100-Tage-Checkliste
Tag 30:
- 1-on-1 mit jedem Team-Member geführt
- Code lokal laufen + verstanden
- Stakeholder-Meetings absolviert
- Top 5 Probleme identifiziert
- 1-2 Quick Wins geliefert
Tag 60:
- Tech-Health-Assessment erstellt
- Quick Wins sichtbar (Team + Leadership merken es)
- Erste Prozess-Verbesserungen (Code-Review, CI/CD, etc.)
Tag 100:
- 12-Monats-Roadmap erstellt & kommuniziert
- Team ist aligned (weiß, wohin es geht)
- Leadership vertraut Ihnen
- Execution läuft (erste Roadmap-Items gestartet)
Erfolgsmetriken: Wie wissen Sie, ob Sie erfolgreich waren?
Nach 100 Tagen:
Team:
- Team-Moral gestiegen (messbar via Umfrage oder Turnover)
- Entwickler sagen: "Es wird besser"
Delivery:
- Velocity ist stabil oder steigt
- Deployment-Frequency höher
- Incident-Rate sinkt
Stakeholder:
- CEO sagt: "Ich bin froh, dass wir dich haben"
- Product/Sales sehen Tech nicht mehr als Blocker
Strategie:
- Klare Roadmap existiert
- Alle wissen, wohin es geht
- Budget/Headcount für nächstes Jahr ist geklärt
Spezialfall: Fractional CTO (Part-Time)
Unterschiede zu Vollzeit:
1. Weniger Zeit →Priorisierung ist härter
Fokus auf Top 3 Probleme, nicht Top 10.
2. Asynchrone Kommunikation wichtiger
Slack, Loom-Videos, schriftliche Updates.
3. Delegation früher nötig
Sie können nicht überall sein. Identifizieren Sie Leads, empowern Sie sie.
4. Quick Wins sind noch wichtiger
Sie haben weniger "Presence" →Sichtbare Erfolge sind kritisch.
Anpassung der Timeline:
- Vollzeit-CTO: 100 Tage = ~14 Wochen
- Fractional (3 Tage/Woche): 100 Tage = ~20 Wochen
Die Phasen bleiben gleich, nur gestreckter.
Fazit: Die ersten 100 Tage sind ein Sprint, kein Marathon
Phase 1: Verstehen (30 Tage)
Phase 2: Liefern (30 Tage)
Phase 3: Strategisch führen (40 Tage)
Das Ziel: Nach 100 Tagen wissen Sie, was zu tun ist. Das Team vertraut Ihnen. Leadership ist aligned. Und Sie liefern.
Dann beginnt die eigentliche Arbeit.