Your phone buzzes. The dashboard is red. Someone just typed "is this the outage from last month again?" in the incident channel, and forty more people are about to join it. Being a strong engineer does not make you a competent incident commander - it can actively work against you. The instinct that makes you good at debugging (dive in, go deep, fix it yourself) is precisely the instinct that makes incidents last longer and communication break down, because the room now has no one coordinating it. Most engineers get handed the IC rotation with a PagerDuty schedule and zero formal training in the actual job: running the room, not the terminal. The Incident Commander's Handbook is the training you didn't get. It's built for engineers, staff and principal-level, who need the real operating model - not leadership platitudes about staying calm - for running an incident from the first page to a postmortem that actually prevents a repeat. Inside, you'll learn: The actual job of an incident commander: coordinate, don't debug - and why that's the hardest instinct for a strong engineer to unlearn How to declare an incident without ego, and why teams under-declare until a small issue becomes a large one A working severity framework - who gets paged, at what severity, and why paging everyone for everything trains people to ignore pages How to run an incident channel so it doesn't collapse into forty people typing at once, including the specific cadence for updating stakeholders versus the technical response team When and how to escalate - and to whom - without it reading as blame Why you mitigate before you root-cause, and how to make that call under pressure How to run a genuinely blameless postmortem that produces owned, dated action items instead of a document nobody rereads The Five Whys done properly versus done as theater, and how to tell the difference in the room The practical starting toolkit for chaos engineering - controlled failure injection to find your failure modes before production does How to build a just culture where near-misses get reported instead of hidden, and how to design on-call rotations that don't burn out the people running them The book closes with a full worked incident - composite and explicitly illustrative, not a real company's outage - walked from the first page to the final postmortem, so every mechanism in the book lands as one continuous, repeatable playbook. This book is educational and does not guarantee any specific professional, technical, or business outcome.



Imad Muratspahic is an independent author of practical how-to guides, technical handbooks, history and fiction. The books aim to be clear, honest and useful from the first page.