Beförderungs- und Leistungsgespräche, die Engineers respektieren

Ein Senior Engineer in einem Team, mit dem ich zusammengearbeitet habe, kündigte in der Woche nach seinem "Übertrifft Erwartungen"-Review. Nicht wegen der Bewertung. Weil das Beförderungspaket zwei Tage später in der Kalibrierung abgelehnt wurde und niemand, weder sein EM noch der skip-level, ihn gewarnt hatte, dass es eine 50-50-Sache war. Er hatte achtzehn Monate lang gehört "du machst das hervorragend." Die Geschichte, die er seinem Netzwerk beim Abgang erzählte, war einfach: Mein Manager wusste es entweder nicht, oder er wusste es und hat es mir nicht gesagt. Beide Varianten schaden bei der Personalgewinnung.

Halbjahreszyklen verdichten sechs Monate unausgesprochener Signale in ein 45-minütiges Gespräch. Was Sie nicht aufgeschrieben haben, hat nicht stattgefunden. Was Sie im Mai nicht benannt haben, kann im Oktober nicht nachträglich zählen, nur weil Sie es während der Kalibrierungsvorbereitung erinnert haben. Dieser Playbook richtet sich an Engineering Manager, die möchten, dass ihre Engineers nach jedem Review in der Lage sind, das Ergebnis selbst vorherzusagen, anhand von Artefakten, die bereits schriftlich vorliegen.

Beförderungskriterien als Belegliste, nicht als Meinungen

Der schnellste Weg, das Vertrauen eines Engineers zu verlieren, ist eine Beförderungsentscheidung mit Adjektiven zu verteidigen. "Starke technische Führungsqualitäten." "Großartige teamübergreifende Wirkung." "Außergewöhnliche Eigenverantwortung." Keines dieser Worte bedeutet einem Engineer mit einem abgelehnten Paket etwas. Er will den Beleg.

Führen Sie Beförderungen nach einem Vier-Spalten-Raster durch, das an ausgelieferte Arbeit geknüpft ist:

Beachten Sie, was nicht im Raster steht: Bauchgefühl, Seniorität nach Betriebszugehörigkeit, "hat sich im Raum wie ein Staff Engineer angefühlt." So verliert man einen Kalibrierungsstreit. Die obigen Spalten sind der Weg, ihn zu gewinnen.

Wenn Sie sich hinsetzen, um ein Paket zu schreiben, lautet die Frage nicht mehr "Ist Priya bereit für Staff?", sondern "Hat Priya drei org-weit übernommene Designdokumente, zwei vollständig verantwortete Services und ein Quartal, in dem sie mindestens fünf Engineers entsperrt hat?" Wenn sie zwei Designdokumente hat, sind Sie noch nicht bereit, sie aufzustellen. Wenn sie vier hat und das Incident Command bei einem P0, haben Sie einen Fall.

Zeigen Sie die Latte mit konkreten Beispielen. "Auf Staff-Ebene erwarten wir Arbeit wie Marcos Payments-Rewrite-RFC oder Lins Retry-Budget-Framework." Generische Stufen in einem Wiki sind kein Beleg. Echte genehmigte Pakete schon.

Der Begleitartikel zu diesem Playbook ist die Staff-Software-Engineer-Stellenbeschreibung. Der Verantwortungsbereich, die Wirkung und der Multiplikatoreffekt in Ihrem Beförderungsraster sollten wortgetreu mit dieser Stellenbeschreibung übereinstimmen. Wenn Ihr Raster "trifft Architekturentscheidungen" sagt, Ihre Stellenbeschreibung aber "verantwortet Multi-Service-Systemdesign", kalibrieren Ihre Engineers gegen zwei verschiedene Maßstäbe.

Der 6-Monats-Sichtbarkeitsplan

Der häufigste Grund, warum Beförderungspakete scheitern, ist nicht, dass der Engineer sich nicht weiterentwickelt hat. Es ist, dass niemand davon wusste. Ein Staff-Kandidat, der großartige Arbeit in drei internen Tickets geleistet hat, von denen niemand außerhalb des Teams Bescheid weiß, ist ein Staff-Kandidat, dessen Paket in der Kalibrierung scheitert. Sichtbarkeit ist ein Lieferergebnis.

Im ersten Monat jedes Halbzyklus setzen Sie sich mit jedem Engineer, der innerhalb der nächsten 12 Monate ein Beförderungskandidat ist, zusammen und erarbeiten gemeinsam einen 6-Monats-Sichtbarkeitsplan. Vier Artefakte, unterzeichnet und datiert:

1. Ein Stretch-Projekt mit einem namentlich genannten Executive Sponsor und einem sichtbaren Lieferumfang (mehr zur Falle unten).
2. Ein teamübergreifendes Artefakt: ein RFC, den ein anderes Team übernimmt, eine Integration, die ein anderer EM namentlich nennen kann, eine Migration, die ein Tech-Debt-Ticket zwei Orgs weiter geschlossen hat.
3. Ein Mentoring-Ergebnis: ein Junior, der befördert wird, ein neues Teammitglied, das in 30 statt in 90 Tagen produktiv wird, eine Hiring-Loop, die er geleitet hat.
4. Ein schriftliches Designdokument, das das Review besteht und innerhalb von 6 Monaten von jemandem außerhalb des unmittelbaren Teams zitiert wird.

Dieses Dokument kommt in einen gemeinsamen Ordner. Beide unterschreiben es. Jetzt gibt es keine Unklarheit darüber, woran der nächste Zyklus gemessen wird, und der Engineer kann sich im dritten und fünften Monat selbst prüfen, anstatt erst am Kalibrierungstisch davon zu erfahren.

Wenn er alle vier liefert, schreibt sich das Paket von selbst. Wenn er zwei von vier liefert, weiß er im vierten Monat (nicht am Review-Tag), dass das Paket noch nicht bereit ist, und hat die Chance zur Kurskorrektur oder zur Akzeptanz einer 6-monatigen Verzögerung, ohne dass es sich wie ein Vertrauensbruch anfühlt.

Das schwierige Leistungsgespräch: SBI, Bitte und Commitment

Die meisten Engineering Manager verwenden das Sandwich-Prinzip. Sie eröffnen mit einem Lob, bringen die Kritik in der Mitte und schließen mit Aufmunterung. Engineers hören die Mitte nicht. Sie hören: "Sie machen das gut, ein paar Kleinigkeiten, Sie machen das gut." Dann werden sie im Oktober überrascht und erzählen es ihren Bekannten.

Hören Sie mit dem Sandwich-Prinzip auf. Nutzen Sie SBI mit Bitte und Commitment. Vier Schritte, kein Auffüllen.

Situation. Der konkrete Zeitpunkt, Ort und Kontext. "Im Auth-Service-Redesign-Review am 12. März."

Verhalten. Was die Person beobachtbar getan hat. Nicht was Sie über ihren inneren Zustand geschlossen haben. "Sie haben zwei der vier Fragen der Reviewer nicht beantwortet und gesagt: 'Das können wir später klären.'"

Wirkung (Impact). Was es das Team oder die Arbeit gekostet hat. "Die Reviewer haben sich danach bei mir gemeldet. Wir haben den Launch um eine Woche verschoben, um das Bedrohungsmodell neu zu erstellen."

Bitte. Was Sie beim nächsten Mal konkret anders haben wollen. "Wenn ein Reviewer eine Sicherheitsfrage zu einem Designdokument anspricht, brauche ich von Ihnen eine Antwort im Dokument innerhalb von 48 Stunden, auch wenn die Antwort lautet: 'Wir verschieben das, und das ist der Grund.'"

Commitment. Ein Datum und ein Kontrollpunkt. "Schauen wir uns das in unserem 1:1 am 9. April an und schauen, wie die nächsten zwei Design-Reviews verlaufen sind."

Zwei Beispielskripte, die Sie direkt verwenden können:

Code-Reviews blockieren das Team. "In sprint 23 haben drei Ihrer Code-Reviews mehr als 4 Tage gedauert. Einer davon hat den Checkout-Revamp-Launch um einen ganzen sprint verzögert. Das Team beginnt, Sie zu umgehen, was bedeutet, dass Sie den Kontext zur Codebasis verlieren. Ich brauche von Ihnen, dass Sie Reviews entweder in 24 Stunden erledigen oder an jemanden delegieren, der das kann. Lassen Sie uns beim 1:1 am 15. nachschauen."

