Die ersten 30/60/90 Tage als neuer Engineering Manager

Vor drei Wochen waren Sie noch ein Senior IC. Heute stehen in Ihrem Kalender 14 Stunden Meetings, 26 Stunden "offene Zeit" und eine Slack-Nachricht Ihres skip-level: "Sagen Sie mir Bescheid, wenn Sie diese Woche auf einen Kaffee vorbeikommen möchten." Sie haben noch immer Merge-Zugriff. Sie wissen noch genau, welche Datei Sie öffnen müssten, um den Bug zu beheben, der gerade den on-call Engineer angepingt hat. Und genau das ist die Falle.

Die meisten neuen Engineering Manager weichen ins Programmieren aus, weil es sich sicherer anfühlt als Coaching. Ein Jira-Ticket hat eine klare Definition of Done. Das 1:1 mit dem Staff Engineer, der still nach einem anderen Job sucht, nicht. Also baut der neue EM in Woche zwei ein Feature, fühlt sich produktiv und scheitert sechs Monate lang am eigentlichen Job, bis sein skip-level fragt, warum die Team-Velocity sich nicht bewegt hat und zwei Mitarbeitende gekündigt haben.

Wer seinen Wochenerfolg noch in gemergten PRs misst, hat den Titel übernommen, aber den Job noch nicht.

Warum 30/60/90 entscheidend ist

Das Zeitfenster, in dem Ihr Team sich eine Meinung über Sie bildet, ist eng. Bis zum 45. Tag haben die Mitarbeitenden entschieden, ob Sie ein Manager sind, der noch vorgibt, ein IC zu sein, oder ein IC, der tatsächlich zum Manager wird. Sie bemerken, welche Meetings Sie absagen, wessen Einzelgespräche Sie verschieben, worüber Sie sprechen, wenn Sie doch erscheinen. Sie teilen Ihnen ihre Einschätzung nicht mit. Sie passen einfach ihr Verhalten entsprechend an.

Der folgende Plan zielt darauf ab, das zweite Ergebnis zu erzwingen. Jeder 30-Tage-Block enthält drei bis fünf konkrete Aufgaben, und jede davon ist etwas, das Sie nicht aus Ihrer IDE heraus erledigen können.

Tage 1 bis 30: Zuhören, Prüfen, Präsenz zeigen

Der erste Monat dient der Informationsbeschaffung. Sie werden versucht sein, Dinge zu reparieren. Tun Sie es nicht. Sie wissen noch nicht, was tatsächlich kaputt ist und was nur von Ihrem alten Platz aus kaputt aussieht.

10 Einzelgespräche mit Mitarbeitenden in den ersten zwei Wochen

Wenn Sie acht direkt unterstellte Mitarbeiter haben, bedeutet das etwa ein Einzelgespräch pro Tag über zwei Wochen plus ein paar 30-minütige Folgegespräche. Stellen Sie jedes Mal dieselben drei Fragen:

1. Was ist gerade das Beste daran, hier zu arbeiten?
2. Was ist das Schwierigste?
3. Was würden Sie in meiner Position in den ersten 90 Tagen ändern?

Schreiben Sie handschriftlich mit. Lösen Sie im Gespräch keine Probleme. Der häufigste Fehler neuer Engineering Manager in frühen Einzelgesprächen: Sie hören eine Beschwerde und versprechen sofort, sie zu beheben, um dann entweder das Falsche zu reparieren oder das Versprechen drei Wochen später zu brechen. "Erzählen Sie mir mehr davon" und "Darüber möchte ich nachdenken" sind vollständige Antworten.

Bis Ende der zweiten Woche werden Sie 30 bis 50 einzelne Beobachtungen gesammelt haben. Muster werden sichtbar. Drei Mitarbeitende werden dasselbe Problem in unterschiedlichen Worten nennen. Das ist Ihre Landkarte.

Velocity und on-call-Rotation prüfen

Ziehen Sie die letzten 8 sprints heran. Sie suchen nach zwei Dingen:

• Durchsatz-Trend. Sind die pro sprint abgeschlossenen story points gleichbleibend, steigend oder sinkend? Falls sinkend: Wann hat es begonnen? Verknüpfen Sie es mit Ereignissen: eine Umstrukturierung, eine Verschiebung des Verantwortungsbereichs, eine Abwesenheit.
• on-call-Verteilung. Ziehen Sie die Page-Logs und zählen Sie Vorfälle pro Engineer für das letzte Quartal. Wenn drei Personen 70 % der Pages tragen, haben Sie ein Fairness-Problem und ein Burnout-Risiko, und Sie wussten letzte Woche noch nichts davon, weil niemand laut genug geklagt hat.

