Published incident management frameworks assume a dedicated reliability team, a rota of incident commanders and a war room. Most companies running important software have none of those, and conclude that incident process is for larger organisations. The conclusion is wrong: four practices deliver nearly all the benefit and none of them requires a specialist.
First, one person is in charge, and it is not the person fixing the problem. The moment two engineers are involved, someone must coordinate - decide what is being tried, keep others out of the way, and communicate outward - because the engineer holding the debugger cannot also answer the sales director asking for an update. On a small team this rotates and it is a role rather than a job title. Naming it explicitly at the start of an incident is the single highest-return change available.
Second, communicate on a schedule rather than when there is news. Every thirty minutes, even if the update is that you are still investigating. Silence during an outage is read as absence of effort, and it generates exactly the interruptions that slow the work. A fixed cadence buys the responders quiet time between updates, which is the actual point.
Third, mitigate before diagnosing. The instinct of good engineers is to understand the problem, and during an incident that instinct is expensive. Roll back the deployment, fail over, disable the feature, scale up - restore service first and investigate afterwards with the pressure off. A rollback that turns out to have been unnecessary costs almost nothing; an hour of root-cause analysis while customers are down costs a great deal.
Fourth, write it down as you go. A running timeline of what was observed and what was tried, in whatever channel you are already using. Nobody reconstructs this accurately afterwards, and it is the raw material for the review. It also stops the second responder repeating something the first already ruled out.
Then do the review, and do it blamelessly and quickly - within a few days, while people remember. The output is not a document, it is two or three specific changes with owners and dates: the alert that should have fired, the runbook that did not exist, the dependency nobody knew about. Reviews that produce a beautifully written narrative and no tracked actions are theatre. The measure of whether any of this is working is simple: is incident volume trending down quarter over quarter, and are the same causes recurring?
