Deutsch

Häufige Fehler von Engineering Managern (und wie man damit aufhört)

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

Es ist Sonntagabend. Sie reviewen einen PR, den Ihr staff engineer am Freitag geöffnet hat, weil niemand sonst "den Kontext hatte." Ihr 1:1-Dokument mit Ihrem erfahrensten direkt unterstellten Mitarbeiter hat dieselben drei Punkte wie vor sechs Wochen. Sie haben seit der Umstrukturierung kein retro durchgeführt. Sie sagen sich, Sie seien ein Coach-Manager. Ihr Team würde Sie als "nett, aber abwesend" beschreiben.

Diese Anleitung ist die Lücke.

Ich war der schlechte EM in jeder dieser Geschichten. Ich werde nicht moralisieren. Ich werde das Muster benennen, Ihnen die Zahl nennen, die den Schaden quantifiziert, und Ihnen genau sagen, was Sie diese Woche tun sollen. Sie können das ganze Jahr Lara Hogan, Will Larson und Camille Fournier lesen, aber bis Sie den Rat in geändertes Verhalten an einem Dienstagmorgen umgewandelt haben, leidet Ihr Team noch unter der Version von Ihnen, die nichts davon gelesen hat.

Warum das jetzt wichtig ist

EMs im ersten Jahr werden an zwei Dingen gemessen: Team-Output und Mitarbeiterbindung. Die meisten scheitern bei der Mitarbeiterbindung, weil die Versagensmuster unsichtbar sind, bis jemand kündigt. Bis dahin sind es eine dreimonatige Nachbesetzung, eine sechsmonatige Einarbeitungszeit und ungefähr 180.000 bis 250.000 Euro an vollständig belastetem Kostenaufwand pro Abgang, wenn man Ingenieurgehalt, Vermittlergebühren und Einarbeitungsverluste des zurückbleibenden Teams addiert.

Zwei bedauerliche Abgänge in einem Jahr vernichten den Großteil des Produktivitätsgewinns, den Sie erzielt haben. Und Sie können nicht managen, was Sie nicht sehen, daher ist die erste Aufgabe, die Muster zu benennen. Hier sind die sieben, die am häufigsten bei EMs zwischen 6 und 18 Monaten auftreten.

Fehler 1: Coden statt Coachen

Symptom. Sie schließen 3-8 eigene PRs pro Woche. Sie sagen sich, Sie "entsperren das Team". In Wirklichkeit vermeiden Sie die schwierigere, langsamere Arbeit zu entscheiden, welche Person im Team in diesen Teil des Codes hineinwachsen soll.

Reale Zahl. Jede Stunde, die Sie coden, sind ungefähr 1,5-2 Stunden Team-Coaching entgangen, weil Coaching unterbrechungsgetrieben ist und Sie jetzt konzentriert und nicht verfügbar sind. Bei einem Team von sechs sind das etwa 10 verlorene Coaching-Stunden pro Woche. In einem Quartal haben Sie ungefähr 130 Stunden gestohlen, oder einen vollständigen Sprint Senior-Entwicklungszeit, vom Wachstum Ihrer direkt unterstellten Mitarbeiter.

Lösung. Begrenzen Sie Ihren IC-Beitrag auf 10% Ihrer Woche. Blockieren Sie ihn in Ihrem Kalender, beschriften Sie ihn "IC-Zeit", und wenn die Zeit weg ist, ist sie weg. Übergeben Sie die nächste "Ich mache das schnell"-Aufgabe an den direkt unterstellten Mitarbeiter, dessen Wachstumsbereich sie berührt, und sagen Sie ihm, warum Sie sie übergeben: "Das ist die Art von Arbeit, die Sie zu Senior bringt. Ich möchte, dass Sie es besitzen, und ich möchte das Design überprüfen, bevor Sie beginnen." Dieser letzte Satz ist der Unterschied zwischen einer Übergabe und einem Abladen.

Fehler 2: Das schwierige 1:1 überspringen

Symptom. Ihr wöchentliches 1:1 mit dem Senior, der liefert aber toxisch im Code-Review ist, "läuft immer noch die Zeit ab", bevor Sie das Verhalten ansprechen. Drei Monate später führen zwei Personen im Team Gespräche anderswo.

Reale Zahl. Durchschnittliche Betriebszugehörigkeit eines Ingenieurs, der einen Kollegen als toxisch betrachtet und einen Manager hat, der es nicht angesprochen hat: 8-11 Monate. Durchschnittliche Betriebszugehörigkeit eines Ingenieurs, dessen Manager das Verhalten in den ersten vier Wochen benannt hat: 2,5+ Jahre. Das Delta ist ein vollständiger Backfill-Kosten pro Jahr des Vermeidens, plus die kulturellen Kosten für den Rest des Teams, der zugesehen hat, wie Sie nicht gehandelt haben.

