Ein Tag im Leben eines Engineering Managers: Was die Stellenausschreibung verschweigt

Es ist 8:47 Uhr. Ihre on-call-Ingenieurin wurde um 3:14 Uhr wegen eines Postgres-Replikats angepingt, das sich um 3:22 Uhr von selbst erholt hatte, was bedeutet, dass sie acht Minuten Schlaf bekam statt den Rest der Nacht. Ihr skip-level möchte bis mittags ein Roadmap-Update, und Sie haben Notion noch nicht geöffnet. Sie haben in 13 Minuten ein 1:1 mit einer Senior-IC, auf das Sie sich nicht vorbereitet haben, und der Personalvermittler, der Sie vor sechs Monaten in diese Stelle vermittelt hat, beschrieb sie als "ein leistungsstarkes Team führen."

Dieser Satz ist wahr wie "Ich betreibe ein Restaurant" wahr ist, wenn man nachts um 23 Uhr Inventar macht und sich bei einem Stammgast wegen einer falschen Bestellung entschuldigt. Es ist die Überschrift. Die Stelle ist alles darunter.

Das ist, wie der Tag für einen Engineering Manager mit 5 bis 12 direkt unterstellten Mitarbeitern in einem B2B SaaS-Unternehmen tatsächlich aussieht. Echte Zeitstempel, echte Unterbrechungen, echte Abwägungen. Wenn Sie ein IC sind und den Wechsel abwägen, lesen Sie das und fragen Sie sich, ob es wie Arbeit klingt, die Sie jahrelang machen würden. Wenn Sie ein aktueller EM sind und sich wie ein Versager fühlen, weil Ihr Tag nichts als Unterbrechungen ist, lesen Sie das und erkennen Sie: Sie scheitern nicht. Sie machen die Arbeit.

8:00 Uhr: Standup-Vorbereitung, Slack-Triage und PagerDuty

Bevor Ihr Team sich einloggt, erledigen Sie die Arbeit, die niemand sieht.

PagerDuty öffnen. Die Vorfälle der letzten Nacht überfliegen. Wer wurde angepingt, was hat ausgelöst, war es real oder war es wieder der gleiche flatternde Alert, den Sie vor drei sprints zur Bereinigung markiert haben? War es real, braucht Ihre on-call-Ingenieurin heute Deckung; sagen Sie ihr in Slack, standup zu überspringen und weitere 90 Minuten zu schlafen. War es Rauschen, ist das ein Ticket für den, der Observability besitzt. So oder so entscheiden Sie vor standup, damit Sie die Störung absorbieren können, anstatt sie vom Team ausbaden zu lassen.

Dann Slack. Sie haben 47 ungelesene Nachrichten in sechs Kanälen. Sie lesen nicht nach Inhalt. Sie scannen nach zwei Dingen: wer ist blockiert, wer ist frustriert. Blockierte Ingenieure brauchen bis 10 Uhr einen freien Weg, sonst verlieren sie einen halben Tag. Frustrierte Ingenieure in öffentlichen Threads brauchen eine DM, keine öffentliche Antwort, und die DM muss wahrscheinlich noch heute Morgen passieren.

Linear öffnen. Oder Jira. Welches Ihr Team auch immer nutzt, die Frage ist dieselbe: Welche Tickets stecken im Review, welche sind durch eine Abhängigkeit außerhalb Ihres Teams blockiert, und welche sehen "in progress" aus, haben sich aber seit vier Tagen nicht bewegt? Diese letzte Kategorie ist die gefährliche. Ein Ingenieur, der ein Ticket seit vier Tagen nicht bewegt hat, ist entweder feststeckend und sagt es nicht, arbeitet an etwas, das er Ihnen nicht erzählt hat, oder sucht still woanders einen Job. Sie müssen bis Freitag wissen, was davon zutrifft.

Sie haben seit drei Wochen keinen Code geschrieben. Früher machten Sie diesen Teil des Tages mit einem Kaffee und einem Compiler. Jetzt machen Sie ihn mit einem Kaffee und dem Kontext von sieben Personen im Kopf. Der Wechsel von "Ich schreibe Code" zu "Ich räume Wege frei für 7 Menschen, die Code schreiben" ist die erste Sache, vor der niemand Sie warnt, und es ist der Teil, um den die meisten Ex-ICs still in den ersten sechs Monaten trauern.

