Was macht ein Incident Manager? Rolle, Skills, Karriere und Praxisbeispiel

Einleitung: Warum Incident Management für IT-Teams entscheidend ist

Ob E-Commerce-Checkout, Banking-App oder IoT-Plattform: Ausfälle passieren – in jeder ausreichend komplexen IT-Landschaft. Wenn der Ernstfall eintritt, entscheidet professionelle Incident-Steuerung über Nutzerauswirkungen, Umsatzverlust und Vertrauen. Genau hier kommt der oder die Incident Manager:in ins Spiel: Diese Rolle koordiniert die Reaktion auf Störungen, sorgt für klare Kommunikation und treibt die Ursachenanalyse und Verbesserungen voran. Für Kandidat:innen eröffnet sich damit ein spannendes Karrierefeld zwischen Technik, Kommunikation und Prozessverantwortung.

Was ist ein Incident Manager? Rolle und Abgrenzung

Ein Incident Manager verantwortet die Effektivität und Effizienz des Incident-Management-Prozesses und ist in kritischen Situationen die erste Eskalationsinstanz. Im Tagesgeschäft bedeutet das: priorisieren, die richtigen Teams aktivieren, Entscheidungen herbeiführen und Stakeholder außen wie innen informiert halten. In vielen Organisationen führt die Rolle auch das Major-Incident-Team bei schwerwiegenden Störungen.

Diese Einordnung folgt dem ITIL-geprägten Verständnis von Prozessverantwortung (inklusive Berichtswesen und Eskalation). Parallel dazu hat sich im SRE/DevOps-Umfeld ein Einsatzführungsmodell etabliert, das klare Incident-Rollen definiert und die Reaktion entlang von „Koordinieren, Kommunizieren, Kontrollieren“ organisiert. Google SRE beschreibt diesen Ansatz ausführlich im Incident Command System (ICS)-Stil und dient vielen Tech-Unternehmen als Blaupause.

Incident Manager vs. Incident Commander vs. Incident Controller

• Incident Manager (ITIL-Kontext): Prozessverantwortung, Eskalationsführung, Sicherstellung, dass Incidents innerhalb der vereinbarten Service Levels bearbeitet werden. Bei Major Incidents oft Leitung des Einsatzteams.
• Incident Commander (SRE/ICS): operative Einsatzleitung im laufenden Incident. Die Person priorisiert, teilt Aufgaben zu und hält die Lage stabil, während technische Leads mitigieren. Die Führungsrolle kann zwischen Personen wechseln, bleibt aber immer eindeutig besetzt.
• Incident Controller: teils synonym oder als unterstützende Koordinationsrolle genutzt, je nach Unternehmenssprache. Wichtig ist weniger der Titel als die klare Verantwortlichkeit im Einsatzfall.

Praxis: In produktorientierten Tech-Organisationen findet man häufig die ICS-Rollen („Commander“, „Comms Lead“, „Ops Lead“); in stärker ITIL-geprägten Umgebungen heißen die Führungsrollen eher „Incident Manager/Major Incident Manager“. Beides lässt sich kombinieren – entscheidend sind klare Zuständigkeiten.

Abgrenzung zu Service Desk, 1st/2nd/3rd‑Level und Problem Management

• Service Desk und 1st Level übernehmen Erfassung, Vorqualifizierung und initiale Lösungsversuche. 2nd/3rd Level arbeiten technische Tickets ab und liefern Workarounds oder Fixes.
• Der oder die Incident Manager:in steuert übergreifend: Priorisierung nach Impact/Dringlichkeit, Eskalationen, Statuskommunikation und – bei Major Incidents – die End-to-End-Koordination.
• Problem Management ist separiert: Dort geht es um Ursachenforschung und strukturelle Abstellung wiederkehrender Störungen. Incident Management fokussiert die schnelle Wiederherstellung des Service innerhalb von SLAs/SLOs; die strukturierte Aufarbeitung folgt nach der Stabilisierung.

Kernaufgaben im Tagesgeschäft

Vorbereitung und Prävention: Playbooks, Rufbereitschaft und Alerting

