Du bist ein guter Entwickler. Vielleicht einer der Besten im Team. Jetzt steht die Frage im Raum: Tech Lead werden? Dieser Guide zeigt dir, was dich erwartet – ohne Schönfärberei.
Was ist ein Tech Lead eigentlich?
Die Rolle verstehen
Ein Tech Lead ist NICHT:
- Ein Senior Developer mit Titel
- Der beste Coder im Team
- Ein Manager in Verkleidung
Ein Tech Lead IST:
- Technischer Entscheider
- Multiplikator für das Team
- Brücke zwischen Business und Engineering
- Coach für andere Entwickler
Das Verhältnis: Coden vs. Führen
| Team-Größe | Coding | Tech Leadership | Management |
|---|---|---|---|
| 2-3 Devs | 70% | 25% | 5% |
| 4-6 Devs | 50% | 40% | 10% |
| 7-10 Devs | 30% | 50% | 20% |
| 10+ Devs | 10-20% | 50% | 30% |
Die unbequeme Wahrheit: Je größer dein Team, desto weniger codest du.
Die 5 Hauptaufgaben eines Tech Leads
1. Technische Entscheidungen treffen
Was das bedeutet:
- Architektur-Entscheidungen
- Technologie-Auswahl
- Trade-offs abwägen
- Langfristige Richtung vorgeben
Typische Entscheidungen:
- Microservices vs. Monolith
- Build vs. Buy
- Welches Framework
- Wann refactoren, wann neu bauen
Der Unterschied zum Senior Dev: Als Senior gibst du Empfehlungen. Als Lead trägst du die Verantwortung für die Entscheidung – und ihre Konsequenzen.
2. Code Quality sicherstellen
Was das bedeutet:
- Code Reviews (oder: Review-Kultur etablieren)
- Standards definieren
- Technische Schulden managen
- Testing-Strategie
Praktisch:
- Review Checklist erstellen
- Pair Programming oder Mob Programming fördern
- Architektur-Dokumentation pflegen
- Tech Debt Backlog führen
- Reverse Mentoring mit Junioren etablieren
Wichtig: Du musst nicht jeden PR reviewen. Du musst sicherstellen, DASS Reviews stattfinden und qualitativ hochwertig sind.
3. Team-Produktivität maximieren
Was das bedeutet:
- Blocker entfernen
- Prozesse optimieren
- Tools und Infrastruktur bereitstellen
- Fokus-Zeit schützen
Typische Blocker:
- Unklare Requirements
- Fehlende Zugänge
- Technische Schulden
- Meetings-Overload
Deine Aufgabe: Diese Blocker aus dem Weg räumen, BEVOR sie das Team ausbremsen.
4. Technische Vision kommunizieren
Was das bedeutet:
- Warum bauen wir das SO?
- Wohin entwickelt sich die Architektur?
- Wie passt das in die Gesamt-Strategie?
Mit wem kommunizieren:
- Team: Kontext für Entscheidungen
- Product: Technische Constraints erklären
- Stakeholder: Risiken und Trade-offs
Skill: Komplexes einfach erklären können – für unterschiedliche Zielgruppen.
5. Talente entwickeln
Was das bedeutet:
- Mentoring
- Wachstum ermöglichen
- Stärken fördern
- Feedback geben
Praktisch:
- 1:1s mit Team-Mitgliedern
- Stretch Assignments vergeben
- Wissen teilen (Brown Bags, Docs)
- Raum für Fehler lassen
Die größten Fehler neuer Tech Leads
Fehler 1: Alles selbst machen wollen
Das Problem: Du siehst einen Bug. Du könntest ihn in 5 Minuten fixen. Also machst du es selbst.
Warum das schadet:
- Du skalierst nicht
- Team lernt nicht
- Du brennst aus
Die Lösung: Delegieren lernen. Ja, es dauert länger. Ja, es ist manchmal frustrierend. Aber es ist der einzige Weg, ein Team zu skalieren.
Die 70%-Regel: Wenn jemand anderes die Aufgabe zu 70% so gut machen kann wie du, delegiere.
Fehler 2: Nicht mehr coden
Das Problem: Du bist so beschäftigt mit Meetings, dass du den Code nicht mehr kennst.
Warum das schadet:
- Du verlierst technische Glaubwürdigkeit
- Du triffst uninformierte Entscheidungen
- Du kannst nicht mehr mentoren
Die Lösung: Block "Coding Time" in deinem Kalender. 2-3 fokussierte Stunden pro Tag, nicht verhandelbar.
Was coden:
- Prototypen für neue Features
- Kritische Infrastruktur
- Code Reviews
- Technische Spikes
Fehler 3: Mikro-Management
Das Problem: Du reviewst jeden Commit, bist in jeder Diskussion, gibst zu jedem Detail Feedback.
Warum das schadet:
- Team fühlt sich nicht vertraut
- Entscheidungen stauen sich bei dir
- Du wirst zum Bottleneck
Die Lösung: Ergebnisse definieren, Weg frei lassen. "Das Ziel ist X. Wie ihr dahin kommt, entscheidet ihr."
Fehler 4: Konflikte vermeiden
Das Problem: Zwei Teammitglieder sind sich uneinig. Du hoffst, es löst sich von selbst.
Warum das schadet:
- Konflikte eskalieren
- Passive Aggression
- Produktivität sinkt
Die Lösung: Konflikte früh adressieren. Nicht urteilen, sondern moderieren. Gemeinsam Lösungen finden.
Fehler 5: Stakeholder ignorieren
Das Problem: Du fokussierst dich auf das Team und vergisst Product, Management, andere Teams.
Warum das schadet:
- Überraschende Anforderungen
- Mangelndes Verständnis für Tech-Arbeit
- Ressourcen-Konflikte
Die Lösung: Regelmäßige Sync-Meetings. Proaktiv kommunizieren. Transparenz über Status und Risiken.
Die Skills, die du entwickeln musst
Technische Skills (weiterhin wichtig)
- Architektur-Denken: System-Design, nicht nur Code
- Breite über Tiefe: Überblick über viele Technologien
- Technische Kommunikation: RFCs, ADRs, Dokumentation
Soft Skills (jetzt kritisch)
Kommunikation:
- Zuhören (wirklich zuhören)
- Feedback geben (konstruktiv, konkret)
- Präsentieren (für verschiedene Audiences)
- Schriftlich kommunizieren (Klarheit, Struktur)
Leadership:
- Delegieren
- Vertrauen aufbauen
- Entscheidungen treffen (auch mit unvollständigen Infos)
- Verantwortung übernehmen
Empathie:
- Perspektive wechseln
- Motivation verstehen
- Frustrationen erkennen
- Individuelle Bedürfnisse berücksichtigen
Der Übergang: Die ersten 90 Tage
Tag 1-30: Beobachten und Verstehen
Ziele:
- Team kennenlernen
- Prozesse verstehen
- Quick Wins identifizieren
- Vertrauen aufbauen
Aktivitäten:
- 1:1s mit allen Team-Mitgliedern
- Code-Basis durcharbeiten
- Architektur-Dokumentation lesen (oder feststellen, dass keine existiert)
- Stakeholder kennenlernen
Nicht tun:
- Große Veränderungen ankündigen
- "Bei meinem alten Job haben wir..."
- Sofort alles umbauen wollen
Tag 31-60: Erste Verbesserungen
Ziele:
- Erste Blocker entfernen
- Prozesse optimieren
- Sichtbare Verbesserungen
Aktivitäten:
- Ein konkretes Problem lösen
- Review-Prozess verbessern
- Technische Dokumentation starten
- Team-Rituale etablieren
Tag 61-90: Langfristige Richtung
Ziele:
- Technische Vision entwickeln
- Roadmap für technische Verbesserungen
- Team-Entwicklung planen
Aktivitäten:
- Tech-Strategie-Dokument
- Architektur-Entscheidungen dokumentieren
- Individuelle Entwicklungspläne
- Regelmäßige Retros
Tools und Frameworks
Für Architektur-Entscheidungen
Architecture Decision Records (ADRs):
# ADR-001: Verwendung von PostgreSQL als Primärdatenbank
## Status
Akzeptiert
## Kontext
Wir brauchen eine relationale Datenbank für Transaktionsdaten.
## Entscheidung
Wir verwenden PostgreSQL.
## Konsequenzen
+ Open Source, keine Lizenzkosten
+ Team-Erfahrung vorhanden
- Kein managed Service im aktuellen Stack
Für 1:1s
Struktur:
- Check-in (5 min)
- Ihre Themen (15 min)
- Deine Themen (10 min)
- Karriere/Entwicklung (10 min)
- Action Items (5 min)
Fragen:
- "Was blockiert dich gerade?"
- "Worauf bist du stolz?"
- "Was würdest du ändern, wenn du könntest?"
- "Wie kann ich dir besser helfen?"
Für Priorisierung
RICE-Framework:
- Reach: Wie viele Nutzer betroffen?
- Impact: Wie stark ist der Effekt?
- Confidence: Wie sicher sind wir?
- Effort: Wie aufwändig?
Score = (Reach × Impact × Confidence) / Effort
Ist Tech Lead das Richtige für dich?
Zeichen, dass es passt:
- Du hilfst gern anderen, besser zu werden
- Du denkst in Systemen, nicht nur in Code
- Du kannst komplexes einfach erklären
- Du triffst gern Entscheidungen
- Du kannst mit Ambiguität umgehen
Zeichen, dass es nicht passt:
- Du codest am liebsten ungestört 8 Stunden
- Meetings frustrieren dich grundsätzlich
- Du willst keine Verantwortung für andere
- Politik und Stakeholder-Management sind dir zuwider
- Du definierst dich über Code-Output
Die Alternative: Staff Engineer
Nicht jeder muss Lead werden. Der Individual Contributor Pfad:
- Senior → Staff → Principal → Distinguished Engineer
- Mehr technische Tiefe, weniger People Management
- Einfluss über Expertise, nicht über Hierarchie
Fazit
Tech Lead werden ist ein Karriere-Wechsel, nicht nur eine Beförderung. Du tauschst einen Teil deiner Coding-Zeit gegen Leadership-Aufgaben.
Die Belohnung: Größerer Impact. Du skalierst durch andere. Du formst nicht nur Code, sondern Teams und Kulturen.
Die Herausforderung: Neue Skills, neue Fehler, neue Frustrationen. Der beste Coder zu sein reicht nicht mehr.
Wenn das klingt, als könnte es zu dir passen – probier es aus. Wenn nicht – das ist völlig okay. Die Welt braucht auch exzellente Individual Contributors.
Du stehst vor technischen Entscheidungen wie Build vs. Buy? Unser Build vs. Buy Framework hilft bei der systematischen Entscheidungsfindung.
