In this article
Before you start
Part of leadership interview questions.
Why interviewers ask this
A manager who handles incidents badly loses the team's trust in one bad weekend, and a manager who lets on-call decay loses people over a few quarters. Candidates report prompts such as being paged that a major site is down on a Saturday, or a reported prompt of incidents up 40% on an inherited team whose on-call rotation is burning people out. These are reported by candidates; no company's practice is claimed here.
The prompts separate two skills. The first is running a single incident calmly. The second is looking after the system that produces incidents: the rotation, the follow-up and the culture.
A weak answer says "I jump in and fix it" or "I make sure everyone works harder." A strong answer shows structure during the incident, a blameless review afterward, and a view of workload that treats a heavy pager as a signal about the system and not a personal failing.
Incident leadership for managers from first principles
- Incident commander
- An incident commander is the one person who holds the high-level state of a production incident, assigns the other response roles by need and priority, and makes the final calls during it, while delegating the hands-on repair work to other responders.
- Pager budget
- A pager budget is a cap on the number of paging incidents an on-call engineer should receive in one shift, set so that the engineer keeps time for follow-up work, and used by a manager to judge whether the on-call load is sustainable. Google's guideline is two per 12-hour shift.
In plain words
Think of a restaurant kitchen at the dinner rush. One person calls the orders, and the cooks cook. Customers hear from the front of house, not from the stove. The analogy breaks in one place: a head chef can pick up a pan, but an incident commander who starts debugging stops commanding.
In one precise sentence, incident leadership separates deciding, doing and telling, so that one person decides, specialists do and one person tells everyone else.
The rest of this page follows an incident in four steps. Then it turns to the part managers own between incidents: how heavy the pager is.
Step 1: Declare the incident and name one commander
An incident needs one commander from the first minutes, and one commander is named when the incident is declared. Declare early: the SRE book says to declare an incident if a second team is needed, if the outage is visible to customers, or if the issue is still unsolved after an hour of concentrated analysis. In Google's incident response chapter, the person who declares the incident typically becomes the IC.
Rank does not decide who commands. PagerDuty's training makes the IC the highest-ranking person on the call whatever their day-to-day rank, with final decisions. For a manager this cuts both ways. Do not override the commander because you outrank them, and do not hide from the role when nobody holds it. Say aloud which seat you are in: commander, stakeholder or supporter. When command changes hands, say so explicitly; the SRE book's example is "you're now the incident commander, okay?" You now know who decides; next is what that person does with the people around them.
Step 2: Split the roles and delegate every repair
The commander delegates every repair action to other responders and keeps the overall picture. Mitigate first: stop the impact before hunting for the root cause, which is the response priority in the Workbook's incident management section. Google's Workbook names three main roles: the incident commander, the Communications Lead (CL) and the Operations Lead (OL). The CL is the person who talks to responders and stakeholders. The OL is the person who runs the hands-on technical work. In Google's model the CL and OL report to the IC, and the commander holds every role not yet delegated. If an incident shrinks enough, the CL role can fold back into the IC.
PagerDuty's documentation is blunt that the commander is not a resolver: the IC should not run remediations, check graphs or read logs, and should delegate those tasks. The SRE book adds the payoff: a clear separation of responsibilities gives people more autonomy, because nobody has to second-guess colleagues. How much technical depth a manager needs for this is its own question; see how technical an engineering manager must be.
Text description of the diagram
- The commander holds every role not yet delegated.
- The Operations Lead runs the hands-on technical work.
- The Communications Lead handles updates and inquiries.
Step 3: Communicate on a rhythm and keep one living document
The Communications Lead gives periodic updates to responders and stakeholders. In the Workbook, the CL is the public face of the response and also handles inquiries, so the commander is not interrupted by every message. PagerDuty adds that a Customer Liaison drafts external messages when asked by the IC.
The commander's most important responsibility, according to the SRE book, is to keep a living incident document that several people can edit at once. It is the single place where state, decisions and open questions are written down, so a late joiner reads it instead of asking.
As a manager you can help most by shielding the response from executive pressure. Route senior questions to the CL, and agree the time of the next update before the current one ends. A good update says what is known, what is not known and when the next update comes. The skills overlap with stakeholder management for engineering managers.
Step 4: Close with a blameless postmortem and tracked actions
A blameless postmortem assigns tracked actions with owners, and its purpose is to understand what happened and why. Atlassian runs one for every severity 1 and 2 incident (the two most serious levels), names an owner who is accountable for completing it, and has approvers prioritize the follow-up actions in their backlog. Its stated attitude is: "We assume good intentions on the part of our staff and never blame people for faults."
Blameless does not mean unaccountable. Atlassian's handbook says the value of being blameless improves services by holding teams accountable, not by apportioning blame, and it commits to specific changes by specific dates. Its postmortems page also notes that when people feel their standing or career is at risk, they may hide the truth. Preventing recurrence means fixing the class of incident, not only the one trigger.
Step-by-step description
- One commander is named.
- Roles split; repairs delegated.
- Updates run on a rhythm.
- Blameless review, tracked actions.
- One commander is named when the incident is declared.
- The commander delegates every repair action to other responders.
- The Communications Lead gives periodic updates to responders and stakeholders.
- A blameless postmortem assigns tracked actions with owners.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Incident leadership continues between incidents, because on-call load is a manager's responsibility. Google's on-call article states: "SRE managers are responsible for keeping the on-call workload balanced and sustainable across these two axes" (Google Research, 2015). The two axes are quantity, the percentage of time spent on-call, and quality, the number of incidents per shift. The same article says SREs spend no more than 25% of their time on-call and another 25% on other operational work, so at least 50% goes to engineering. The Workbook targets a maximum of two incidents per on-call shift, to leave time for follow-up, and the SRE book gives the unit: no more than two events per shift, for example per 12 hours.
Now a hypothetical inherited team, matching the interview prompt. All inputs are illustrative: a baseline of 100 paging incidents a month, a 40% rise to 140, and a 30-day month split into 60 twelve-hour shifts. A 12-hour shift then averages 1.67 incidents at baseline.1 After a 40% rise it averages 2.33 against a budget of two per 12-hour shift.1 The budget allows 120 incidents a month, so incidents must fall by about 14.3% from 140 to meet it.1
| Quantity (illustrative inputs, computed) | Value |
|---|---|
| Twelve-hour shifts in a 30-day month | 60 |
| Incidents per 12-hour shift at 100 a month | 1.67 |
| Incidents per 12-hour shift at 140 a month | 2.33 |
| Pager budget per 12-hour shift | 2 |
| Monthly incidents the budget allows | 120 |
| Cut needed from 140 a month | 14.3% |
| Time on-call, 4 engineers, primary only | 25% |
| Time on-call, 4 engineers, primary and secondary | 50% |
| Time on-call, 8 engineers, primary and secondary | 25% |
Text description of the diagram
- At 100 incidents a month, a 12-hour shift averages 1.67 incidents.
- After a 40% rise it averages 2.33 against a budget of 2.
The eight-engineer figure matches Google's minimum for a single-site team with a primary and a secondary and week-long shifts; a dual-site team needs a minimum of six per site (Google Research, 2015). The SRE book adds that more frequent events may degrade the quality of response and suggest a problem with design, monitoring sensitivity or postmortem follow-through.
What to do with the numbers follows from this. Treat the fix as a funded project, not a request to cope. Getting that project onto the roadmap is a trade-off conversation; see tech debt versus features and when priorities change mid-quarter. Out-of-hours on-call work should also be compensated, says the Workbook.
Trade-offs and edge cases
Incident structure is a trade between overhead and coherence.
- Small incidents. A tiny incident does not need three people. The CL role can fold back into the IC, and one person can carry both for a while.
- The manager is the best debugger. Handing command to someone else feels wasteful, but a commander who debugs stops tracking the whole state. Join as the OL or step back and support.
- Executive pressure. A senior leader on the call can pull the response toward status requests. Agreeing an update rhythm moves those requests to the CL; see delivery under pressure.
- Blameless is not toothless. The review still names causes and assigns dated actions. What it avoids is naming a person as the cause.
- Averages hide bursts. An average under the budget can still contain a week of many pages. Look at the worst shifts, not only the mean.
How to answer it in an interview
A critical system is failing in production. What do you do?
First I make sure there is exactly one incident commander. If I'm the manager on the call, I either take the role explicitly or hand it to the on-call engineer and support them; I don't take command by rank. The commander delegates the technical work and we mitigate first, stopping the impact before we hunt for the root cause; a communications lead posts steady updates, and we keep one shared incident document. Afterward I run a blameless postmortem where every action has an owner and a date. I also check whether on-call load was already too high, because that points to the system, not to a person.
The spoken structure: name the commander, delegate and communicate, review blamelessly, then fix the system behind the pager.
Common mistakes
- "I'm the most senior person, so I run the incident." (wrong) Rank does not set the commander. (right) "I confirm who commands, and I say whether I'm commanding or supporting."
- "I dive into the logs myself." (wrong) The commander is not a resolver. (right) "I delegate the repair and keep the whole picture."
- "Blameless means nobody is accountable." (wrong) Teams are held accountable without blame. (right) "Every action has an owner and a date, and nobody is named as the cause."
- "If the pager is busy, people just need to push through." (wrong) Frequent events degrade response and signal design problems. (right) "I treat a heavy pager as a system problem and fund the fix."
Follow-up questions
What are some examples of how you managed a P0 incident?
A P0 is the highest-priority incident level; pick a real incident of your own and walk it through the four steps: who commanded, how roles were split, how updates ran and what the review changed. A strong answer names what you delegated and one action you completed afterward, rather than describing heroics.
What steps did you take to make sure it was resolved and not repeated?
Say that the postmortem ended with tracked actions, each with an owner and a date, and that approvers prioritized them in their backlogs. Mention that you fixed the class of incident and checked back on the actions until they were done.
How would you approach a situation where a critical system is failing in production?
Confirm one commander, declare the incident, split the roles, set an update rhythm and keep a shared document. Only then discuss causes. The order matters more than the technical details.
What do you do when you get paged that the main site is down on a Saturday?
Acknowledge the page, check whether an incident has been declared and who commands, and join in the seat that helps most, whether that is supporter, stakeholder or commander. Do not start uncoordinated side investigations; if nobody has declared it, declare it and take command until you hand off.
What do you do in your first three months with a team whose incidents are rising?
Measure first: incidents per shift and the share of time spent on-call, against a budget of two per 12-hour shift and a cap of 25% of time. Then fund the reliability work, fix on-call staffing and run blameless reviews. A director-level interview will push on how you win that funding.
Does blameless mean nobody is accountable?
No. Blameless means not blaming people for faults, while teams are still held accountable through owned, dated actions.
- Name one incident commander at declaration; rank does not decide who commands.
- The commander delegates every repair and keeps the overall state and one living document.
- A Communications Lead updates stakeholders on a rhythm so the response is shielded.
- A blameless postmortem ends in owned, dated, tracked actions.
- On-call load is a manager's responsibility: watch the pager budget and time on-call.
Sources
- Managing Incidents (Site Reliability Engineering book, chapter 14) — Google SRE, 26 Oct 2026
- Incident Response (Site Reliability Engineering Workbook, chapter 9) — Google SRE, 26 Oct 2026
- Incident Management Guide — Google SRE, 26 Oct 2026
- On-Call (Site Reliability Engineering Workbook) — Google SRE, 26 Oct 2026
- Service Best Practices (Site Reliability Engineering book) — Google SRE, 26 Oct 2026
- Being On-Call (USENIX ;login:) — Google Research, 1 Oct 2015
- Incident Command roles and Incident Commander training — PagerDuty Incident Response Documentation, 26 Oct 2026
- Different Roles for Incident Response — PagerDuty Incident Response Documentation, 26 Oct 2026
- Incident Management Handbook — Atlassian, 26 Oct 2026
- Postmortems (Atlassian incident management handbook) — Atlassian, 26 Oct 2026