Gute Reaktion beginnt vor dem ersten Alarm. Ein belastbares Setup umfasst nutzerzentriertes, SLO-basiertes Monitoring, praxistaugliche Alarmierung, klare Bereitschaftsregelungen und gepflegte Runbooks. Playbooks beschreiben Debug- und Mitigationsschritte pro Service; regelmäßige Übungen („Game Days“ oder Simulator-Trainings) erhöhen die Souveränität – insbesondere bei neuen Teammitgliedern. Wo sinnvoll, hilft Automatisierung bei Standardaufgaben, damit sich Menschen auf Entscheidungen konzentrieren können.

Reaktion und Koordination während eines Incidents: die 3Cs

In der Akutphase zählt Geschwindigkeit mit Struktur. Ein bewährtes Prinzip sind die 3Cs:

• Koordinieren: Rollen besetzen, Ziele und nächste Schritte klären, Aufgaben zuweisen und Abhängigkeiten managen.
• Kommunizieren: Status für Stakeholder zielgruppengerecht bündeln – intern (Fachbereiche, Management) und extern (Statusseite, Support). Konsistente, nutzerorientierte Updates schaffen Vertrauen.
• Kontrollieren: Lagebild, Risiken und Wirkung der Maßnahmen fortlaufend prüfen; nötigenfalls Course-Correction und Eskalationen einleiten.

Typische Artefakte in dieser Phase sind ein zentrales Incident-Channel/War Room, eine Live-Timeline und ein geklärtes Update-Intervall. In größeren Organisationen werden zusätzlich dedizierte Leads eingesetzt (z. B. Communications Lead, Operations Lead), damit technische Minderung und Stakeholder-Updates parallel funktionieren – ein Muster, das im SRE-Umfeld etabliert ist und auch in klassischen IT-Organisationen gut funktioniert.

Steuerung von Major Incidents und Eskalationsverantwortung

Major Incidents (höchste Priorität) verlangen verkürzte Entscheidungswege, direktere Eskalationen und häufig die Einbindung zusätzlicher Funktionen (Service Owner, Security, Lieferanten). Der oder die Incident Manager:in entscheidet über Priorität, aktiviert zusätzliche Ressourcen und hält den Überblick über Risiken gegenüber SLA/SLO-Verpflichtungen. Wichtig ist, die operative Verantwortung eindeutig zu halten, auch wenn mehrere Fachteams parallel arbeiten.

Nachbearbeitung: Postmortems, Maßnahmenverfolgung und kontinuierliche Verbesserung

Nach der Stabilisierung beginnt die Lernphase. Wirksame Postmortems sind strukturiert, faktenbasiert und „blameless“. Sie enthalten in der Regel eine klare Zusammenfassung, eine präzise Timeline, Ursachen und beitragende Faktoren, Impact (technisch und geschäftlich), die dokumentierte Lösung sowie priorisierte Maßnahmen mit Terminen und Verantwortlichkeiten. Sinnvolle Kennzahlen sind unter anderem Time to Detect, Time to Respond/Resolve sowie Verfügbarkeits- und SLA/SLO-Bezug. Für die Praxis lohnt ein Blick in etablierte Leitfäden wie den Postmortem-Guide von PagerDuty, der eine gut nutzbare Struktur für Reviews beschreibt.

Der oder die Incident Manager:in stellt sicher, dass Maßnahmen ins Backlog übernommen, priorisiert und fristgerecht nachverfolgt werden – und dass gewonnene Erkenntnisse (z. B. bessere Alerts, ergänzte Runbooks, Trainingsbedarfe) in die Vorbereitung zurückfließen.

Wichtige Fähigkeiten und Kompetenzen (Hard & Soft Skills)

Technische Kenntnisse und Tools

Incident Manager müssen nicht jede Codezeile debuggen können, aber sie brauchen technisches Lese- und Steuerungsvermögen: Wie liest man Dashboards? Welche Logs sind relevant? Welche Deployments liefen zuletzt? Häufig genutzte Tool-Kategorien sind Monitoring/Observability, Ticketing/ITSM, Collaboration/ChatOps sowie Runbooks und Statusseiten. Entscheidend ist, diese Werkzeuge zu orchestrieren, statt sich in Details zu verlieren.