9:00 Uhr: Das 1:1, auf das Sie sich nicht vorbereitet haben

Das 1:1 ist Ihre renditestärksten 30 Minuten der Woche, und es ist das Erste, das gestrichen wird, wenn Sprint-Planung überzieht. Heute ist es mit Maya, einer Senior-Backend-Ingenieurin. Sie ist seit drei Jahren dabei. Sie hat Ihre letzte große Migration veröffentlicht. Und vor zwei Wochen wechselte ihr LinkedIn-Profil still von "offen für Möglichkeiten: nein" zu "offen für Möglichkeiten: ja."

Sie beginnen nicht damit. Sie beginnen mit: "Wie geht es Ihnen diese Woche?" Und dann halten Sie den Mund.

Ein echtes 1:1 ist kein Statusbericht. Statusberichte finden in Linear und standup statt. Das 1:1 ist für alles, was nicht in ein Ticket passt: das Feedback, auf dem sie seit Wochen sitzt, die Architekturentscheidung, mit der sie nicht einverstanden ist, die Tatsache, dass ihr Manager (Sie) nicht stark genug zurückgedrängt hat, als Produkt ihr Redesign halbiert hat. Ihre Aufgabe ist es, es sicher zu machen, das Schwierige zu sagen, und dann zu handeln auf das, was sie sagt.

Um 9:18 Uhr feuert PagerDuty. Nicht der Service Ihres Teams, aber nah genug, dass Slack aufleuchtet. Sie werfen einen Blick auf ihr Telefon. Maya sieht, dass Sie schauen. Hier ist das Skript, das funktioniert:

"Das ist nicht von uns, aber Slack wird gleich laut werden. Geben Sie mir 20 Sekunden, um es zu stummzuschalten, und dann machen wir weiter. Ihre Zeit ist wichtiger als dieser Thread."

Dann stummschalten Sie es tatsächlich. Sie hören nicht die nächsten 12 Minuten halb zu, während Ihre Augen Slack-Benachrichtigungen verfolgen. Das 1:1 bekommt Ihre volle Aufmerksamkeit, oder Sie sagen es ab. Es gibt keine mittlere Option. Die mittlere Option ist, wie Senior-Ingenieure lernen, dass ihr Manager nicht wirklich da ist, und so wechselt Mayas LinkedIn von "ja" zu "Ich habe gerade ein Angebot angenommen."

10:30 Uhr: PR-Review, aber nicht für Korrektheit

Sie öffnen GitHub. Oder GitLab. Es gibt 14 offene PRs im Team. Sie reviewen sie nicht auf Korrektheit. Ihr staff engineer reviewt auf Korrektheit, und sie ist jetzt besser darin als Sie.

Sie reviewen auf Durchfluss.

Wer wartet seit mehr als 48 Stunden auf ein Review? Dieser Ingenieur verliert Momentum und wechselt wahrscheinlich den Kontext zu etwas anderem, was bedeutet, dass er, wenn das Review endlich kommt, eine Stunde braucht, um den Kontext zurückzuladen. Finden Sie den Reviewer, finden Sie heraus, warum er feststeckt, entsperren Sie es.

Welche zwei PRs berühren dieselbe Datei? Das ist ein Merge-Konflikt in der Entstehung, und einer dieser Ingenieure wird einen Morgen mit einem rebase verlieren. Bringen Sie sie jetzt zu einem 10-Minuten-Call zusammen.

Welcher PR hat sechs Runden Kleinkram-Kommentare bei einer 40-Zeilen-Änderung? Das ist ein Senior-Ingenieur, der zu vorsichtig mit einem Junior ist, und es erodiert das Vertrauen in beide Richtungen. Sie kommentieren nicht im Thread. Sie schreiben dem Senior eine DM: "Hey, die Änderung sieht gut aus. Genehmigen und weiter." Das ist die Entscheidung, die sonst niemand trifft, weil niemand sonst die Autorität hat, sie zu treffen.

