Wie sieht deine Roadmap für die ersten 90 Tage aus, wenn du als Tech Lead in einem neuen Unternehmen anfängst?

Question

Accepted Answer

Meine ersten 90 Tage sind in der Reihenfolge **zuhören, dann kartieren, dann handeln** aufgebaut: Ich gewinne Vertrauen und Kontext, bevor ich etwas ändere, liefere dann einen kleinen sichtbaren Erfolg und schlage erst danach strukturelle Änderungen vor. Das Ziel ist Glaubwürdigkeit, nicht Heldentum.

## Tage 0–30: Zuhören und lernen

- **Triff jeden im 1:1** — jeden Entwickler, meinen Manager, den PM und die wichtigsten Stakeholder. Ich frage, was funktioniert, was kaputt ist und was sie sich wünschen, dass jemand behebt.
- **Lies das System, nicht nur den Code** — führe die App lokal aus, verfolge den kritischen Request-Pfad, lies die Incidents und Postmortems der letzten 3 Monate.
- **Kartiere die Delivery-Pipeline** — wie Code vom Laptop in die Produktion gelangt, wo er stockt, wie die CI/CD- und On-call-Situation aussieht.
- **Schreibe noch nichts Strukturelles.** Ich reiche kleine PRs ein (Doku, ein flaky Test, eine README), um den Workflow kennenzulernen und zu zeigen, dass ich praktisch mit anpacke.

## Tage 30–60: Diagnostizieren und einen Erfolg liefern

- Fasse die Erkenntnisse in einer kurzen **schriftlichen Diagnose** zusammen: die drei größten Stärken, die drei größten Risiken, nach Wirkung geordnet.
- Wähle **einen aussagekräftigen, risikoarmen Erfolg** — z. B. die CI-Zeit halbieren, den lautesten Alert beheben, das Deployment dokumentieren. Sichtbarer Mehrwert schafft das politische Kapital für größere Änderungen.
- Validiere meine Einschätzung mit dem Team und dem Manager, bevor ich mich auf eine Richtung festlege.

## Tage 60–90: Richtung vorgeben

- Schlage eine **technische Roadmap** vor, die an Geschäftszielen ausgerichtet ist, mit Reihenfolge und Verantwortlichen.
- Etabliere oder verfeinere **Team-Rituale** — Code-Review-Normen, On-call-Rotation, Planungsrhythmus.
- Einige mich mit meinem Manager darauf, **wie mein Erfolg gemessen wird**, nach sechs Monaten.

## Fallstricke, die es zu vermeiden gilt

- **Umschreiben vor dem Verstehen** — das „offensichtliche" Chaos kodiert oft hart erkämpfte Constraints.
- **Versuchen, alles auf einmal zu beheben** — wähle wenige Dinge und bringe sie zu Ende.
- **Den sozialen Graphen ignorieren** — wer wirklich Entscheidungen trifft, ist genauso wichtig wie die Architektur.

## Warum es wichtig ist

Die Hebelwirkung eines Tech Lead entsteht aus Vertrauen und Kontext, die sich beide kumulativ aufbauen. Den ersten Monat mit Zuhören zu verbringen fühlt sich langsam an, verhindert aber den teuren Fehler, das falsche Problem lautstark zu lösen — und ein glaubwürdiger früher Erfolg verschafft dir das Mandat, später die harte strukturelle Arbeit anzugehen.