Einleitung: Den Mythos der Dienstjahre entzaubern
Viele Einstellungsprozesse greifen immer noch auf einen einfachen Filter zurück: Mehr Jahre mit dem Titel „Manager“ bedeuten stärkere Führung. Das ist bequem, aber irreführend. Dienstjahre messen die Zeit in der Rolle, nicht die Wirkung. Du kannst fünf Jahre lang ein stabiles Team führen, ohne Menschen zu entwickeln, Strategie zu prägen oder die Lieferung zu verbessern. Gleichzeitig üben viele Entwicklerinnen und Entwickler in der Mid-Career-Phase jede Woche zentrale Management-Skills aus – sie mentorieren Kolleginnen und Kollegen, stimmen Stakeholder ab, räumen Blockaden aus dem Weg und treffen Entscheidungen unter Druck – ganz ohne formalen Titel.
Großartige Engineering-Manager werden durch Ergebnisse definiert, nicht durch Etiketten. Hast du einer leistungsschwachen Teamkollegin geholfen, sich deutlich zu verbessern? Hast du einen riskanten Launch funktionsübergreifend gesteuert? Hast du ein vages Problem in einen Plan verwandelt, den das Team liefern konnte? Das sind Führungsverhaltensweisen. Einstellende Manager, die Wert auf Resultate legen, reagieren auf Belege, nicht auf Kalender-Mathematik.
Dieser Artikel zeigt dir, wie du diese Belege präsentierst. Du lernst, wie du deine täglichen Beiträge in ein aussagekräftiges Engineering-Manager-Portfolio überführst, das Führung auch ohne Dienstjahre zeigt. Wir verwandeln Aktivitäten, die du vermutlich bereits tust – Mentoring sichtbar machen, Design-Reviews moderieren, Incidents koordinieren, Roadmaps beeinflussen – in konkrete Artefakte und funktionsübergreifende Impact-Beispiele. Außerdem zeigen wir, wie du nichttraditionelle Engineering-Erfahrungen (Open Source, Community-Leadership, Ehrenamt, Startup-Chaos) hervorhebst, die People Leadership, Urteilsvermögen und Systemdenken signalisieren.
Wenn in deinem Lebenslauf jahrelang nicht „Manager“ steht, ist das keine Sackgasse. Es ist eine Chance, eine klarere Geschichte zu erzählen: So entwickle ich Menschen, reduziere Risiken und liefere Wert. Der Rest dieses Guides gibt dir Vorlagen, Beispiele und Belege, um diese Geschichte unwiderlegbar zu machen.
Definiere neu, was als Führungserfahrung zählt
Führungserfahrung ist nicht darauf beschränkt, direkte Reports zu haben. Für ein Engineering-Manager-Portfolio fokussiere dich auf übertragbare Führungssignale, die du bereits gezeigt hast:
- Mentoring: andere durch Code-Reviews, Pairing, Onboarding-Guides, Brown-Bags und Karriere-Coaching weiterentwickeln.
- Technische Entscheidungsfindung: Optionen rahmen, Trade-offs klären und eine Entscheidung herbeiführen, die Teams entblockt und Risiko reduziert.
- Stakeholder-Abstimmung: Erwartungen über Product, Design, Security, Ops und Kundschaft hinweg setzen; gemeinsame Pläne schaffen; Überraschungen vermeiden.
- Ergebnisverantwortung: Erfolgsmetriken definieren, gegen sie ausführen und mit Postmortems und Learnings den Kreis schließen.
Kurzfristige Projekte können Führung ohne Dienstjahre belegen. Einen dreiwöchigen „Bug Burn-Down“-Sprint geleitet? Das mappt auf Ergebnisverantwortung (klares Ziel, tägliche Metriken), technische Entscheidungsfindung (Triage-Regeln, Schweregrade), und Stakeholder-Abstimmung (gemeinsame Prioritäten mit Support und PM). Halte in deinem Portfolio fest: Ziel, Constraints, Entscheidungsprozess, Vorher/Nachher-Metriken und wie du das Team motiviert hast.
Freiwilligenkoordination ist valide nichttraditionelle Engineering-Erfahrung. Eine Community-Hackathon-Organisation oder ein DEI-Mentoring-Kreis zeigt Kapazitätsplanung, Kommunikation und Konfliktlösung. Übersetze das so: „40 Freiwillige über 5 Workstreams koordiniert; ein Runbook erstellt; 95% pünktliche Session-Starts erreicht; einen Feedback-Loop implementiert, der den NPS von 62 auf 82 erhöhte.“ Das sind funktionsübergreifende Impact-Beispiele, die Hiring-Teams auf Teamführung mappen können.
Interne Initiativen – etwa den Incident-Response-Prozess aufsetzen, trunkbasiertes Development pilotieren oder flaky Tests entfernen – mappen direkt auf Management-Kompetenzen. Du hast ein systemisches Problem identifiziert, Konsens aufgebaut, Veränderung umgesetzt und Ergebnisse gemessen. Dokumentiere Problemstellung, Stakeholder, Entscheidungslog, Rollout-Plan und Resultate (z. B. MTTR −30 %, Deploy-Lead-Time von Tagen auf Stunden gesenkt).
Dein Vorteil: Kuriere und beschrifte diese Stories explizit als „Mentoring“, „Entscheidungsfindung“, „Abstimmung“ und „Ownership/Verantwortung“. Dieses Framing hilft Reviewerinnen und Reviewern, Führungssignale auch ohne formale Titel zu erkennen.
Portfolio-Bausteine, die Führung belegen (mit Beispielen)
Dein Engineering-Manager-Portfolio sollte sich wie Beweisführung lesen, nicht wie Autobiografie. Baue diese Bausteine, um Führung ohne Dienstjahre unwiderlegbar zu machen.
Mentoring-Dossiers Erstelle pro Mentee, den du gecoacht hast (Directs, Praktikantinnen, New Grads, Peers, sogar Open-Source-Beitragende), ein 1–2-seitiges Briefing. Enthalten:
- Wer und Ziel: „IC2-Backend-Engineer mit Ziel IC3-Beförderung; Probleme mit PR-Qualität und Stakeholder-Updates.“
- Interventionen: „Wöchentliche 30-min Code-Review-Drills, Incident-Shadowing, Demo-Probeläufe, Checkliste für ‚Definition of Done‘.“
- Artefakte: Beispiel-PR Vorher/Nachher, Mapping zur Karriere-Rubrik, Feedback-Notizen (anonymisiert), Lernplan.
- Ergebnisse mit Vorher/Nachher-Metriken:
- PR-Rework-Rate: 38% → 12% in 8 Wochen
- On-Call-Readiness: Shadow → Primary in 6 Wochen; MTTR beim ersten Incident: 52m
- Beförderung: IC2 → IC3 in 9 Monaten
- Cross-Team-Feedback-Score: 3.2/5 → 4.4/5 Das ist Mentoring so präsentiert, dass Hiring-Panels es quantifizieren können. Es hebt auch nichttraditionelle Engineering-Erfahrung hervor, etwa eine Community-Beitragende zur ersten großen Patch-Landung zu führen.
Funktionsübergreifende Fallstudien Verpacke 2–3 funktionsübergreifende Impact-Beispiele mit einer einfachen Erzählstruktur:
- Problem und Einsatz: „Checkout-Fehler stiegen auf 2.1%, ~120.000 $/Tag an fehlgeschlagenen Zahlungen.“
- Deine Rolle in der Abstimmung: „Payments, Mobile, Risk koordiniert; gemeinsame Erfolgsmetriken gesetzt (Fehlerrate <0.5%, stabile Betrugsrate).“
- Entscheidungen und Trade-offs: „Neue Features zurückgestellt; Idempotency Keys ergänzt; Canary-Ramp mit Kill-Switch eingeführt; Risk auf Threshold-Anpassungen ausgerichtet.“
- Ergebnis und Nachweis:
- Fehlerrate: 2.1% → 0.3% in 10 Tagen
- Betrug unverändert; Umsatz zurückgewonnen; Support-Tickets −47%
- Stabilität nach Launch: 0 Kritische in 30 Tagen
- Artefakte: Entscheidungslog, Rollout-Plan, Screenshots des Metrik-Dashboards. Dieses Format zeigt, dass du Alignment schaffen, Entscheidungen treffen und messbare Ergebnisse liefern kannst – genau das, was eine EM tut.
Operative Verbesserungen und Incident-Postmortems Behandle Prozessgewinne als Portfolio-Assets, die strategisches Denken und Prozess-Ownership zeigen:
- On-Call-Überarbeitung: „Runbooks, Rotationen und Alert-Tuning eingeführt.“
- Pages/Eng/Woche: 14 → 5
- MTTR: 76m → 28m
- Burnout-Umfrage: 2.9/5 → 4.1/5
- Delivery-Pipeline: „Trunkbasiertes Development und CI-Gates ergänzt.“
- Deployment-Frequenz: wöchentlich → täglich
- Fehlerrate bei Änderungen: 18% → 7%
- Durchlaufzeit: 5 Tage → 1.5 Tage
- Incident-Postmortem: „Sev-1 wegen Cache-Stampede.“
- Root Causes gemappt; Rate Limiter + Request Coalescing ausgeliefert
- Wiederholungen: 3/Monat → 0 in 60 Tagen
- Lernschleife: blameless Retro, Trainingsmodul, Runbook-Update Füge Links zu RCAs, Dashboards, Checklisten und SOPs hinzu. Auch wenn du nicht der „Manager“ warst, bringt dich die Ownership von Analyse und Nachverfolgung als Führung ohne Dienstjahre ins Rampenlicht.
- On-Call-Überarbeitung: „Runbooks, Rotationen und Alert-Tuning eingeführt.“
Setze diese Bausteine zu einem prägnanten Engineering-Manager-Portfolio zusammen: Einseiter-Zusammenfassungen mit verlinkten Belegen. Die Mischung aus Mentoring-Dossiers, funktionsübergreifenden Fallstudien und operativen Verbesserungen macht alltägliches Problemlösen zu klaren Führungssignalen.
Wie du Artefakte und Narrative erstellst, wenn dir formale Rollen fehlen
Behandle Alltagsmomente – Standups, Design-Reviews, Incident-Calls und Code-Reviews – als Rohstoff für dein Engineering-Manager-Portfolio. Erfasse sie als kurze Impact-Stories im einfachen Kontext–Aktion–Ergebnis-Format.
- Kontext: Was war kaputt oder unklar? Wer war beteiligt? Was stand auf dem Spiel?
- Aktion: Was hast du entschieden, moderiert oder gelehrt? Wie hast du Menschen ausgerichtet?
- Ergebnis: Was hat sich verändert – nach Möglichkeit mit Zahlen – plus Signale von anderen.
Beispiele, die du in 5–7 Sätzen schreiben kannst:
- Design-Review: API-Oberfläche war zwischen zwei Teams uneindeutig. Ich habe ein 45‑minütiges Entscheidungs-Review mit PM und SRE geleitet, ein ADR-Template vorgeschlagen und Konsens zur Versionierungsstrategie herbeigeführt. Ergebnis: 30% weniger Integrationsbugs im nächsten Release, Onboarding-Guide von beiden Teams übernommen.
- Code-Reviews: PR-Queue lag im Schnitt bei 2.5 Tagen. Ich habe eine Reviewer-Rotation und Checkliste eingeführt, zwei ICs in Review-Qualität gecoacht. Ergebnis: Median-Review-Zeit sank auf 14 Stunden; Release-Kadenz wechselte von zweiwöchentlich zu wöchentlich; zwei Mentees erhielten Peer-Empfehlungen mit Verweis auf klarere Reviews.
- Incident-Nachbereitung: Wiederkehrender Ausfall mit unklarer Ownership. Ich moderierte ein blameless Postmortem, klärte das On-Call-Runbook und definierte SLIs mit Product. Ergebnis: 40% geringere MTTR über 2 Monate; Support meldete weniger Eskalationen.
Quantifiziere, wo möglich:
- Delivery: kürzere Zykluszeit, schnellere Review-Latenz, verbesserte Release-Kadenz.
- Qualität/Zuverlässigkeit: weniger Incidents, niedrigere MTTR, Defect-Escape-Rate.
- Teamgesundheit: Onboarding-Dauer, Mentoring-Ergebnisse, Durchsatz im Hiring-Funnel.
Füge qualitative Signale hinzu, um Führung ohne Dienstjahre zu belegen:
- Kurze Zitate von Teammitgliedern, PMs oder SREs.
- Slack-Kudos, Peer-Feedback, Auszüge aus Performance-Reviews.
- Funktionsübergreifende Impact-Beispiele, z. B. „QA übernahm unsere Teststrategie; Support reduzierte Ticket-Bearbeitungszeit um 20%.“
Formate, die gut funktionieren:
- Einseitige Fallstudien: Problem, Constraints, deine Rolle, Aktionen, Ergebnisse, Artefakte (Link zu ADRs, Runbooks, PRs).
- Foliensatz (5–7 Folien): Vorher/Nachher-Metriken, Entscheidungstimeline, Lessons Learned.
- GitHub-Repo: README mit Zusammenfassung von Initiativen; annotierte Commits, die auf Entscheidungen verlinken; Beispiel-RFCs/ADRs; Issue/PR-Templates; Runbooks. Nutze bei Bedarf geschwärzte Beispiele.
- Rubrik „Leadership-Highlights“ in deinem CV/auf deiner Portfolio-Seite: 5–7 Bullet Points mit Outcomes (z. B. „4 Engineers gementort; 2 innerhalb von 12 Monaten befördert“, „Release-Checkliste standardisiert; wöchentliche Releases 2 Quartale lang gehalten“).
Praxistipps:
- Führe ein wöchentliches Impact-Log; wandle starke Einträge monatlich in Artefakte um.
- Anonymisiere sensible Daten; zeige Formen/Verläufe von Metriken, keine Geheimnisse.
- Führe mit Outcomes in Titeln: „PR-Latenz 44% gesenkt via Reviewer-Rotation“, nicht „Bei Code-Reviews geholfen“.
- Verlinke Artefakte miteinander, damit Reviewerinnen und Reviewer deine nichttraditionelle Engineering-Erfahrung end-to-end nachvollziehen können.
Praktische Checkliste und nächste Schritte zum Aufbau deines Manager-Portfolios
Inventur (1–2 Stunden)
- Liste Projekte, Incidents, Migrationen, On-Call-Erfolge, Hiring/Interview-Loops, Tech-Debt-Abbauten und Standards, die du beeinflusst hast.
- Ergänze Mentoring-Momente: jemanden onboarden, eine Peer entblocken, Code-Reviews moderieren, die Teamgewohnheiten verändert haben.
- Sammle funktionsübergreifende Impact-Beispiele: Partnerschaft mit Product/Design/Security/Support zur Erreichung einer gemeinsamen Metrik.
- Ziehe Artefakte heran: RFCs, Designdocs, Dashboards, PRs, Postmortems, Roadmap-Folien, Slack/Email-Kudos, Kundentickets.
- Quantifiziere Vorher/Nachher, wo möglich: MTTR, Lead Time, Defektrate, Latenz, Kosten, NPS/CSAT, Feature-Adoption.
3–5 stärkste Stories priorisieren (30 Minuten)
- Wähle Vielfalt: Delivery, Reliability, Teamgesundheit und eine bereichsübergreifende Initiative.
- Bevorzuge Stories mit klaren Outcomes, deiner Führung ohne Dienstjahre und messbarem Impact.
Belege sammeln (60–90 Minuten)
- Ergänze Metriken, Timelines, Stakeholder-Namen/-Rollen und 1–2 Zitate.
- Verlinke Beweise (bei Bedarf schwärzen). Wenn Metriken privat sind, zeige relative Veränderung (z. B. „P95 um ~35% gesenkt“).
Narrative verfassen (60 Minuten)
- Nutze Problem → Aktionen → Ergebnis → Was ich anders machen würde.
- Mache deine Rolle explizit: Wo du Richtung gesetzt, Trade-offs verhandelt, gecoacht oder Prozess geschaffen hast.
- Halte jede Story bei 300–500 Wörtern mit einer 2–3‑Satz-Zusammenfassung oben.
Publizieren und iterieren (60 Minuten)
- Stelle dein Engineering-Manager-Portfolio auf eine einfache Site oder in ein Doc (Notion/GitHub Pages/Google Doc).
- Inklusive 1‑Seiten-Übersicht, 3–5 Story-Seiten und Links zu Artefakten.
- Bitte zwei Managerinnen/Manager um Feedback; überarbeite Titel, Metriken und Klarheit.
Interviewvorbereitung: nichttraditionelle Erfahrung selbstbewusst erzählen
- Baue drei Laufzeiten pro Story: 30‑Sekunden-Teaser, 2‑Minuten-Überblick, 5‑Minuten-Deep-Dive.
- Mappe jede Story auf Leadership-Themen: Priorisierung, Stakeholder-Abstimmung, Konfliktlösung, Risikomanagement, Mentoring sichtbar machen.
- Nutze „wir“ für Teamerfolge und „ich“ für deine spezifischen Entscheidungen.
- Für Design-/Leadership-Übungen:
- Beginne mit der Klärung von Zielen, Constraints, Stakeholdern und Erfolgsmetriken.
- Skizziere einen Plan: Meilensteine, Entscheidungslog, Kommunikationskadenz, Risiken/Mitigations, wie du Outcomes misst.
- Stütze dich auf nichttraditionelle Engineering-Erfahrung (z. B. Community-Arbeit, OSS-Maintenance), um Urteilsvermögen und Koordination zu zeigen.
- Bringe ein 1–2‑seitiges Leave-Behind deiner Portfolio-Highlights mit.
Schnell neue Belege schaffen (2–4 Wochen)
- Leite eine Brown-Bag-Serie (3 Sessions): Thema wählen (On-Call Excellence, Incident-Review, Performance-Tuning), Feedback sammeln, Folien und Attendance-Metriken teilen.
- Führe ein Mini-Cross-Team-Projekt durch: zweiwöchiger Bug Bash oder Reliability-Sprint mit RFC, Ownern und einer einfachen Metrik (z. B. MTTR ↓ 25%, P95‑Latenz ↓ 20%).
- Veröffentliche ein blameless Postmortem: klare Timeline, Root Causes, Actions und 30‑Tage-Follow-up-Resultate.
- Bonus-Quick-Wins: Onboarding-Guide schreiben, Office Hours starten oder ein Decision-Template pilotieren – jedes ist ein Portfolio-Artefakt.
Nächste Schritte diese Woche
- Tag 1: Inventur und Auswahl deiner 3–5 Stories.
- Tag 2: Quantifizieren und Artefakte sammeln.
- Tag 3: Narrative entwerfen; 1‑Seiten-Übersicht erstellen.
- Tag 4: Leichtgewichtiges Portfolio veröffentlichen; zwei Feedback-Reviews terminieren.
- Tag 5: 30s/2m/5m‑Versionen proben; ein kleines Experiment wählen, das am Montag startet.