Halten Sie Ihre Ergebnisse fest. Beheben Sie noch nichts. Die Prüfung ist eine Ausgangsbasis, die Sie in den Tagen 31 bis 60 für Ihre erste retro verwenden werden.

5 funktionsübergreifende Meetings besuchen

Produkt-Planung. Design-Review. Sales Enablement (ja, Sales, weil Ihr Team wahrscheinlich Features baut, die das AE-Team vorführen muss). Support-Eskalations-Sync. Das wöchentliche Meeting Ihres skip-level mit seinem Peer in einer anderen Abteilung.

Sie sind nicht dort, um zu reden. Sie sind dort, um zu verstehen, wie Ihr Team von außen wahrgenommen wird. Der Product Manager, der Ihr Team im standup lobt, verdreht in der funktionsübergreifenden Planungssitzung vielleicht die Augen. Der Support-Lead erwähnt möglicherweise drei Kundeneskalationen, von denen Sie noch nie gehört haben. Der Ruf Ihres Teams lebt in Räumen, zu denen Sie zuvor nicht eingeladen waren.

Notieren Sie in diesen Meetings gezielt Beobachtungen zu Ihrem Team. Bringen Sie die Erkenntnisse in Einzelgesprächen zurück, ohne zu nennen, wer was gesagt hat.

KEINE Code-Commits

Klare Regel. Wenn ein kritischer Bug Ihre Hände braucht, arbeiten Sie mit einem Engineer zusammen und lassen Sie ihn mergen.

Jeder Commit, den Sie in Monat eins einbringen, signalisiert Ihrem Team, dass der alte Job für Sie noch verfügbar ist. Die Mitarbeitenden werden Sie umgehen, um schneller zu liefern. Sie werden Ihnen die unordentlichen menschlichen Probleme nicht mehr bringen, weil sie sehen, dass Sie lieber im Code wären. Sie werden sich produktiv fühlen und sich selbst täuschen.

Als ich einem Senior Engineer das erste Mal sagte, ich würde ihn bei einer komplexen Migration begleiten, aber nicht selbst commiten, schaute er etwa zehn Minuten lang verärgert und dann für den Rest des Quartals spürbar entspannter. Er wollte mich nicht in seinem Repository tippen sehen. Er wollte, dass ich mich um alles andere kümmere.

Tage 31 bis 60: Eine Sache leiten, eine Sache beheben, eine schwierige Sache ansprechen

Der zweite Monat ist der Übergang von Input zu Output. Drei Aufgaben, alle klein genug, um sie in 30 Tagen tatsächlich abzuschließen.

1 Retrospektive leiten

Ihre erste als Moderator, nicht als Teilnehmer. Verwenden Sie die Daten aus der Velocity-Prüfung. Das Format ist weniger entscheidend (start-stop-continue, mad-sad-glad oder was Ihr Team nutzt). Entscheidend ist, dass Sie ein unbequemes Muster benennen und dem Raum Zeit geben, damit umzugehen.

Zum Beispiel: "Wir schließen Tickets, aber 22 % davon werden innerhalb von zwei sprints wieder geöffnet. Woran liegt das?" Dann schweigen Sie. Die ersten 90 Sekunden werden still oder von Ausweichen geprägt sein. Halten Sie das aus. Engineers sagen letztlich die Wahrheit, wenn Sie die Stille nicht mit Ihrer eigenen Theorie füllen.

Als ich die erste retro als Manager leitete, redete ich 18 von 30 Minuten lang. Das war die Lektion. Ihre Aufgabe in einer retro ist es, zu fragen, zusammenzufassen und ein oder zwei Folgepunkte zu vergeben. Nicht das Gespräch zu führen.

1 kaputten Prozess beheben

Die kleinste Sache, über die Mitarbeitende in Einzelgesprächen geklagt haben und für die Sie in zwei Wochen eine Lösung liefern können. Nicht die große Umstrukturierung. Die Sache, die alle seit Monaten nervt und um die sich bisher niemand gekümmert hat, weil niemand den Auftrag oder die Energie dazu hatte.

Praxisbeispiele, die funktioniert haben:

• standup, der 45 Minuten dauert: auf 15 Minuten gekürzt, Format auf async-first umgestellt mit einem 10-minütigen Live-Sync nur bei konkreten Blockern.
• PR-Review-Frist von drei Tagen, die häufig überschritten wird: Ein einseitiges Erwartungsdokument veröffentlicht, einen Slack-Reminder-Bot eingerichtet, für jeden Bereich einen Ersatz-Reviewer benannt.
• on-call-Übergabe ohne schriftliches runbook: ein 20-minütiges Übergabemeeting am Ende jeder Rotation eingeführt, Notizen in einem gemeinsamen Dokument.

