Supporting Your Team's New Responders

Bringing new people into on-call can be daunting: for them (obviously), but also for you. Karan Nagarajagowda shares what  works when supporting junior engineers through their first high-severity incidents and why your leadership in those moments matters.

‍

When a junior engineer joins their first high-severity incident, there's a particular kind of nerves that comes with it. They're newer to the system than everyone else in the room. Senior engineers are firing context at each other in shorthand. And they're trying to work out whether they're meant to help, observe or quietly disappear, as the seconds are trickling away.

Your job as a leader or senior engineer is to coordinate, so they can contribute and communicate. You know that you’ll have nailed it if they leave the incident non-traumatically, feeling like they grew their skills & confidence.

‍

1. Assign clear, explicit instructions

Be specific in what you ask your junior or newer engineers to do, e.g. "Can you check the metrics and validate them?" "Can you check the logs and correlate with when the issue started?" "Can you do the timeline check and document it?"

These types of crisp asks turn a nervous junior into a contributing teammate. Vague instructions like "help us debug this" tend to produce paralysis. Explicit, scoped tasks produce results, increasing confidence with every one completed.

This type of communication removes ambiguity, allowing closer alignment of mental models. The result should therefore yield better results. Recall an important David D. Woods & John Allspaw quote:

"Without the cognitive work that people engage in with each other, all software systems eventually fail."

‍

2. Pair with a senior engineer

Wherever you can, pair a junior engineer with a senior one during an incident to build psychological safety quickly. The senior engineer is there to backstop technical decisions and model how to behave under pressure, and the junior engineer gets to ask the questions they might not want to ask in front of the whole room.

It's also how new patterns spread. Watching how a senior engineer reads a metric, frames an update, or decides when to escalate is worth more than any post-incident review.

‍

3. Embrace blamelessness and demand it from the team

This one is non-negotiable. The moment a junior engineer fears embarrassment, they stop contributing. And you lose the very observations that often crack the case open.

Blameless culture isn't a slogan; it's an operating condition for fast incident response. If your new staff are worried about being publicly corrected for guessing wrong, they will stop saying what they actually see, and you'll lose visibility into the problem space right when you need it most.

As the leader in the room, your tone sets this: it's okay for them to be wrong. It's okay for them to say "I don't know." It's okay for them to flag something that turns out to be unrelated. The cost of staying quiet is almost always higher than the cost of imperfect input.

Cat Hicks wrote about this relationship between perceived performance and organisational framing about a month ago:

‘When a developer struggles, the organization frames its question as something like this: is this person missing skills? Or a team misses its targets, so it asks...who do we need to move out? A project fails....well who owns that and didn't work hard enough?

In my experience, the technical teams that move forward rapidly right now aren't asking "do we have the right people?" but rather "have we built conditions where people can show us what they can do? Where people can be their best selves?"

‍

4. Use the runbook as a springboard to encourage problem-solving

A good runbook can for sure be helpful for new on-call staff in an incident. Yet it can be a double-edged sword. It can create brittleness, reduce an incident responder to a mere command executor and take away problem-solving. Or it can give the practitioner access to clues from past incidents. Recall Dwight Eisenhower’s famous quote: "In preparing for battle, I have always found that plans are useless, but planning is indispensable." Overall, the runbook can note how similar incidents were resolved in the past and explain why a certain sequence of steps worked. Therefore, incident leaders can encourage responders to draw inspiration from the runbook while doing their own problem-solving.

‍

5. Practise before it counts

Mock incidents (or incident simulations) are the most reliable way to build incident reflexes without the real-world stakes. I run my drills to intentionally include ambiguity, incomplete information, and communication pressure: exactly the things that make a real incident feel disorienting.

The goal isn't to memorise a runbook. It's to help your team discover what they tend to do under pressure (freeze, over-talk, dive too deep, miss the comms), so they can adjust before it matters. Back in the day, the only way to do this was to go through a lot of painful incidents. Now, you can get the same palm-sweating experience, minus the actual downtime.

‍

Being clear about your role

When a junior engineer or new on-call staff member walks into their first real incident, the culture they find will shape everything that follows. You can give them all the tools in the world: runbooks, a paired senior, an explicit task. But if you enter into that incident room armed with pressure and blame, they'll feel it and shut down.

Your coordination and communication skills in early incidents matter and influence their ongoing success. Let’s end on this, by author Jon Gordon: ‘You are not a true success unless you are helping others be successful’.