Kommunikations‑ und Moderationsfähigkeiten für Stakeholder‑Management

Klare, adressatengerechte Sprache ist erfolgskritisch. Aussagen wie „welcher Service ist betroffen, wie stark, was sind Workarounds, wann kommt das nächste Update“ müssen schnell und konsistent verfügbar sein. Gute Moderation verhindert Aktionismus, bündelt Expertise und macht Entscheidungen transparent. Das gilt nach innen und außen – vom Executive-Update bis zur Nachricht für Support-Teams.

Prozessverständnis, Metriken und KPIs

Incident Manager:innen arbeiten metrikgetrieben. Typische Größen sind Time to Detect/Respond/Resolve, Einhaltung von SLAs/SLOs, Anzahl und Dauer von Major Incidents, Qualität und Durchlaufzeit von Maßnahmen aus Postmortems. Ebenso wichtig: ein gutes Verständnis für Priorisierung (Impact × Dringlichkeit) und Eskalationsregeln – sie sichern, dass kritische Fälle die nötige Aufmerksamkeit und Ressourcen bekommen.

Wie wird man Incident Manager? Karrierepfade und Einstiegsmöglichkeiten

Viele starten aus nahegelegenen Rollen: Service Desk/1st Level, Site Reliability Engineering/Operations, Application Support, Service Owner oder technische Projektleitung. Wer hier bereits Bereitschaftsdienste, Major-Incident-Calls oder Release-/Change-Koordination kennt, bringt gute Voraussetzungen mit.

Zertifizierungen und Trainings helfen beim Vokabular, bei Prozessen und der gemeinsamen Sprache in heterogenen Organisationen. Weit verbreitet sind ITIL-Schulungen für Incident Management; wer im SRE-/DevOps-Umfeld arbeitet, profitiert zusätzlich von Praxisformaten rund um On-Call, Postmortems und Notfallübungen. Besonders wertvoll sind reale Einsatzerfahrungen und das Üben von Kommunikationssituationen – zum Beispiel über Rollenspiele oder Simulationen.

Erfahrungswerte für Bewerbungsunterlagen und Interviews

Lebenslauf und Gespräch sollten Wirkung belegen, nicht nur Verantwortlichkeiten. Konkrete, messbare Beispiele helfen:

• „Major-Incident-Prozess neu aufgesetzt; konsistente Kommunikations-Intervals eingeführt und TTR in kritischen Services über sechs Monate deutlich reduziert.“
• „SLO-basierte Alerts mit Service Ownern harmonisiert; Alert-Fatigue abgebaut, On-Call-Last gesenkt, gleichzeitig zuverlässigere Detection erreicht.“
• „Blameless-Postmortem-Format etabliert; Review-Quote und Maßnahmen-Durchlauf verbessert.“

Typische Fragen im Gespräch drehen sich um Priorisierungskonflikte, Eskalationsentscheidungen, Kommunikation unter Unsicherheit, Umgang mit unvollständigen Informationen und das Übersetzen technischer Risiken in Business-Impact. Hilfreich ist das STAR‑Format (Situation, Task, Action, Result), um Antworten strukturiert zu liefern.

Gehaltserwartungen und Arbeitgeberprofile in Deutschland

Konkrete Gehälter variieren stark nach Branche, Unternehmensgröße, Standort und Bereitschaftsanteil. In produktorientierten Tech-Unternehmen, IT-Dienstleistern und Managed-Service-Providern sind dedizierte Incident- oder Major-Incident-Rollen verbreitet. Auch Betreiber kritischer Infrastrukturen (z. B. Energie, Gesundheit, Mobilität, öffentliche Verwaltung) suchen Incident-Verantwortliche mit hohem Prozess‑ und Compliance-Verständnis. Größere Unternehmen unterscheiden häufiger zwischen Prozessverantwortung (Incident Manager) und operativer Einsatzführung (z. B. Incident Commander); in kleineren Organisationen werden diese Hüte oft von einer Person getragen. Für die eigene Einordnung lohnt der Blick auf Bereitschaftsmodelle, Rufbereitschaftszulagen und die Anzahl zu betreuender Services.