Designdokumenten fehlt Tiefe. "Ihre letzten zwei Designdokumente, die Queue-Migration und das Rewrite des Rate-Limiters, hatten keinen Abschnitt zu Fehlerszenarien und keinen Rollback-Plan. Das Architecture-Review-Committee hat beide zur zweiten Überarbeitung zurückgegeben, was Sie jeweils zwei Wochen gekostet hat. Auf Staff-Ebene müssen Designdokumente mindestens zu 70 % beim ersten Review angenommen werden. Ich möchte, dass das nächste Dokument, das Sie schreiben, eine Tabelle mit Fehlerszenarien und einen Rollback-Abschnitt enthält, bevor es ans ARC geht. Wir schauen uns das nächste Dokument gemeinsam an, bevor Sie es am 22. einreichen."

Beachten Sie, was fehlt: kein "aber ansonsten leisten Sie großartige Arbeit". Dieser Satz dient Ihrem eigenen Wohlbefinden, nicht dem des Engineers. Falls nötig, fügen Sie ihn am Ende des Meetings hinzu, nach dem Commitment.

PIP-Signale: Wann anfangen, wann überspringen

Ein Plan zur Leistungsverbesserung ist ein Instrument, keine Strafe. Der häufigste Fehler von Engineering Managern ist, zu spät damit zu beginnen, was meistens daran liegt, dass sie sechs Monate lang das Sandwich-Prinzip angewendet haben. Der zweithäufigste Fehler ist, einen solchen Plan zu starten, wenn das eigentliche Problem die Passung ist, nicht die Leistung.

Beginnen Sie einen Plan zur Leistungsverbesserung, wenn alle drei Bedingungen zutreffen:

1. Das Verhalten wurde dem Engineer schriftlich benannt (in 1:1-Notizen, die er nachlesen kann).
2. Das Verhalten hat sich wiederholt, über mindestens zwei Zyklen oder zwei Monate.
3. Das Verhalten ist unverändert nach mindestens zwei schriftlichen 1:1-Notizen, die es ansprechen, und mindestens einem SBI-Gespräch.

Wenn Sie nicht alle drei aus Ihrem 1:1-Dokument belegen können, haben Sie keinen Fall für einen solchen Plan. Sie haben eine Feedback-Lücke, und der Plan wird von HR und Ihren Peer-Engineering-Managern in der Kalibrierung angefochten.

Überspringen Sie den Plan bei einem Passungsproblem, nicht einem Leistungsproblem.

Ein Passungsproblem sieht so aus: Der Engineer ist fachlich in Ordnung, liefert seine Arbeit, passt aber nicht zum Domänenbereich des Teams (tief infrastrukturorientierte Person in einem Produktteam, tief produktorientierte Person in einem Plattformteam) oder zur Unternehmensphase (mag das Chaos eines 10-Personen-Teams, wurde bei 800 Personen eingestellt). Der Engineer versagt nicht. Der Platz ist falsch.

Einen Plan zur Leistungsverbesserung auf ein Passungsproblem anzuwenden führt zu einem wütenden Abgang. Der Engineer kämpft, gewinnt technisch gesehen, verlässt das Unternehmen trotzdem und erzählt jedem, dass Sie versucht haben, ihn ungerecht herauszudrängen. Kosten: 6 Monate Teammoral und Ihr Ruf auf dem Markt.

Bieten Sie stattdessen einen geregelten Wechsel an. Direkt, freundlich, mit Datum. "Ich glaube, Sie wären im Plattformteam besser aufgehoben. Ich habe mit Maria gesprochen, und sie hat eine offene Stelle. Ich würde Sie gerne über die nächsten 4 Wochen beim Wechsel unterstützen. Wenn Sie lieber extern schauen möchten, gebe ich Ihnen 6 Wochen Zeit und eine starke Referenz." Engineers respektieren das. Ihre Bekannten respektieren das. Ihre Personalgewinnung profitiert davon.

Die vereinfachte Entscheidungsmatrix für Pläne zur Leistungsverbesserung:

Ein sauber geführter Plan zur Leistungsverbesserung löst sich in 60 Tagen auf, entweder durch echte Verbesserung oder einen sauberen Abgang. Wenn Ihrer sich bis in Monat 4 zieht, managen Sie Ihr eigenes Unbehagen, nicht die Leistung des Engineers.

Beförderungskalibrierung mit Peer-Engineering-Managern

Die Kalibrierung ist das Meeting, in dem Beförderungsentscheidungen tatsächlich getroffen werden. Das von Ihnen verfasste Paket ist die Eintrittskarte. Die 90 Minuten in einem Raum mit 4 bis 6 Peer-Engineering-Managern und Ihrem Director sind der Ort, an dem Champion-vs-Challenger-Dynamiken das Ergebnis entscheiden.

