Die ersten 100 Tage als Tech-Lead

Beziehungen und Erwartungen klären – nicht Output liefern. Verstehe, wie das Team arbeitet, was kaputt ist, und leg mit deinem Vorgesetzten in einem Satz fest, was nach 90 Tagen „sichtbar besser" sein soll.

Dein größter Hebel ist nicht dein Code, sondern die psychologische Sicherheit im Team. In Googles Project Aristotle war sie der wichtigste einzelne Faktor für die Leistung eines Teams – wichtiger als die Zusammensetzung. Genau diese Sicherheit baust oder zerstörst du in den ersten Wochen.

Den Rollenwechsel explizit ansprechen, nicht aussitzen. Führe in Woche 1 ein ehrliches 1:1 mit jedem – besonders mit dem, der den Posten auch wollte.

Ändere bewusst Muster aus der Peer-Zeit („mach ich schnell für dich") und sei in Entscheidungen transparent statt kumpelhaft-vage. Du musst nicht beliebt sein. Du musst berechenbar und fair sein – das schlägt Beliebtheit in jeder schwierigen Situation, die noch kommt.

Woche 1 – Zuhören & Landschaft kartieren

1. Buche mit jedem Teammitglied ein 45-Min-1:1. Drei Fragen: Was läuft gut? Was nervt dich täglich? Was würdest du als Erstes ändern? (Remote: lieber zwei kürzere Video-1:1s als ein langes – und kein Gruppen-Call als Ersatz.)
2. Führe das schwierigste 1:1 zuerst – mit dem Kollegen, der den Posten auch wollte. Benenne die Situation offen.
3. Lies dich in Architektur, CI/CD und die letzten drei Incident-/Postmortem-Dokumente ein. Nicht um zu urteilen – um Kontext zu bekommen.
4. Frag deinen Vorgesetzten konkret: „Woran misst du in 90 Tagen, dass ich diese Rolle gut mache?" Notiere die Antwort in einem Satz.
5. Ändere noch nichts Strukturelles. Sag das auch laut – „die ersten Wochen höre ich zu." Laut sagen heißt nicht groß auftreten; eine kurze Nachricht im Team-Channel zählt genauso.

Tag 1–30 – Verstehen & verankern

1. Verdichte die 1:1-Erkenntnisse zu einer Schmerz-Liste und teile sie transparent („das habe ich verstanden").
2. Wähle einen Quick Win, der Dev-Schmerz senkt (was das heißt, siehe unten).
3. Mach Entscheidungsrechte sichtbar: Wer entscheidet Architektur, wer Tooling, wer Prioritäten?
4. Lege deinen Coding-Rahmen fest: Welche Tickets nimmst du (kein kritischer Pfad), welche nicht.

Tag 31–60 – Erste Hebel ziehen

1. Liefere den Quick Win – sichtbar, dem Team zugeschrieben.
2. Justiere den Review-Prozess: Wann reviewst du (Risiko/Architektur), wann gibt das Team eigenverantwortlich frei?
3. Hol strukturiert Feedback zu deiner Führung ein: „Was sollte ich als Lead anders machen?"
4. Prüfe ehrlich deinen Coding-Anteil. Über ~20 % und auf kritischem Pfad? Gib gezielt ab.

Tag 61–90 – Rolle festigen

1. Setz eine sichtbare Verbesserung am Team-Output um (Lead-Time, weniger Rework, klarere Done-Definition) – nicht an deinem eigenen.
2. Delegiere bewusst eine Aufgabe, die du „eigentlich besser selbst" machen würdest – und halt dich raus.
3. Führe das 90-Tage-Review mit deinem Vorgesetzten gegen den Satz aus Woche 1.

Muss ich der beste Entwickler im Team bleiben? Nein. Deine Autorität kommt aus guten Fragen, Kontext und Standards – nicht aus dem meisten Output. Erfolg heißt: Dein Team wird besser, auch in Bereichen, in denen du nicht der Beste bist.

Wie gewinne ich Respekt, wenn ich jetzt meine ehemaligen Kollegen führe? Indem du den Rollenwechsel offen ansprichst, in Entscheidungen berechenbar und fair bist und alte Peer-Muster bewusst neu rahmst. Fairness schlägt Beliebtheit.

Was, wenn ich nach 100 Tagen das Gefühl habe, nichts geschafft zu haben? Das ist normal – der Wechsel von Einzel-Output zu Team-Outcome fühlt sich anfangs „unproduktiv" an, weil sich dein Erfolgsmaßstab verschoben hat. Genau diesen Shift einzuordnen, statt in alte Coding-Reflexe zurückzufallen, ist die eigentliche Arbeit.

Was ist überhaupt der Unterschied zwischen Tech-Lead und Engineering Manager? Kurz: Der Tech-Lead führt über Technik, der Engineering Manager über Menschen. Ausführlich im Vergleich: Tech Lead vs. Engineering Manager.