Who's in Charge?

Who’s Actually Flying the Plane?

A conversational take on ownership during an incident

I was chatting with a few customers last week, and the same theme kept popping up again and again:
“During an incident, who’s actually in charge?”

You’d think this would be obvious. But when an incident kicks off - think: alarms firing, people piling into the bridge, Slack channels getting noisy - clarity on ownership is usually the first thing to disappear.

And that lack of clarity?
It creates chaos faster than the actual technical issue.

When the Call Starts: Someone Needs to Be the Pilot

Picture this. The incident has just started. People are joining the call from everywhere. Engineers. Managers. Maybe someone from Product. Someone’s dog is barking in the background. You know the scene.

At that moment, you need one thing above all else:
A clearly identified pilot.

Not the smartest person on the call.
Not the most senior.
Not the person with all the answers.

The pilot - the incident commander - is simply the person with the responsibility and authority to drive the incident to resolution.

Think of it as being the CEO of that incident.
For the next 15 minutes, 30 mins, 1-2 hours… that’s you.

It’s Not Command-and-Control — It’s Clarity

Now, being the ‘CEO of the incident’ doesn’t mean you bark orders or pretend you know everything. Far from it.

Most of the time, your job is to coordinate:

• Ask the right probing questions.
• Pull out working theories from your responders.
• Keep multiple investigation threads moving.
• Continuously check customer impact.

It’s not your job to DO all these things; it’s your job to ensure that these things are happening

You’re not there to be the smartest person.
You’re there to be the clearest person.

The IC’s role isn’t to parse all the data and make all the decisions. Rather, it's to ensure the team is gathering the data (noticing the signals) and making progress on creating hypotheses, making interventions, and checking the effect of those interventions.

When the Execs Join… and the Backseat Driving Begins

Here’s where things get interesting.

At some point, someone very senior — maybe your VP, maybe the CTO, sometimes even the founder — joins the call. They mean well. They’re worried. They want to help.

But suddenly their presence changes the room.

People stop talking.
They start waiting for the exec to give direction.
Or worse, the exec starts giving direction.

And now we’ve got a problem:
Your leadership is being unintentionally overwritten.

This is the classic executive swoop.

And if you’re the incident commander, you now have a choice:

• Let the exec take over (which is perfectly fine if that’s what they want).
• Or reaffirm, politely but firmly, that you are in command.

The key is over-communicating your role:

• Put 'Incident Commander' in your title.
• Say it out loud when new people join.
• Post it in the incident channel.
• Repeat it when someone starts backseat-driving.

It’s not about ego.

It’s about clarity.

If Someone Else Wants to Command — Let Them Take the Badge

There is nothing worse than a “shadow commander” running the call from the sidelines while you’re supposed to be the pilot.

If a senior leader genuinely wants to take over, great — hand them the controls.

But it has to be explicit:
One pilot. Not two. Not zero.

If they’re joining as a stakeholder?
You manage the comms and keep them updated.

If they’re joining as a first responder?
They take technical direction from you (like everyone else).

If they’re joining as a commander?
You hand over the baton.

Long Incidents = Fatigue = Handovers

For long-running SEV1s, no one should be expected to stay a pilot forever.

Handovers are healthy.
Handovers are professional.
Handovers prevent mistakes.

But again:
They must be explicit.
The team should always be able to answer the question “Who’s flying the plane?” within one second.

The Uptime Philosophy: During a SEV1, You’re the CEO

At Uptime Labs, we have a simple saying:
During a SEV1, you are the CEO of the company.

That doesn’t mean you outrank actual executives.
It means you own the coordination of the incident.

Your job is to make sure these things are done:

• Drive the investigation.
• Coordinate the responders.
• Set priorities.
• Manage communication to the business.

And the organisation needs to trust and support - whoever is in that seat.

The key is that the IC needs to adapt to the needs of the incident and leverage the team that you have at your disposal. Incident response is a team sport after all.

Everyone Means Well — But Clarity Wins

Most of the stories I heard last week weren’t about technical failure. They were about leadership ambiguity.

As I mentioned previously, incident response is a team sport. Clear, unambiguous leadership helps the IC ensure the incident is progressing; they also need to adaptively ensure that other responders have the right levels of autonomy for any given context. Yes, the IC is flying the plane, but they’re just part of a team, without which the plane will fall out of the sky.

You need clarity of leadership, but don't lose the vital sense that it's a team sport!

If you’re playing the role as IC in a SEV1 incident, that’s the expectation:
You are in charge.

And your number-one skill isn’t knowledge.
It’s the ability to say, calmly and confidently:

I’m the incident commander. I’ll be running this incident.

After all, when the SEV1 is running, the IC is the CEO of the incident!

Practising this clarity on the job is challenging; it's made easier by practising in tabletop exercises or drills. You can run these at a regular cadence within your org, or we recommend practising this in our simulated environment at Uptime Labs. Try a drill today, and let us know what you think!