Die ersten 100 Tage als CTO oder VP Engineering.

Wer zum ersten Mal CTO oder VP Engineering wird, fällt typischerweise in eine von zwei Fallen: entweder bleibst du Architekt mit Führungs-Aufgaben oder du wirst Manager der seine technische Substanz verliert. Die ersten 100 Tage entscheiden welche.

Woche 1-2: Daten sammeln, nicht entscheiden.

1:1 mit jedem direct report. Architektur-Review der drei wichtigsten Systeme. Backlog-Walkthrough mit jedem Product Owner. Ein Skip-Level-Lunch mit drei Engineers ohne direkte Hierarchie. Keine Entscheidungen · Notizen.

Woche 3-4: Drei Mini-Signale.

Eine kleine Architektur-Entscheidung die zeigt dass du verstehst was läuft. Eine 1:1-Routine die zeigt dass dir Senior-Engineers wichtig sind. Ein Stand-up-Format-Tweak der zeigt dass du auf Output achtest, nicht auf Anwesenheit.

Woche 5-8: Strategische Klarheit.

Du hast genug Kontext für die erste echte Roadmap-Diskussion. SEXIER strukturiert. Die Konversation passiert mit deinem CEO und deinem Senior-Team, nicht im All-Hands. Im All-Hands kommt die fertige Klarheit, kein Debattier-Raum.

Woche 9-12: Senior-Hires.

In den ersten 100 Tagen wirst du typischerweise mindestens einen Senior-Hire machen. Die Frage ist nicht ob, sondern in welcher Rolle. Architekt-Spannung kann auch durch einen Senior-Architect mit klarer Verantwortung gelöst werden · du musst nicht selbst Architekt bleiben.

Die häufigste 100-Tage-Falle.

"Ich muss Wert zeigen." Falsch. Du musst in den ersten 100 Tagen weniger Wert zeigen, mehr Kontext aufbauen. Wer auf Tag 30 die erste große Re-Architektur ankündigt, hat sich zwei wichtige Vertrauens-Reserven verbrannt: das Team weiß "neuer CTO macht Politik", das Senior-Eng weiß "neuer CTO hört nicht zu".

In der Challenge trainierst du die ersten 100 Tage als konkrete Drill-Cases · dein erstes 1:1 mit dem Senior-Architect, deine erste Roadmap-Skizze für den CEO, deine erste Skip-Level-Konversation. Real, nicht Theorie.