Ich habe Frontend-Teams von 3 und Teams von 13 Personen geführt. Ich habe Entwickler in einer Startup-Agentur in Bergamo geleitet, Senior Engineers bei AXA Schweiz und crossfunktionale Squads bei Migros und UBS. Teamgrössen, Tech-Stacks und Branchen waren jedes Mal anders. Aber die Muster, die Teams erfolgreich machen? Die sind bemerkenswert konsistent.
Dies ist kein Beitrag über Agile-Zeremonien oder OKRs. Es geht darum, was ich tatsächlich als funktionierend erlebt habe, wenn deine Aufgabe ist, eine Gruppe von Frontend-Entwicklern effektiver zu machen als die Summe ihrer Teile.
Technische Vision ohne Diktatur
Die grösste Falle für Technical Leads ist, zum Flaschenhals zu werden. Du hast Meinungen, du hast Erfahrung, und du kannst die Lösung wahrscheinlich schneller architektonisch entwerfen als jeder in deinem Team. Aber wenn jede Entscheidung über dich läuft, hast du einen Single Point of Failure geschaffen — und du hast deinem Team das Wachstum geraubt, das aus dem eigenen Entscheiden kommt.
Bei AXA, als ich das Style-Guide-Team gründete und eine framework-übergreifende Komponentenbibliothek mit Web Components baute, habe ich nicht jede Komponente selbst entworfen. Ich setzte die architektonische Richtung — Web Components für Framework-Agnostik, ein klares API-Contract-Pattern, Barrierefreiheit als unverzichtbar — und liess dann Engineers ihre Komponenten end-to-end besitzen. Das Ergebnis war besser als das, was ich allein gebaut hätte, weil verschiedene Entwickler Perspektiven einbrachten, die ich nicht bedacht hatte.
Mein Ansatz: Grenzen und Einschränkungen klar definieren, dann maximale Freiheit innerhalb dieser Grenzen geben. Bei UBS, wo ich 13 Frontend-Entwickler in verschiedenen Bereichen manage, setze ich die Muster dafür, wie unsere Anwendungen strukturiert sein sollten, wie State fliessen sollte und wie wir gemeinsame Anliegen behandeln. Aber innerhalb dieser Leitplanken trifft jedes Squad seine eigenen Implementierungsentscheidungen.
Code Review als Mentoring
Code Review ist die wirkungsvollste Aktivität, die ein Tech Lead hat. Nicht weil es Bugs findet — das sollten deine Tests tun — sondern weil es ein Eins-zu-eins-Lehrmoment mit unmittelbarem, konkretem Kontext ist.
Ich reviewe Code unterschiedlich, je nachdem wer ihn geschrieben hat. Ein Junior-Entwickler bekommt detailliertes Feedback zu Patterns und Prinzipien. Ein Mid-Level-Entwickler bekommt Fragen, die ihn dazu bringen, über verpasste Edge Cases nachzudenken. Ein Senior-Entwickler bekommt architektonische Diskussionen über Trade-offs.
Der Schlüssel ist, niemals nur „ändere das" zu sagen. Erkläre immer warum. „Das verursacht ein Re-Render bei jeder Zustandsänderung, weil sich die Objektreferenz ändert — überlege useMemo hier" vermittelt etwas Übertragbares. „Nutze useMemo" vermittelt nichts.
Ich habe Reviewer manchmal ermutigt, neben ihrem Feedback einen «Lernkommentar» zu hinterlassen — keinen Änderungsantrag, nur eine Beobachtung über etwas Interessantes im Code, ein erwähnenswertes Pattern oder eine mögliche Verbesserung für nächstes Mal. Es half, Reviews von einer reinen Gatekeeper-Übung hin zum Wissensaustausch zu verschieben.
Einstellung und Onboarding
Das Team, das du aufbaust, bestimmt die Software, die du lieferst. Ich habe Entwickler in mehreren Ländern eingestellt und eingearbeitet, und die wichtigste Eigenschaft, nach der ich suche, ist nicht Framework-Wissen — es ist die Fähigkeit, wie ein Ingenieur zu denken.
Was heisst das konkret? Ich suche Leute, die keine Fanboys einer bestimmten Technologie sind. React, Angular, Vue, Svelte — alles Werkzeuge, und ein guter Ingenieur wählt das richtige Werkzeug für die richtige Aufgabe. Wenn mir jemand sagt, sein Stack sei «der beste», ohne zu erklären wofür, ist das ein Warnsignal. Wenn jemand erklären kann, warum er je nach Rahmenbedingungen — Teamgrösse, Zeitplan, bestehende Infrastruktur, langfristige Wartbarkeit — einen Ansatz dem anderen vorzieht, dann ist das die Person, die ich in meinem Team will.
Ich kann jemandem React in einem Monat beibringen. Ich kann ihnen nicht beibringen zu beurteilen, ob eine Library das Hinzufügen wert ist, ob ein Pattern skaliert oder ob eine Abstraktion dem Team dient oder nur dem eigenen Ego. Das sind Urteilsentscheidungen, die aus Erfahrung und intellektueller Ehrlichkeit kommen.
Für das Onboarding nutze ich einen gestuften Ansatz: Woche eins ist Code lesen und Fragen stellen, Woche zwei sind kleine Bugfixes mit Paired Review, Woche drei ist ein kleines Feature. In Woche vier tragen die meisten Entwickler bereits sinnvoll bei. Der Schlüssel ist, es sicher zu machen, „dumme" Fragen zu stellen — denn in meiner Erfahrung zeigt die „dumme" Frage meist auf etwas, das das Team ignoriert hat.
Technische Schulden sind ein Gespräch, kein Backlog
Jedes Team, dem ich beigetreten bin, hatte ein „Tech Debt"-Backlog, das niemand anrührte. Tickets mit „Refactor X" oder „Upgrade Y", die ständig deprioritisiert wurden, weil sie keinen sichtbaren Business Value lieferten.
Mein Ansatz ist anders: Technische Schulden werden neben Feature-Arbeit adressiert, nicht stattdessen. Wenn du ein Feature in einem Modul baust, das Schulden hat, räumst du dieses Modul als Teil der Feature-Arbeit auf. Boy-Scout-Regel auf Modul-Ebene.
Bei Vontobel, beim Aufbau der Markets-Plattform, hatten wir eine Legacy-CMS-Integration, mit der die Arbeit schmerzhaft war. Statt ein Epic „CMS-Layer refactoren" zu erstellen, das nie besetzt würde, verbesserten wir die Integration schrittweise — jedes Feature, das CMS-Daten berührte, hinterliess diese Schicht etwas sauberer. Innerhalb von zwei Quartalen war die Integration solide, und wir mussten nie einen „Tech-Debt-Sprint" vor dem Business rechtfertigen.
Das erfordert Disziplin vom Team Lead: Du musst Feature-Arbeit so scopen, dass die Bereinigung enthalten ist, und diesen Scope im Sprint Planning verteidigen. „Dieses Feature ist 5 Punkte, nicht 3, weil wir den Data Layer reparieren müssen, von dem es abhängt" ist ein Gespräch, das ich hunderte Male geführt habe.
Die menschliche Seite
Der schwierigste Teil beim Führen von Entwicklern ist nicht die Technologie — es sind die Menschen. Entwickler haben Egos (mich eingeschlossen). Sie haben schlechte Wochen. Sie sind untereinander und mit dir uneins. Sie wechseln zu anderen Firmen. Sie brennen aus.
Was ich gelernt habe: Transparenz baut Vertrauen schneller auf als alles andere. Teile die Begründung hinter Entscheidungen, auch unbequemen. Wenn ein Projekt hinter dem Zeitplan liegt, sag es und erkläre den Plan. Wenn du eine Fehlentscheidung getroffen hast, steh öffentlich dazu. Dein Team wird dem Standard folgen, den du setzt.
Bei UBS lege ich grossen Wert auf das, was ich „bereichsübergreifende Kohäsion" nenne — sicherstellen, dass Entwickler, die an verschiedenen Teilen des Produkts arbeiten, sich als ein Team fühlen, nicht als isolierte Squads, die zufällig ein Repo teilen. Regelmässige teamübergreifende Code Reviews, gemeinsame Architectural Decision Records und rotierende Pair-Programming-Sessions über Bereichsgrenzen hinweg tragen alle dazu bei.
Ein Frontend-Team zu führen bedeutet, eine Umgebung zu schaffen, in der gute Entscheidungen natürlich entstehen — wo Entwickler den Kontext, die Werkzeuge und die psychologische Sicherheit haben, um ihre beste Arbeit zu leisten. Der technische Teil ist wichtig, aber er ist die einfachere Hälfte.