Sechs Engineers in achtzehn Monaten zur Senior-Beförderung gecoacht

Ich bin skeptisch gegenüber Leadership-Fallstudien, die wie Methodiken klingen. Die ehrliche Version dieser Geschichte ist: Sechs spezifische Personen, in einem spezifischen Team, in einer spezifischen Firma, haben den Sprung zur Senior-Stufe in achtzehn Monaten geschafft. Ich hatte einen bedeutenden, aber nicht alleinigen Anteil daran. Die Teile, die generalisieren, sind nützlich; die, die es nicht tun, sind zumindest konkret.

Was ich hier nicht tun werde, ist sie zu nennen oder mit identifizierbaren Details zu beschreiben. Beide haben das gelesen und die Darstellung freigegeben.

Der Ausgangszustand

Ich übernahm Ende 2023 eine Squad von fünf. Zwei der fünf waren an einer „Mid II"-/„Senior I"-Grenze, solide in ihrer Spur, starke Individual Contributors, keiner von beiden auf dem Niveau, das das Calibration Grid Senior nannte. Verschiedene Lücken:

• Engineer A. Starke Ausführung, schwach beim Scoping. Konnte ein Feature einwandfrei ausliefern, hatte aber Mühe, sich gegen mehrdeutige Briefs zu wehren oder Trade-offs sichtbar zu machen. Default-Verhalten unter Druck: genau das tun, was verlangt wurde, schnell.
• Engineer B. Stark beim Scoping und der Architektur, schwach beim Dranbleiben. Brillante anfängliche Designs, dann eine Tendenz, im langen Tail aus Tests, Politur und Rollout Energie zu verlieren. Default-Verhalten: bei „Feature läuft auf meiner Maschine" Sieg erklären und zum nächsten interessanten Problem driften.

Beide waren seit mindestens einem Jahr „fast bereit", bevor ich kam. Das Team hatte zwei vorherige Tech Leads durchlaufen, die sie nicht über die Linie bringen konnten. Das war nützlicher Kontext, keiner war ein Selbstläufer, und der Weg nach vorn musste etwas adressieren, das vorherige Manager nicht angegangen waren.

Constraints

• Kalibrierung ist real. Die Senior-Latte bei diesem Unternehmen hat konkrete Kriterien: Scope, Autonomie, technische Tiefe, Leadership, Kommunikation, jeweils mit konkreten Beispielen. Beförderungs-Cases werden gesponsert, schriftlich vorgetragen und von einem Panel geprüft, das Engineering-Direktor:innen einschließt, die die Kandidat:innen nicht persönlich kennen. „Ich finde, sie sind senior" ist kein Case.
• Achtzehn Monate fühlten sich wie der richtige Horizont an. Lang genug, um aussagekräftige Evidenz zu produzieren; kurz genug, damit die Engineers motiviert blieben. Beide hatten Ungeduld signalisiert.
• Verspreche nichts, was ich nicht liefern kann. Beförderungs-Outcomes sind nicht unilateral. Ich kann werben, Evidenz formen, einen Case vorbereiten. Ich kann nicht garantieren, dass das Panel zustimmt.

Vorgehen

IDPs, die nicht wie HR-Dokumente klangen

Das Standard-IDP-Template hier ist okay, aber es tendiert dazu, Pläne zu erzeugen, die wie „Kommunikation verbessern" aussehen: nützlich für Calibration-Papierkram, nutzlos als Leitfaden. Ich schrieb beide IDPs als konkrete Checklisten neu, gebunden an Evidenz, nicht an Bestrebungen.

Für Engineer A:

ZIEL: Scoping-Autonomie auf mindestens drei Projekten zeigen.

EVIDENZ, nach der ich Ausschau halten werde:
- Ein schriftliches Scope-Dokument vor dem ersten PR auf einem Feature,
  das du besitzt.