GitHub ist ein Code-Tool für Ihre Ingenieure. Für Sie ist es eine Management-Oberfläche, ein Echtzeit-Dashboard, wo Aufmerksamkeit feststeckt, wo Zusammenarbeit Reibung erzeugt, und wo die Velocity Ihres Teams durch Review-Engpässe verloren geht. Nennen Sie das die PR-Queue-Gebühr. Jeder PR, der mehr als zwei Tage sitzt, kostet Sie Zinseszinsen an verlorenem Fokus, und Sie sind die einzige Person, deren Aufgabe es ist, das zu bemerken.

11:15 Uhr: Sprint-Planung, dann die Unterbrechung

Sie sind 15 Minuten damit beschäftigt, das Linear-Board des nächsten Sprints mit Ihrem tech lead zu verfeinern. Sie stoßen auf eine Geschichte, die sagt "Auth-Provider-Migration untersuchen", weil das keine Geschichte ist, das ist ein Quartals-Aufwand als Dienstagnachmittagsbeschäftigung verkleidet.

Slack: "hey, kurz 2 Min. für eine schnelle Frage?" Vom VP of Product.

Es sind nie zwei Minuten. Es ist nie eine Frage. Die "schnelle Frage" ist: "Wir verlegen den Launch des KI-Features um drei Wochen vor, was kann Ihr Team bis dahin realistischerweise liefern?" Diese Antwort erfordert, dass Sie die Kapazität Ihres Teams kennen, Ihre bestehenden Sprint-Verpflichtungen, Ihren technischen Schulden, der das KI-Feature blockiert, das PTO Ihrer Senior-Ingenieurin nächsten Monat, und die politische Realität, dass "nein, wir können nicht" ein karrieredefinierender Satz ist, den Sie nur ein paar Mal im Jahr einsetzen können.

Sie nehmen den Anruf. Sie geben die Antwort nicht im Anruf. Sie sagen: "Lassen Sie mich die Abhängigkeiten prüfen und bis 16 Uhr mit einer echten Zahl zurückkommen." Dann gehen Sie um 11:38 Uhr zur Sprint-Planung mit Ihrem tech lead zurück, der 23 Minuten lang höflich auf ihren Bildschirm gestarrt hat.

Das ist die Rolle, die keine Stellenausschreibung erwähnt: Kontext-Übersetzer. Sie sitzen zwischen Exec-Strategie ("wir wollen KI bis Q3") und Engineering-Realität ("die Auth-Migration blockiert das, und der Ingenieur, der Auth kennt, ist im Elternurlaub"). Sie können nicht zu beidem Ja sagen. Ihre Aufgabe ist es, das eine in das andere zu übersetzen, ohne das Vertrauen in eine der beiden Richtungen zu brechen. Manche Wochen gelingt das gut. Manche Wochen gelingt es schlecht und Ihr Team bekommt einen Schleudertrauma. Beides ist normal.

13:00 Uhr: Das Meeting mit sich selbst, das nie stattfindet

Nach dem Mittagessen zeigt Ihr Kalender "FOKUS: Q3-Planungsdokument." Es steht seit drei Wochen da. Es verschiebt sich täglich.

Das ist das Meeting-mit-sich-selbst-Problem. Die Arbeit, die ungestörtes Denken erfordert (der Quartalsplan Ihres Teams, Ihre Leistungsbeurteilungen, die Architekturentscheidung, die Ihr staff engineer am Freitag an Sie eskaliert hat) hat nie eine harte Frist für heute. Sie verliert also immer gegen die Arbeit, die das tut. Den on-call-Alert. Die Slack-DM vom Ingenieur, der Deckung braucht. Die "schnelle Frage" vom VP.

Die meisten EMs verlieren diesen Kampf. Das Q3-Dokument wird sonntags um 23 Uhr geschrieben, weil Ihr Director es montags braucht. Die Leistungsbeurteilungen werden in der Woche vor ihrem Fälligkeitsdatum zusammengequetscht, und man sieht es ihnen an.