Lösung. Wenn Sie ein Thema seit zwei Wochen oder mehr vermeiden, öffnet das nächste 1:1 damit. Kein Räuspern, kein "Wie war Ihr Wochenende?" Skript: "Ich möchte die ersten 15 Minuten für ein schwieriges Gespräch über den Stand des Code-Reviews nutzen. Ich habe X von zwei Kollegen gehört. Schildern Sie mir Ihre Perspektive." Weichen Sie die Eröffnung nicht ab. Weichen Sie das Zuhören ab. Der häufigste Grund, warum dieses Gespräch schlecht läuft, ist nicht, dass Sie das Falsche gesagt haben. Es ist, dass Sie das Richtige 30 Sekunden lang gesagt haben und dann die nächsten 14 Minuten damit verbracht haben, sich dafür zu entschuldigen.

Fehler 3: Zu starke Abhängigkeit von Velocity-Metriken

Symptom. Sie zitieren story points in skip-levels. Sie haben letztes Quartal einen 20%igen Velocity-Sprung gefeiert, der von einem Senior entstand, der das backlog neu bewertet hat, nicht von einer echten Änderung im Durchsatz. Wenn Sie gefragt werden, wie das Team läuft, ist "Velocity ist gestiegen" das Erste, was aus Ihrem Mund kommt.

Reale Zahl. Ungefähr 70% der Velocity-Veränderungen in einem bestimmten Quartal sind Schätzungsdrift, keine echte Produktivitätsänderung. Teams, die Velocity managen, sehen die DORA-Änderungsfehlerrate innerhalb von zwei Quartalen um 15-25% steigen, weil sie Testtiefe und Review-Sorgfalt reduzieren, um die Punktzahl attraktiv zu halten. Sie haben das Dashboard optimiert und das darunter liegende System beschädigt.

Lösung. Ersetzen Sie Velocity in Ihrem wöchentlichen Bericht durch drei Zahlen: Deployment-Häufigkeit, Änderungsfehlerrate und Zeit zur Wiederherstellung. Wenn Ihre Organisation sie nicht verfolgt, instrumentieren Sie sie selbst in einer Tabellenkalkulation für ein Quartal. Das dauert ungefähr 90 Minuten zum Einrichten und 10 Minuten pro Woche zur Pflege. Bringen Sie DORA zu Ihrem skip-level und erklären Sie, warum Sie von Punkten abweichen. Das erste Mal, dass Sie das tun, wird Ihr skip-level Sie mehr respektieren, nicht weniger. Hören Sie auf, Punkte zu zitieren.

Fehler 4: Beförderungskriterien unzureichend dokumentieren

Symptom. Sie haben einen direkt unterstellten Mitarbeiter, der sich "nah dran" an Senior anfühlt, und einen anderen, der "noch nicht ganz da ist." Wenn jemand Sie bittet, den Unterschied zwischen ihnen in 90 Sekunden aufzuschreiben, könnten Sie das nicht. Sie würden über "Präsenz" und "Eigentümerschaft" und "Urteilsvermögen" sprechen, und der Raum würde höflich nicken.

Reale Zahl. Beförderungsergebnisse korrelieren etwa 0,4 mit dokumentierten Kriterien und etwa 0,7 mit Manager-Vertrauen und Recency-Bias, wenn Kriterien nicht schriftlich vorliegen. Die Lücke zeigt sich in der Kalibrierung als "Ich vertraue Ihrer Einschätzung", was dazu führt, dass die Lauten befördert werden und die Stillen stagnieren. Die Kosten landen ungefähr 18 Monate später im Team, wenn der stärkste IC, der ohne klaren Grund übergangen wurde, zu einem Unternehmen geht, das ihm einen gab.

Lösung. Schreiben Sie diese Woche ein einseitiges Dokument "Was Staff bei diesem Team aussieht". Drei Abschnitte: Umfang, Wirkung, Verhalten. Fügen Sie 4-6 konkrete Beispiele unter jedem hinzu, entnommen aus Personen, die Sie morgen befördern würden. Teilen Sie es mit jedem direkt unterstellten Mitarbeiter in seinem nächsten 1:1, nicht in einer vagen "Hier ist das Dokument, melden Sie sich, wenn Sie Fragen haben"-E-Mail. Gehen Sie es durch. Fragen Sie, wo sie sich einschätzen. Verwenden Sie dasselbe Dokument in der Kalibrierung. Aktualisieren Sie es vierteljährlich. Das Dokument ist nicht das Ziel; das Gespräch, das es erzwingt, ist das Ziel.