- Mindestens ein Push-Back pro Projekt: ein Brief, den du
  hinterfragt oder umformuliert hast, mit der Begründung schriftlich.
- Eine Entscheidung, die du getroffen hast, mit der ich zum Zeitpunkt
  nicht einverstanden war und die mir später gefiel.

Für Engineer B:

ZIEL: End-to-End-Verantwortung über Rollout und Follow-up
demonstrieren.

EVIDENZ, nach der ich Ausschau halten werde:
- Drei Features von Kickoff bis „die Metriken haben sich bewegt",
  nicht nur „ausgeliefert".
- Ein schriftliches Postmortem zu mindestens einem Release, das nicht
  sauber ablief, von dir verfasst.
- Engagement mit Downstream-Konsumenten: mindestens ein
  vorausschauendes Gespräch pro Release mit jemandem, dessen Arbeit
  von deiner abhängt.

Das „Evidenz, nach der ich Ausschau halten werde" war der Unterschied. Es machte das IDP zu einer operativen Anleitung statt zu einem Performance-Review-Dokument. Wir gingen es monatlich in 1:1s durch.

Projekt-Allokation als Hauptenergiehebel

Das am meisten unterschätzte Werkzeug eines Tech Lead ist, wer welches Projekt bekommt. Die meisten Coaching-Gespräche der ersten sechs Monate fanden während der Projekt-Allokation statt, nicht in 1:1s. Ich gab beiden Engineers gezielt Projekte, die ihre Lücken trainierten:

• Engineer A bekam die nächsten zwei Features mit mehrdeutigen Briefs am Stück. Beide kamen mit vagen Produkt-Beschreibungen rein; ich bat Engineer A, das Scope-Dokument vor dem Code zu schreiben, und reviewte diese Scope-Dokumente so, wie es eine Senior-Reviewerin tun würde.
• Engineer B bekam zwei Features, bei denen der Rollout so schwer war wie der Bau. Eines beinhaltete eine Datenbankmigration mit Zero-Downtime-Anforderungen; eines beinhaltete Breaking-Change- Kommunikation mit einem Partner-Team. Beide wurden gewählt, weil es keinen Weg gab, früh „Sieg" zu rufen.

Allokation als Coaching-Tool erfordert, dass man die Projekte tatsächlich hat. Ich musste mehrfach gegenüber Product zurückschieben, um diese spezifischen Arbeitsformen flüssig zu halten. Das war ein eigenes Gespräch mit dem PM der Squad, der super dabei war, sobald ich das Warum erklärte.

Code-Review-Frequenz als Coaching-Oberfläche

Senior-Engineers hinterlassen Senior-Code-Reviews. Ich wollte, dass die Reviews beider Engineers so klingen. Also schatten-reviewte ich in den ersten sechs Monaten jeden PR, den sie reviewten, nicht als zusätzliche Reviewerin am PR, sondern in unseren 1:1s, mit einer spezifischen Struktur:

„Hol die letzten fünf PRs raus, die du reviewt hast. Geh mit mir durch, worauf du geachtet hast, was du kommentiert hast, was du nicht kommentiert hast, aber bemerkt hast, und was du übersehen hast."

Das Muster, das auftauchte: Beide Engineers reviewten Code gut auf Zeilen-Ebene, und kommentierten selten Architektur, Scope oder was einem Diff fehlte. Sechs Monate gezielter Aufmerksamkeit später hinterließen beide routinemäßig Review-Kommentare auf Architektur-Ebene. Wir hörten mit dem Schatten-Review-Übung auf, sie hatte ihren Zweck erfüllt.

Kalibrierungs-Übung aufeinander

In der Mitte des Zyklus ließ ich beide Engineers eine Mock-Kalibrierung an der Arbeit des anderen machen. Das Calibration-Grid hochgezogen, drei aktuelle Projekte pro Person ausgewählt und sie gebeten, einzuschätzen, wo die Arbeit der Kollegin auf jedem Kriterium landete. Sie waren strengere Bewerter als ich, ein Signal, dass sie die Latte besser verstanden, als ich ihnen zugetraut hatte.

