Der Wechsel vom Entwickler zum Tech Lead ist keine Beförderung im Sinne von “dasselbe, nur höher” — es ist ein Berufswechsel mit demselben Arbeitgeber. Die Fähigkeiten, die dich zum besten Dev im Team gemacht haben, sind ab jetzt nicht mehr dein Job, sondern nur noch dein Fundament. Wer das nicht versteht, wird ein schlechter Lead und ein frustrierter Mensch — oft beides gleichzeitig.
Ich führe technische Projekte mit Kunden, koordiniere Mitwirkende in eigenen Vorhaben und habe in Teams auf beiden Seiten der Rolle gesessen. Das hier ist der Realitätsabgleich, den ich mir vor dem ersten Lead-Anteil gewünscht hätte.
Die Kalender-Realität: Dein Tag gehört nicht mehr dir
Der erste Schock ist banal und trifft trotzdem jeden: Dein Kalender. Als Dev hattest du zusammenhängende Stunden für tiefe Arbeit, unterbrochen von wenigen Meetings. Als Lead dreht sich das um — Abstimmungen, 1:1s, Planungsrunden, Stakeholder-Fragen, Reviews, Unblocking. Deine Arbeit besteht jetzt zu einem großen Teil aus Gesprächen, und das ist kein Fehler im System: Es ist der Job.
Das Problem entsteht, wenn du versuchst, dein altes Entwicklungspensum obendrauf zu halten. Dann codest du abends “in Ruhe nach”, brennst aus und machst beide Jobs mittelmäßig. Die ehrliche Anpassung: Plane als Lead realistisch nur noch einen Bruchteil deiner Zeit für eigenen Code ein — und wähle diesen Code strategisch. Gut geeignet: Prototypen, Tooling, unkritische Randstücke. Schlecht geeignet: alles auf dem kritischen Pfad, denn du bist ab jetzt die Person mit den meisten Unterbrechungen und der unzuverlässigsten Verfügbarkeit im Team. Der Lead, der den kritischen Release-Blocker hält und dann drei Tage in Meetings verschwindet, ist ein Klassiker — sei nicht dieser Lead.
Code loslassen: Der schmerzhafteste Teil
Das Schwerste am Rollenwechsel ist nicht das Neue, sondern das Loslassen des Alten. Konkret heißt das: Andere schreiben jetzt den Code, den du schneller und vielleicht besser geschrieben hättest — und du lässt sie, weil das Team sonst nie schneller wird als du allein.
Zwei Muster, an denen scheiternde Leads erkennbar sind: Das erste ist der Lead als Flaschenhals — jede wichtige Entscheidung, jedes Review, jede Architekturfrage läuft über ihn. Fühlt sich nach Kontrolle an, ist aber ein Single Point of Failure mit Burnout-Garantie. Das zweite ist Rückdelegation an sich selbst: Ein Task ist halb fertig, der Lead “macht es schnell selbst fertig”. Jedes Mal, wenn du das tust, lernt das Team: Halbfertig reicht, der Lead übernimmt schon. Du trainierst deinem Team die Verantwortung ab.
Die Alternative ist unbequemer und wirksamer: Standards setzen statt Ergebnisse selbst produzieren. Klare Definition of Done, gute Review-Kultur, Architektur-Leitplanken, die das Team selbst anwenden kann. Dein Output misst sich ab jetzt nicht an deinen Commits, sondern daran, was das Team ohne dich hinbekommt. Der beste Lead ist der, dessen Urlaub niemand am Output merkt — das kratzt am Ego, und genau daran erkennst du, ob du die Rolle wirklich willst.
Delegieren ist ein Handwerk, kein Charakterzug
“Ich kann schlecht delegieren” klingt wie eine Persönlichkeitseigenschaft, ist aber meist nur fehlende Technik. Die Kernpunkte, die den Unterschied machen:
- Delegiere Ergebnisse, nicht Arbeitsschritte. “Bau die Export-Funktion, hier sind die Anforderungen und Constraints” statt einer Schritt-für-Schritt-Anleitung. Wer nur Schritte bekommt, denkt nicht mit — und du hast trotzdem die ganze Denkarbeit.
- Delegiere Dinge, die du gern behalten würdest. Die spannenden Aufgaben nur bei dir zu horten und Routine zu verteilen, demotiviert genau die Leute, die du entwickeln willst.
- Akzeptiere die 80-Prozent-Lösung. Die Umsetzung wird anders als deine — anders heißt nicht schlechter. Korrigiere nur, was echte Folgen hat (Sicherheit, Wartbarkeit, Architektur), nicht Geschmack.
- Bau ein Frühwarnsystem statt Kontrolle. Kurze Check-ins an vereinbarten Punkten, nicht tägliches Über-die-Schulter-Schauen. Micromanagement ist nur die Angst vor Delegation in Aktivitäts-Verkleidung.
Die neuen Kern-Skills: Übersetzen und entscheiden
Zwei Fähigkeiten dominieren den Lead-Alltag, und beide werden im Dev-Dasein kaum trainiert. Die erste ist Übersetzung: Du bist die Schnittstelle zwischen Technik und Rest der Welt. Nach oben übersetzt du technische Realität in Konsequenzen (“Wenn wir das Refactoring schieben, kostet jedes Feature ab Q3 doppelt”) statt in Fachjargon. Nach unten übersetzt du Geschäftsdruck in sinnvolle Prioritäten, ohne jede Panik ans Team durchzureichen — du bist auch Puffer, nicht nur Durchleitung.
Die zweite ist Entscheiden unter Unklarheit. Als Dev konntest du bei Architektur-Debatten die beste Lösung suchen; als Lead musst du Debatten auch beenden. Eine gute Entscheidung heute schlägt die perfekte in drei Wochen — und manchmal ist deine wichtigste Leistung, eine Entscheidung zu treffen, damit acht Leute weiterarbeiten können. Dokumentiere die Begründung kurz (ein Absatz reicht), damit sie später nachvollziehbar bleibt, und korrigiere offen, wenn du falsch lagst. Nichts baut schneller Vertrauen auf als ein Lead, der Irrtümer zugibt, und nichts zerstört es schneller als einer, der sie umdeutet.
Willst du das überhaupt? Die ehrliche Vorab-Prüfung
Der wichtigste Absatz zum Schluss: Tech Lead ist keine Belohnung für guten Code, und es nicht zu wollen ist keine Schwäche. Der Karriere-Mythos, dass nach Senior zwangsläufig Führung kommt, ist in guten Firmen längst durch IC-Pfade (Staff, Principal) ersetzt — tief technische Karrieren ohne Personalverantwortung, oft gleich bezahlt. Prüfe dich ehrlich: Gibt dir es Energie, wenn andere durch deine Hilfe besser werden — oder nur, wenn du selbst das Problem löst? Erträgst du Tage, an denen dein sichtbares Ergebnis “drei gute Gespräche” ist? Wenn nein, ist der IC-Pfad kein Trostpreis, sondern deine richtige Antwort.
Und falls du gerade mitten im Wechsel steckst und merkst, dass niemand dich darauf vorbereitet hat: Damit bist du nicht allein — die meisten Leads lernen die Rolle im freien Fall. Im Discord der Community sind einige unterwegs, die diesen Wechsel hinter sich haben und ehrlich davon erzählen.