Fehler 5: Das Team (schlecht) vor Kontext abschirmen

Symptom. Sie "schützen das Team vor Politik", indem Sie ihnen nicht sagen, dass das Projekt gefährdet ist, die Personalressourcen eingefroren sind oder der Kunde das v1 hasst. Sie erfahren es über einen Slack-Kanal zwei Wochen später, oft von jemandem, der nicht einmal in Ihrem Team arbeitet. Dann fragen sie Sie danach und Sie sagen etwas wie "Ja, ich wollte das erwähnen."

Reale Zahl. Ingenieure, die sich unterdurchschnittlich informiert fühlen, erzielen in Engagement-Umfragen 30-40 Punkte weniger als Kollegen, die sich überdurchschnittlich informiert fühlen. Engagement im unteren Quartil prognostiziert Abgang innerhalb von 12 Monaten mit dem 2-3-fachen der Basisrate. Übersetzung: Schlechtes Abschirmen kostet Sie etwa einen von vier direkt unterstellten Mitarbeitern pro Jahr, und die vier, die Sie verlieren, sind diejenigen mit Optionen.

Lösung. Standard: teilen. Der Test ist nicht "wird das sie stressen", sondern "würde ich das wissen wollen, wenn ich an ihrer Stelle wäre?" Führen Sie einen wöchentlichen 15-minütigen Team-Kontext-standup durch: Was auf Führungsebene geändert wurde, was noch unsicher ist, was sie ignorieren sollten. Wenn etwas wirklich zu sensibel ist, sagen Sie "Es gibt etwas, das ich noch nicht teilen kann, hier ist, wann ich das voraussichtlich kann." Dieser Satz kauft mehr Vertrauen als jede Verhüllung. Ingenieure können den Unterschied zwischen einem Manager, der sie schützt, und einem Manager, der sich selbst schützt, erkennen.

Fehler 6: Keine retros durchführen (oder gefälschte)

Symptom. Das letzte retro war vor 11 Wochen. Oder Sie führen sie durch, aber die Maßnahmen bekommen nie Verantwortliche oder Fälligkeitsdaten, also tauchen dieselben drei Probleme in jedem retro wieder auf. Jemand erwähnt, dass Deploys immer noch schmerzhaft sind. Alle nicken. Nichts passiert. Nächstes retro, jemand erwähnt, dass Deploys immer noch schmerzhaft sind. Alle nicken.

Reale Zahl. Teams, die echte retros mit benannten Verantwortlichen und Datumsangaben und Follow-up im nächsten retro durchführen, liefern etwa 25% mehr vorfall-freie Quartale als Teams, die das nicht tun. Teams, die gefälschte retros durchführen, erzielen dasselbe Ergebnis wie Teams ohne retros, was bedeutet, das Ritual ohne den Loop ist aktiv schlimmer als nichts. Sie haben dem Team beigebracht, dass das Ansprechen von Problemen sie nicht löst, was eine weitaus schwierigere Lektion rückgängig zu machen ist, als von vorne anzufangen.

Lösung. Rhythmus: alle zwei Sprints, 60 Minuten, keine Ausnahmen. Format: vier Spalten (beibehalten, gestrichen, mehr davon, blockiert auf). Jede Maßnahme erhält einen Verantwortlichen und ein Datum. Verfolgen Sie die Maßnahmen auf einem öffentlichen Board. Öffnen Sie das nächste retro mit der Überprüfung der vorherigen Maßnahmen. Wenn weniger als 70% abgeschlossen sind, ist das das Gespräch, und Sie überspringen das Brainstorming. Das Team wird beim ersten Mal widersprechen. Tun Sie es trotzdem. Nach zwei Zyklen werden sie mit bereits benannten Maßnahmen auftauchen, weil sie wissen, dass Sie nachfragen werden.

Fehler 7: Langsam einstellen, weil Einstellung schwer ist

Symptom. Sie haben eine offene Stelle, die seit vier Monaten offen ist. Sie haben acht Kandidaten interviewt. Keiner erfüllte "den Maßstab." Währenddessen arbeitet Ihr Team seit einem Quartal mit 80% Kapazität, und Ihr stärkster Senior erledigt die Arbeit von zwei Personen und sieht in 1:1s müde aus.