Bringen Sie ein einseitiges Pre-Read mit. Zwei Tage vor der Kalibrierung schicken Sie Ihren Peer-Engineering-Managern eine einzelne Seite pro Kandidat:

• Name, aktuelles Level, Ziellevel
• Die drei wichtigsten Artefakte (mit Links zum Designdokument, RFC, Vorfall-Retrospektive)
• Belege für Verantwortungsbereich, Wirkung und Multiplikatoreffekt in jeweils drei kurzen Stichpunkten
• Ein Absatz zu dem stärksten Gegenargument und Ihrer Antwort darauf

Dieser letzte Punkt trennt den Engineering Manager, der seinen Engineer befördert aus der Kalibrierung herausgeht, von dem, der es nicht schafft. Den Einwand des Challengers im Pre-Read vorwegzunehmen bedeutet, dass die Gegenstimme im Raum etwas anspricht, das Sie bereits schriftlich adressiert haben. Nehmen Sie es nicht vorweg, erhält Ihr Peer, der Einwände erhebt, die Möglichkeit, es zuerst zu formulieren.

Verteidigen Sie einen Grenzfall, ohne ihn zu überverkaufen. Grenzfall bedeutet: Der Engineer erfüllt die Kriterien in zwei von drei Dimensionen und nähert sich in der dritten an. Sagen Sie nicht "er ist absolut Staff." Sagen Sie: "Er erfüllt die Kriterien bei Verantwortungsbereich und Multiplikatoreffekt, nähert sich bei der Wirkung an, und hier ist die laufende Arbeit, die die Lücke bis Q3 schließt." Das ist die Art von Aussage, die einer Prüfung durch den Director standhält. Einen Grenzfall zu überverkaufen kostet Sie Ihre Glaubwürdigkeit für die nächsten zwei Zyklen.

Wenn ein Peer-Engineering-Manager Ihren Engineer blockiert, um den eigenen zu schützen (das kommt vor, besonders wenn Bewertungen nach einem Ranking vergeben werden oder das Budget begrenzt ist), kämpfen Sie nicht im Raum darum. Sie verlieren und beschädigen die Beziehung. Klären Sie es stattdessen bilateral. "Ich möchte sicherstellen, dass ich Ihren Einwand zu Priyas Designdokument-Anspruch verstehe. Können wir diese Woche gemeinsam ihre drei RFCs durchgehen?" Neun von zehn Malen löst sich der Widerstand auf, sobald Sie das Gespräch von der Kalibrierungsbühne nehmen.

Die Stretch-Projekt-Falle

Die Hälfte der gescheiterten Beförderungspakete, die ich gesehen habe, wurde durch ein Stretch-Projekt zu Fall gebracht, das nie sichtbare Arbeit liefern würde. Das Muster ist immer gleich. Der Engineering Manager weist ein Stretch-Projekt zu, das auf dem Papier großartig klingt. Der Engineer verbringt 4 Monate damit. Das Projekt wird deprioritisiert, im Umfang gekürzt oder der Executive Sponsor wechselt das Team. Der Engineer liefert nichts extern Sichtbares. Der Kalibrierungsraum fragt: "Was hat Priya in diesem Halbjahr gemacht?" Der Engineering Manager hat nichts, worauf er zeigen kann.

Validieren Sie den Stretch-Umfang, bevor Sie ihn zuweisen. Drei Prüfungen, alle erforderlich:

1. Echtes Budget. Es gibt eine Haushaltsposition oder eine Personalbestandszuteilung, kein "Das klären wir später." Wenn die Finanzabteilung es nicht benennen kann, existiert es nicht.
2. Namentlich genannter Executive Sponsor. Ein konkreter Director oder VP, der schriftlich oder in einem aufgezeichneten Meeting gesagt hat: "Das ist einer meiner drei Prioritäten in diesem Halbjahr." Kein CC in einer Launch-E-Mail. Eine explizite Aussage.
3. Sichtbarer Lieferumfang. Ein Nutzer, Kunde oder internes Team, das die Ausgabe verwenden wird und bestätigen kann, dass sie angekommen ist. Wenn die einzigen Personen, die es sehen, das eigene Team des Engineers sind, ist es ein normales Projekt, kein Stretch.