Die Lösung ist unspektakulär: buchen Sie den Fokusblock in Ihrem Kalender und behandeln Sie ihn wie ein externes Meeting. Lehnen Sie überlappende Anfragen ab. Akzeptieren Sie, dass Sie in manchen Wochen den Block einem echten Brand opfern, und das ist in Ordnung, aber der Standard muss verteidigt werden. Die Ingenieure, die zu Senior EMs und Directors werden, sind diejenigen, die gelernt haben, ihre eigene Denkzeit zu schützen, bevor es zur Krise wird.

15:30 Uhr: Asynchrones Notion, kein Echtzeit-Slack

Am Nachmittag ist Ihr Gehirn erschöpft. Das ist der Moment, in dem Sie Ihre geringst-denkintensive, höchst-volumige Arbeit erledigen sollten: Dokumentation schreiben, die in Notion lebt und an Ihrem Tag nichts ändert, aber über die nächsten zwei Quartale kumuliert.

Das Team-Handbuch-Update. Das on-call-runbook, das Ihre Ingenieurin vor zwei Wochen angefordert hat. Die retro-Notizen des letzten Sprints, die Sie versprachen zu zirkulieren. Das Einstellungsloop-Kalibrierungsdokument, auf das Ihr Personalvermittler wartet.

Nichts davon ist dringend. Alles ist wichtig. Der Kumulationseffekt ist, dass in sechs Monaten, wenn Sie eine neue Ingenieurin einarbeiten, sie drei Notion-Seiten liest und in einer Woche Fahrt aufnimmt, statt Ihren tech lead einen Monat lang dieselben Fragen zu stellen. Das ist die Hebelwirkung schriftlicher Arbeit, und sie ist unsichtbar, bis Sie sie unterlassen und das Team langsamer wird, ohne dass jemand sagen kann warum.

17:00 Uhr: Arbeit an Beförderungsunterlagen

Das Team meldet sich ab. Sie öffnen Notion. Sie schreiben zwei Beförderungsunterlagen (eine für eine Ingenieurin, die Senior wird, eine für eine Ingenieurin, die Staff wird) und eine Selbstbeurteilung für sich selbst.

Beförderungsunterlagen sind die Arbeit, die jeden Tag verschoben wird, bis die Leistungsbeurteilungsperiode wie ein Lkw einschlägt. Und die Ingenieure, die befördert werden, sind diejenigen, deren Manager den Fall über den gesamten Zyklus hinweg mit konkreten Belegen aufgebaut haben, nicht diejenigen, deren Manager es über ein Wochenende mit vager Sprache über "nachgewiesene Wirkung" zusammengequetscht haben.

Hier ist ein Notion-Template-Ausschnitt, der wirklich funktioniert:

## Beförderungsfall: [Name] → [Level]

### Was sich im Umfang geändert hat (letzte 2 Quartale)
- [Spezifisches Projekt, von Anfang bis Ende geführt, mit messbarem Ergebnis]
- [Spezifische teamübergreifende Zusammenarbeit mit benanntem Ergebnis]
- [Spezifischer Mentoring-Moment mit benanntem Mentee und Ergebnis]

### Belege, dass die nächste Stufe bereits geschieht
- [Link zum Design-Dokument, das sie geschrieben haben]
- [Link zum Vorfall, den sie geleitet haben]
- [Link zu Feedback von Peer/skip-level]

### Risiken, die das Panel ansprechen wird (und Antworten)
- [Risiko]: [Vorbereitete Antwort]
- [Risiko]: [Vorbereitete Antwort]

### Anfragen an das Panel
- [Was Sie mehr / weniger gewichten sollen]

Der Risiken-und-Antworten-Abschnitt ist der, den die meisten Manager überspringen. Er ist der, der gewinnt. Beförderungspanels sind standardmäßig skeptisch, und Unterlagen, die ihre Einwände vorwegnehmen, erledigen 80% der Arbeit, bevor sie den Mund öffnen.

Sie beenden die ersten Unterlagen um 17:51 Uhr. Ihr Kind hat um 19 Uhr ein Konzert. Die zweiten Unterlagen erledigen Sie morgen, außer morgen gibt es ein 1:1, das Sie vergessen haben, eine Incident-Review und ein Kandidaten-Panel. Also erledigen Sie es Donnerstag. Vielleicht.

Der Skalierungsinflektionspunkt: 5 Ingenieure zu 9