Reale Zahl. Kosten einer offenen Senior-Stelle bei typischem SaaS-Gehalt: ungefähr 20.000-30.000 Euro pro Monat an entgangenem Output, plus die Last, die Sie dem Rest des Teams aufbürden, was sein Abgangsrisiko erhöht (siehe Fehler 5). Eine vier Monate offene Stelle hat das Unternehmen 100.000 Euro gekostet und Ihnen wahrscheinlich einen bedauerlichen Abgang noch dazu eingebracht. Der Maßstab, den Sie halten, hat jetzt mehr als zwei günstigere Einstellungen zusammen gekostet.

Lösung. Definieren Sie den Maßstab schriftlich: drei Muss-Anforderungen, drei Nice-to-have. Führen Sie jeden Interview-Loop gegen dieses Dokument aus, nicht gegen Bauchgefühl. Wenn Sie fünf Kandidaten nacheinander abgelehnt haben, ist der Maßstab das Problem, nicht der Markt. Entweder senken Sie ihn bewusst und teilen Ihrem skip-level mit, warum, oder Sie teilen die Stelle in zwei günstigere Einstellungen auf, die zu einer starken heranwachsen können. Die begleitende Staff Software Engineer-Stellenausschreibung ist ein guter Ausgangspunkt dafür, wie "der Maßstab" schriftlich aussieht. Hören Sie auf, auf ein Einhorn zu warten, während Ihr Team abbrennt. Das Einhorn kommt nicht, und das Team ist der Vermögenswert, den Sie tatsächlich haben.

Alles zusammenfügen: Ein 30-minütiges Selbst-Audit

Stellen Sie einen Timer. Bewerten Sie sich für jede der sieben Fallen oben mit 1-5. Seien Sie ehrlich. Ihr skip-level weiß es bereits.

Alles 3 oder darunter: Wählen Sie eine Lösung aus dieser Anleitung, tragen Sie sie für diese Woche in Ihren Kalender ein, und sagen Sie einem Peer-EM, wozu Sie sich verpflichtet haben, damit Sie es nicht still fallen lassen. Versuchen Sie nicht, alle sieben auf einmal zu beheben. Sie werden an allen abprallen. Wählen Sie die niedrigste Bewertung, führen Sie diese Lösung zwei Wochen durch, dann führen Sie das Audit erneut durch.

Der Grund, warum das funktioniert und "Ich werde absichtsvoller beim Coachen sein" nicht, ist, dass die Lösung ein Kalender-Block ist, keine Absicht. Kalender-Blöcke überleben Montage. Absichten nicht.

Wie gutes Aussehen in 90 Tagen aussieht

Konkretes Bild. Wenn Sie das Audit diese Woche durchgeführt und sich zu einer Lösung pro zwei Wochen verpflichtet haben, sollte das Team, das Sie bis August haben, so aussehen:

  • Sie liefern Code weniger als 10% Ihrer Woche und fühlen sich nicht schuldig dabei.
  • Sie haben mindestens zwei schwierige 1:1s geführt, und das Team ist dadurch besser, nicht schlechter.
  • Ihr wöchentlicher Bericht beginnt mit Deployment-Häufigkeit und Änderungsfehlerrate, nicht mit story points.
  • Jeder direkt unterstellte Mitarbeiter weiß, wie die nächste Stufe für ihn aussieht, auf Papier, und hat mindestens ein Gespräch mit Ihnen darüber geführt, wo er im Vergleich dazu steht.
  • Das Team erhält Kontext mit Standard-Teilen, nicht Standard-Abschirmen, und Ihr wöchentlicher Kontext-standup ist eine Gewohnheit, die niemand in Frage stellt.
  • retros laufen in einem zweiwöchigen Sprint-Rhythmus mit einem abgeschlossenen Aktionsprotokoll, das zu mehr als 70% rechtzeitig ist.
  • Keine Stelle ist seit mehr als acht Wochen offen ohne eine schriftliche Maßstabs-Neukalibrierung.

Nichts davon erfordert eine Persönlichkeitstransplantation. Es erfordert die Entscheidung, dass die Version von Ihnen, die diese Muster toleriert, diejenige ist, für die Ihr Team bezahlt, und dann eine Änderung nach der anderen, bis sie es nicht mehr sind.

Mehr erfahren

About the author

Camellia

Camellia

Principal Product Marketing Strategist

Camellia is Principal Product Marketing Strategist at Rework, helping B2B buyers pick the right software with confidence. With 6+ years in product marketing and 150+ SaaS tools evaluated across CRM, project management, and sales engagement, Camellia turns competitive intelligence into clear, honest comparisons. Readers get vendor evaluations they can trust to cut through marketing noise and decide faster.