Wählen Sie eine Sache. Setzen Sie die Lösung um. Sagen Sie dem Team, dass Sie zugehört haben. Es geht nicht primär um die Prozessverbesserung (auch wenn sie willkommen ist). Es geht darum, dass das Team sehen wollte, ob Sie wirklich zuhören. Die Antwort ist jetzt: ja.

1 kritisches Feedback-Gespräch führen

Das, dem Sie bisher ausgewichen sind.

Der Senior Engineer, der brillant ist, aber Juniors im Code-Review vor den Kopf stößt. Der Mid-Level, der Schätzungen regelmäßig um das Dreifache verfehlt. Der tech lead, der sich innerlich verabschiedet hat und um den das Team still herumarbeitet.

Bereiten Sie das Gespräch vor dem Meeting schriftlich vor. Nutzen Sie die Situation-Verhalten-Auswirkung-Bitte-Struktur:

• Situation: "Im gestrigen Design-Review, als Priya den queue-basierten Ansatz vorschlug..."
• Verhalten: "...haben Sie sie zweimal unterbrochen und dann gesagt, das Design 'würde nicht funktionieren', ohne zu erklären warum."
• Auswirkung: "Zwei andere Engineers haben mir mitgeteilt, dass sie frühe Ideen nicht mehr in den Team-Channel bringen, weil sie damit rechnen, abgewürgt zu werden. Wir verlieren Input, den wir brauchen."
• Bitte: "Ich brauche von Ihnen, dass Sie Personen ausreden lassen und, wenn Sie anderer Meinung sind, erst eine Frage stellen, bevor Sie widersprechen. Ist das möglich?"

Üben Sie es laut. Führen Sie es im Einzelgespräch, nie in der Gruppe. Lassen Sie danach Stille zu. Das Gespräch wird sich während der Unterhaltung unangenehm anfühlen und beim zweiten Mal spürbar leichter sein. Dieses Gespräch beweist Ihnen selbst, dass Sie den Job machen können.

Tage 61 bis 90: Ergebnisse verantworten, vorausplanen

Der dritte Monat ist der Punkt, an dem Sie aufhören, "der neue EM" zu sein, und anfangen, "der EM" zu sein. Drei Aufgaben, alle für Ihren skip-level sichtbar.

Ein Team-OKR übernehmen

Nicht "die Plattform-Initiative unterstützen". Ein konkretes, messbares Ergebnis, an dem Sie am Quartalsende gemessen werden.

Schlecht: "Developer Experience verbessern." Gut: "Mediane PR-Review-Zeit bis Ende Q3 von 38 auf 12 Stunden reduzieren, gemessen über das bestehende GitHub-Metrics-Dashboard."

Schreiben Sie es auf. Holen Sie die Zustimmung Ihres skip-level ein. Sagen Sie dem Team, dass es Ihres ist, nicht ihres. Sie verantworten die Zahl, sie leisten die Arbeit. Diese Unterscheidung ist wichtig, weil das Team zu viele Manager erlebt hat, die ein OKR weitergereicht und sich dann beim Ausrutschen davongestohlen haben.

Einen 90-Tage-Bericht beim skip-level vorstellen

Maximal drei Folien. Die Struktur, die funktioniert:

• Folie 1: Was ich vorgefunden habe. Velocity-Ausgangswert, on-call-Verteilung, die drei größten Risiken, die ich identifiziert habe, die drei größten Stärken. Jeweils zwei Sätze.
• Folie 2: Was ich geliefert habe. Die retro, die Sie geleitet haben, der Prozess, den Sie verbessert haben, das OKR, das Sie übernommen haben. Konkrete Ergebnisse, die der skip-level nachprüfen kann.
• Folie 3: Was ich beantrage. Der H2-Einstellungsplan und der Vorschlag zur Reduzierung technischer Schulden (nächster Punkt). Konkrete Anfragen, konkrete Kosten, konkrete erwartete Ergebnisse.

Das ist das Dokument, das Ihnen weitere 90 Tage Vertrauen sichert. Es ist auch das, was Ihr skip-level seinem Vorgesetzten gegenüber zitieren wird, wenn er erklärt, warum er Sie befördert hat. Machen Sie es ihm leicht.

H2-Einstellungsplan und Plan zur Reduktion technischer Schulden vorlegen

Eine offene Stelle mit einer von Ihnen verfassten Stellenbeschreibung (Link zur begleitenden Staff-Software-Engineer-JD-Vorlage) und eine priorisierte Liste der drei wichtigsten Posten technischer Schulden mit groben Kostenschätzungen.

Der Einstellungsplan sollte folgende Fragen beantworten: Welche Rolle, warum diese und nicht eine andere, was wird durch den Einstieg entsperrt, welcher Trade-off entsteht, wenn Sie den Personalbestand nicht bekommen. Eine Seite.