Alles, was ich gerade beschrieben habe, funktioniert bei 5 Ingenieuren. Es bricht bei 9.

Bei 5 können Sie jeden PR im Kopf behalten. Sie können wöchentliche 1:1s mit allen haben und trotzdem Zeit zum Denken. Sie wissen, wer feststeckt, bevor er fragt, weil Sie es in der standup-Körpersprache sehen.

Bei 9 können Sie das nicht. Die Mathematik geht nicht auf. Neun 30-minütige wöchentliche 1:1s sind 4,5 Stunden; mit Vorbereitung und Follow-up ist das ein ganzer Tag. PRs, die Sie früher kurz überblickt haben, erfordern jetzt den Filter eines tech lead, bevor sie Sie erreichen. Standups hören auf, Signal zu sein, und beginnen, Status-Theater zu sein, weil es zu viele Stimmen gibt.

Die Systeme, die Sie bei 5 ignoriert haben, werden bei 9 unverzichtbar: ein schriftliches Team-Charter, damit neue Mitglieder den Standard kennen, eine on-call-Rotation, die nicht von Ihrem Gedächtnis abhängt, ein Einstellungsrubrik, das außerhalb Ihres Kopfes existiert, und 1:1s, die zweiwöchentlich für die erfahrensten Personen werden, weil sie es am wenigsten brauchen, und wöchentlich für Personen, die neu im Team oder neu auf Senior-Level sind.

Wenn Sie auf zweiwöchentlich wechseln, fühlt sich jemand vernachlässigt. Sagen Sie ihnen direkt warum. "Ich bin dünner ausgestreckt als früher. Zweiwöchentlich ist das, was ich aufrechterhalten kann. Wenn etwas Dringendes auftaucht, ist meine Slack-DM offen und ich antworte innerhalb einer Stunde." Die Ehrlichkeit kauft Ihnen mehr Wohlwollen, als die fehlenden 30 Minuten kosten.

Was die Stellenausschreibung falsch hatte

"Ein leistungsstarkes Team führen" bedeutet wirklich:

• Ihren Fokus schützen. Ein Großteil Ihres Tages besteht darin, Chaos zu absorbieren, damit sie es nicht müssen.
• Ambiguität übersetzen. Exec-Strategie ist absichtlich vage. Ihr Team braucht Tickets, keine Stimmungen.
• Ihre Zeit verteidigen. Nein sagen zur "schnellen Frage" des VP ist Teil der Arbeit, kein Ausweichen.
• Das Dokument schreiben, das sonst niemand schreiben wird. Runbooks, Charters, Beförderungsunterlagen, retro-Zusammenfassungen.
• Stress absorbieren, damit sie es nicht müssen. Das ist der unspektakuläre Kern der Rolle und der Teil, der Menschen erschöpft.

Die Stellenausschreibung sagt "Ergebnisse erzielen." Der Tag sagt "die Notion-Seite schreiben, die bedeutet, dass die nächste Person das nicht von vorne herausfinden muss."

Abschluss

Wenn alles in diesem Artikel anregend klingt (das 1:1, auf das Sie sich wirklich freuen würden, das Chaos, das Sie gerne übersetzen würden, die langsame Kumulation schriftlicher Dokumentation, die sonst niemand tun wird), sind Sie bereit.

Wenn es erschöpfend klingt (Sie würden lieber Code liefern als Meetings absorbieren, lieber schwierige technische Probleme lösen als menschliche), ist der IC-Track keine Degradierung. Es ist eine andere Form von Senior-Arbeit, und die Industrie belohnt sie endlich angemessen. Die Staff Software Engineer-Stellenausschreibung ist aus einem Grund der Begleiter zu diesem Artikel. Lesen Sie beides. Wählen Sie das, dessen schlechte Tage sich wie lohnende Arbeit anfühlen.

Die richtige Antwort ist die, bei der die schlechten Tage sich immer noch wie Arbeit anfühlen, die es wert ist.

Mehr erfahren

• Staff Software Engineer JD (Begleiter)
• Running 1:1s Engineers Don't Dread
• The IC-to-EM Transition
• Writing Promotion Packets That Actually Land