Das brachte auch Lücken ans Licht, die sie an der jeweils anderen Person bemerkt hatten. Engineer A hatte Engineer B Feedback zur Follow-Through-Lücke geben wollen und keinen Frame dafür gefunden. Die Kalibrierungs-Übung gab ihm einen.

Die Beförderungs-Cases

Ich schrieb beide Cases am Achtzehn-Monats-Punkt parallel.

Ein Beförderungs-Case hier ist grob:

1. Headline-Zusammenfassung. Ein Absatz, von der Managerin geschrieben, zur Begründung für die Beförderung.
2. Evidenz pro Kriterium. Zwei bis drei konkrete Beispiele pro Calibration-Dimension. „Demonstrierte technische Tiefe: führte die Untersuchung des Dataloader-Cache-Key-Bugs; schrieb das Postmortem; entwarf den Fix, der in Woche 5 landete."
3. Selbstreflexion. Vom Engineer geschrieben, eine Seite, was sie glauben, hineingewachsen zu sein, und wo die Lücken noch sind.
4. Sponsor. Ein Senior-Engineer außerhalb des Teams, der mit der Kandidat:in gearbeitet hat und unabhängig zu ihrem Case sprechen kann.

Beide Cases gingen ans Panel, beide gingen durch. Einer beim ersten Versuch, einer beim zweiten nach einer Panel-Revisionsanfrage, Engineer Bs Case kam mit dem Feedback zurück, dass die Cross-Team-Scope-Evidenz nicht stark genug war. Wir fügten ein weiteres Projekt an Evidenz hinzu und stellten erneut vor; er ging durch.

Ergebnis

Die Zeile „noch im Team" zählt mehr als die anderen. Beförderungs-Cases, die dazu führen, dass Leute innerhalb eines Quartals nach der Beförderung gehen, sind ein Zeichen dafür, dass es um Retention ging, nicht um Bereitschaft. Beide Engineers blieben und haben seither selbst Tech-Lead-Track-Arbeit übernommen.

Was ich anders machen würde

Ich hätte die Sponsor-Gespräche sechs Monate früher begonnen. Der Sponsor ist der Teil des Cases, über den ich am wenigsten Kontrolle habe. Sie müssen genug von der Arbeit der Engineer:in beobachtet haben, um unabhängig sprechen zu können. Speziell für Engineer B war die Cross-Team-Evidenz-Lücke ebenso eine Sponsor- Lücke wie eine Evidenz-Lücke, die einzige Senior-Engineer:in, die eng mit ihm gearbeitet hatte, war innerhalb unserer Squad. Potenzielle Sponsors in Monat sechs zu identifizieren statt in Monat sechzehn, hätte die Panel-Revision verhindert.

Ich hätte früher ehrlicher zu denen sein sollen, die es nicht schaffen würden. Ich hatte einen dritten Engineer im Team, von dem ich insgeheim hoffte, er würde in diesem Fenster auch Senior erreichen. Er war weiter von der Latte entfernt als die anderen zwei, und ich war in den ersten sechs Monaten nicht direkt genug darüber. Bis ich es war, hatte es ihn Sichtbarkeit auf die Art von Projekten gekostet, die seinen Case aufgebaut hätten. Das geht auf mich.

Ich hätte das IDP-Framework aufgeschrieben, statt es jedes Mal neu zu erfinden. Ich nutze die gleiche evidenzbasierte IDP-Form für die Engineers, die ich gerade coache, aber ich habe sie beim zweiten Mal von Grund auf gebaut. Ein kurzes internes Dokument, „wie ich IDPs schreibe, die nicht performativ sind", hätte einen Abend Arbeit gespart und anderen Manager:innen geholfen, mit denen ich überlappe.