Praxisbeispiel: Ein typischer Major‑Incident‑Ablauf aus Sicht des Incident Managers

Ein Freitagabend, 19:12 Uhr: Die Fehlerquote im Checkout steigt sprunghaft. Ein SLO-basiertes Alert löst aus; die Rufbereitschaft betroffener Teams wird gepaged. Die Incident Managerin übernimmt die Einsatzleitung.

• Koordinieren: Sie eröffnet den Incident-Channel, benennt Rollen (Operations Lead für technische Minderung, Communications Lead für Updates) und steckt das erste Ziel: „Workaround oder Teilwiederherstellung innerhalb von 15 Minuten.“
• Kommunizieren: Ein internes Executive-Update nennt betroffene Regionen, Schweregrad, vermuteten Impact und Zeitpunkt des nächsten Updates. Support bekommt eine Kurzvorlage mit Workaround-Hinweisen.
• Kontrollieren: Die Timeline dokumentiert Fakten (Metriken, Deployments, Konfig‑Änderungen, Entscheidungen). Nach 10 Minuten identifiziert das Team eine fehlerhafte Konfiguration im neuen Payment‑Gateway. Rollback scheitert zunächst; ein Feature‑Flag schafft Teilentlastung, Priorisierung wechselt auf schnelle, risikoarme Minderung.

Nach 28 Minuten ist der Checkout stabilisiert. Ein externer Statushinweis kündigt an, dass Restprobleme einige Nutzer:innen betreffen können. Die Incident Managerin schließt die Akutphase, terminiert das Postmortem und benennt eine:n Owner. Im Review wird die Root Cause (fehlerhafte Konfiguration ohne ausreichende Canary‑Abdeckung) mit beitragenden Faktoren (unzureichende Runbook‑Schritte, unklare Eskalationskette zum Anbieter) aufgearbeitet. Maßnahmen: Canary-Rollouts für das Gateway verpflichtend, Runbook ergänzen, Eskalationskontakte des Anbieters prüfen, Monitoring auf nutzerzentrierte Metriken erweitern. Fristen und Verantwortliche werden festgehalten; die Umsetzung fließt priorisiert ins Backlog.

Fazit: Worauf Kandidat:innen achten sollten und wie sie sich positionieren

Incident Management ist mehr als „Feuerwehr“: Es verbindet technische Urteilsfähigkeit, Führung unter Zeitdruck, klare Kommunikation und konsequente Nachbearbeitung. Wer in diese Rolle gehen will, sollte

• Übung in On‑Call‑Szenarien und Major‑Incident‑Calls suchen,
• SLO‑basiertes Monitoring, Runbooks und Postmortems beherrschen,
• souverän moderieren und adressatengerecht kommunizieren können,
• und den kontinuierlichen Verbesserungszyklus ernst nehmen.

Für die Vertiefung bieten sich praxiserprobte Leitfäden an – etwa der Incident-Management-Ansatz im SRE-Umfeld von Google, der ICS-Rollen und die 3Cs beschreibt, oder strukturierte Postmortem-Guides mit klaren Templates und Metriken. Wer diese Prinzipien in Bewerbungen und Interviews mit konkreten, messbaren Beispielen hinterlegt, hat beste Chancen – quer durch Branchen, vom produktgetriebenen Scale-up bis zur kritischen Infrastruktur.

Weiterführend:

• Google SRE: Incident Management Guide – Rollen, 3Cs, Vorbereitung–Reaktion–Lernen: https://sre.google/resources/practices-and-processes/incident-management-guide
• Postmortem Documentation Guide – Struktur, Metriken, Verantwortlichkeiten: https://www.pagerduty.com/resources/insights/learn/how-to-write-postmortem
• ITIL-Rollenüberblick (u. a. Incident Manager, Major Incident Team): https://wiki.de.it-processmaps.com/index.php/Rollen_in_ITIL