The Project
The instinct in a major incident is for the most senior technical person to dive onto the keyboard. I have learned that this is exactly how the person who should be coordinating becomes the bottleneck. When I serve as Incident Commander, my job is not to fix the problem myself. It is to make sure the right people are fixing it, that they can work without interruption, and that everyone who needs to know what is happening stays informed.
Command, not keyboard
I keep the command role separate from the hands on the keyboard. I bring in the responders who actually know the failing system, and then I get out of their way. My attention goes to the shape of the incident: what we know, what we are trying, who is doing what, and what we will do if the current attempt does not work. The responders own the fix. I own the coordination.
Protecting responder focus
During a serious event, the pressure to give updates can pull technical responders out of the work every few minutes. I put myself between that pressure and the people restoring service. I gather status on a cadence that does not interrupt them, and I answer the questions coming from leadership and customer-facing teams so the responders do not have to.
Keeping stakeholders informed
Leadership and customer-facing stakeholders need a clear, honest picture: what is affected, what we are doing, and when they will hear from me next. Steady communication buys the technical team room to work and keeps the organization from spinning up its own parallel, conflicting response.
Wrap Up
Good incident command is mostly restraint. The measure of it is that the people closest to the problem get to focus on the problem, the rest of the organization stays calm and informed, and service is restored without the commander ever needing to touch the keyboard.