Die Liste technischer Schulden sollte für jeden Posten beantworten: Was läuft heute deswegen schlechter, grober Engineering-Aufwand zur Behebung (in Personenwochen), erwartete Verbesserung (in messbaren Begriffen wie 30 % weniger Pages, 2 Wochen schnellere Einarbeitung). Priorisieren Sie die drei Punkte. Verteidigen Sie die Reihenfolge, wenn sie hinterfragt wird.

Reichen Sie es ein. Verteidigen Sie es. Selbst wenn Sie den Personalbestand oder das Budget für technische Schulden nicht erhalten: Der Akt des Schreibens und Verteidigens des Plans ist das, was Sie von "neuem EM" zu "EM mit einer eigenen Perspektive" macht.

Typische Fehler in der Praxis

Drei vorhersehbare Wege, auf denen dieser Plan scheitert.

Der Rückzug zum Code

Wenn Ihre Hände nicht tippen wollen, ist das Entzug, keine Schwäche. Blockieren Sie 90 Minuten pro Woche für "Engineering-Zeit" (Architektur-Review, PRs lesen ohne zu mergen, ein schwieriges Problem gemeinsam mit einem Junior debuggen) und nennen Sie es auch so. Nennen Sie es nicht Coding. Das Label ist wichtig, weil es Sie jedes Mal zwingt zu fragen, ob das, was Sie gleich tun werden, Mentoring oder Verstecken ist.

Die Identitätskrise "Ich bin eigentlich kein Manager"

Wenn Sie das in Woche sechs noch sagen, hat Ihr Team es längst bemerkt. Sie hören es als: "Ich plane, zurück zum IC zu gehen, sobald es unangenehm wird", was sie weniger bereit macht, Ihnen die unbequemen Dinge zu bringen.

Ersetzen Sie es durch: "Ich bin ein Manager, der früher Code ausgeliefert hat. Jetzt liefere ich Menschen, die Code ausliefern." Sagen Sie es laut, wenn es sich beim ersten Mal seltsam anfühlt. Bis Woche zehn wird es das nicht mehr.

Die Überkorrektur

Der EM, der in Woche eins drei Management-Bücher liest und montags mit einem neuen Framework, einem neuen Ritual und einem umbenannten standup erscheint. Mitarbeitende hassen das. Sie haben kein neues Betriebssystem verlangt. Sie wollten einen Manager, der zuhört.

Erst zuhören. Dann ändern. Die 30-Tage-Prüfungsphase existiert genau dafür.

Vorlagen und Tools, die Sie wirklich nutzen werden

Vier Instrumente, die sich lohnen, einmal aufzubauen und dauerhaft zu verwenden:

• Frageskript für das erste Einzelgespräch. Die drei obigen Fragen plus drei Folgefragen: "Wie sieht eine gute Woche für Sie aus?" "Mit wem im Team sollte ich besonders viel Zeit verbringen?" "Was sollte ich wissen, das mir niemand von selbst sagen wird?"
• Beobachtungsprotokoll für 30 Tage. Drei Spalten: was ich gehört habe, was ich gesehen habe, was ich noch nicht ändere und warum. Die dritte Spalte ist die Disziplin.
• 90-Tage-Berichtsvorlage. Drei Folien, Struktur wie oben, mit harter Obergrenze für die Wortanzahl pro Folie, damit kein Padding entsteht.
• Skript für kritische Feedback-Gespräche. Situation, Verhalten, Auswirkung, Bitte. Ausdrucken. Vor jedem schwierigen Einzelgespräch in den ersten sechs Monaten ausfüllen.

Erfolgsmessung an Tag 90

Sie wissen, dass die 90 Tage gewirkt haben, wenn am letzten Tag alle fünf dieser Punkte zutreffen:

1. Jeder direkt unterstellte Mitarbeiter hat mindestens 6 Einzelgespräche mit Ihnen geführt und kann benennen, woran Sie für ihn arbeiten.
2. Die Team-Velocity wird gemessen und zeigt einen Trend. Selbst wenn der Trend flach ist, wissen Sie genau warum.
3. Ein Prozess ist sichtbar besser, und das Team schreibt Ihnen das an.
4. Ihr skip-level kann das größte Risiko Ihres Teams in einem Satz beschreiben, weil Sie es ihm mitgeteilt haben.
5. Sie haben in 90 Tagen keinen Code gemergt, und das Team kommt damit zurecht.

Der letzte Punkt ist der eigentliche Test. Die 90 Tage beweisen nicht, dass Sie noch programmieren können. Sie beweisen, dass Sie es lassen können.

Mehr erfahren

• Einzelgespräche führen, auf die Ihre Mitarbeitenden sich freuen
• Der Übergang vom Ausführen zum Führen
• Ehemalige Kollegen führen
• Staff Software Engineer JD Template