Wenn eine der drei Bedingungen fehlt, ist das Projekt eine Karrierefalle. Sprechen Sie dagegen, auch wenn der Engineer begeistert ist. "Ich finde diese Idee großartig. Bevor ich sie als Ihr Stretch-Projekt zuweise, brauche ich zu wissen, wer der Executive Sponsor ist und welcher Nutzer es verwenden wird. Ohne diese zwei Punkte verbringen Sie 4 Monate mit etwas, das Ihrem Paket nicht hilft." Die guten Engineers danken Ihnen im fünften Monat. Die herausragenden im ersten.

Kontinuierliche Entwicklungsdokumentation

Ein Dokument. Dasselbe Dokument. Es begleitet den Engineer die gesamte Zeit seiner Teamzugehörigkeit. Nicht drei separate Dokumente an drei verschiedenen Stellen.

Drei Rhythmen speisen es:

Die monatliche Stichpunkt-Aktualisierung ist die unterschätzte Maßnahme. Fünf Minuten. Der Engineer schreibt auf, was er geliefert hat, was ihn blockiert hat, was er gelernt hat, was er von Ihnen erbittet. Sie lesen es vor dem nächsten 1:1 und antworten schriftlich. Sechs Monate später, wenn die Kalibrierungsvorbereitung beginnt, haben Sie 6 Monate an Stichpunkten, die sich ohne heroischen Erinnerungsaufwand in das formale Paket verdichten.

Die wichtigste Regel: Der Engineer kann seinen eigenen Entwicklungsverlauf jederzeit nachvollziehen. Wenn Ihr Engineer fragt "Wo stehe ich gerade?", lautet die Antwort: "Öffnen Sie das Dokument, scrollen Sie zum letzten Quartals-Review, da sehen Sie genau, wo Sie stehen." Keine Überraschungen. Kein "Lassen Sie mich einen Termin einplanen, um das zu besprechen." Das Dokument ist die Antwort.

So können Sie auch dann nahtlos weitermachen, wenn ein Engineer das Team wechselt oder Sie das Unternehmen verlassen. Der nächste Engineering Manager erbt ein echtes Dokument. Keine Slack-DM-Historie.

Häufige Fehler, die es zu vermeiden gilt

• Echtes Feedback für den Review-Tag aufsparen. Wenn Ihr Engineer es im Oktober zum ersten Mal hört, haben Sie im Mai versagt.
• Auf Potenzial statt auf Belege befördern. Auf Potenzial setzen Sie beim Einstellen, nicht bei der Beförderung. Beförderungen laufen auf Basis ausgelieferter Artefakte.
• Weiche Sprache, die im Kopf des Engineers als "kein Problem" ankommt. "Ich würde mir bei Ihren Designdokumenten etwas mehr Sorgfalt wünschen" ist kein Feedback. Es ist ein Hinweis, der ignoriert wird. Verwenden Sie SBI.
• Kalibrieren ohne Artefakte im Raum. Wenn Sie das Designdokument nicht verlinken können, haben Sie kein Argument.
• Geleistete Stunden mit erbrachter Wirkung verwechseln. Ein Engineer mit 60 Arbeitsstunden, der zwei Features geliefert hat, schlägt keinen Engineer mit 40 Stunden, der vier geliefert hat.

Erfolgsmessung

Sie wissen, dass dieser Playbook greift, wenn:

• Kein Engineer von seiner Review-Tag-Bewertung überrascht wird, weil er dasselbe Entwicklungsdokument liest wie Sie.
• Beförderungspakete in 70 % der Fälle in der ersten Kalibrierungsrunde genehmigt werden, weil Sie aufgehört haben, Grenzfälle als Wette einzureichen.
• Pläne zur Leistungsverbesserung sich innerhalb von 60 Tagen auflösen (entweder durch echte Verbesserung oder einen sauberen Wechsel), anstatt sich bis in Monat 6 zu ziehen und das Team zu belasten.
• Engineers ihre eigenen Kriterien für die nächste Stufe auswendig nennen können, weil Sie das Raster schriftlich festgehalten und anhand eines echten Artefakts besprochen haben.

Der Maßstab ist einfach: Ein Engineer mit einem abgelehnten Paket sollte in der Lage sein, auf die Kriterien zu zeigen, auf seine Arbeit zu zeigen und der Lücke zuzustimmen. Wenn er das nicht kann, liegt das Versagen bei Ihnen, nicht bei ihm.

Mehr erfahren

• Staff Software Engineer Stellenbeschreibung
• Einzelgespräche mit Engineers, die etwas bewegen
• Senior Engineers einstellen, die bleiben
• Skip-Level 1:1s, die echte Wahrheit ans Licht bringen