Mentoring through operational work: build independent diagnosis safely
Build an operational mentoring plan using incident rehearsal, bounded authority and observable diagnosis skills. Explain your contribution without inventing outcomes or claiming another engineer’s work.
TL;DR: Give the learner progressively harder decisions with explicit safety limits, then evaluate whether they can explain and verify the result without your prompts. Measure independent judgment and escalation, not how many commands they watched you type.
Separate learning responsibility from production authority
A new teammate can own the investigation narrative while an experienced responder retains authority for a risky production change. Those roles are compatible. State who can approve changes, when the mentor will intervene and which conditions require immediate escalation before the exercise begins.
Google's SRE onboarding discussion uses structured learning and operational preparation rather than assuming someone becomes ready after a fixed number of shadow shifts. The principle is transferable: identify what the person must be able to reason about, and give them evidence-producing work at the appropriate scope.
Start by asking the learner to explain the service path and select a read-only observation. If they cannot distinguish a frontend timeout from a backend rejection, another dashboard tour is unlikely to solve the gap. Use a recent incident with sanitized evidence and ask what they expect to see under two competing hypotheses.
Build a rehearsal around an actual decision
Use this fictional exercise: a service's error rate rises after a configuration rollout. Latency increases only for one endpoint, and database health remains normal. The learner receives request outcomes, deployment timestamps and a redacted configuration diff. They must identify the affected request path and recommend whether to revert the configuration.
Do not hide essential context merely to make the exercise difficult. Instead, reveal evidence when the learner asks a specific question. If they request “all logs,” ask which event would distinguish their hypotheses. If they propose rollback, ask what makes the previous configuration compatible and which signal would demonstrate recovery.
| Observable behavior | Evidence of progress | Coaching response when absent |
|---|---|---|
| Defines affected scope | Names endpoint, users and start time | Ask what remains healthy |
| Chooses a discriminating check | Predicts outcomes for two causes | Compare hypotheses before commands |
| Bounds a change | Names approval, rollback and stop condition | Rehearse in a disposable environment |
| Verifies recovery | Rechecks customer outcome and side effects | Separate process survival from service health |
| Escalates appropriately | Explains uncertainty and required help | Clarify the escalation threshold |
The table is an assessment aid for this exercise, not a universal certification rubric. Adapt the evidence to the service and role.
Gradually remove prompts
A useful progression is for the mentor to demonstrate reasoning once, then let the learner lead a replay, and finally observe a different case. Repeating the exact same commands proves recall more readily than transfer. Keep the production authority boundary visible even when the learner is leading the conversation.
The SRE workbook's on-call chapter describes training roadmaps and incident role-play. Such rehearsal creates room to make and correct mistakes without manufacturing a customer outage. Live incidents still require the incident commander's judgment; teaching must not delay a needed mitigation.
For the fictional endpoint case, suppose the learner needs four prompts on the first replay and one on a second, related exercise. That is useful coaching evidence, but the different cases make it a weak quantitative comparison. Record the actual improvement: they independently correlated the configuration change and requested a compatibility check before rollback. Avoid converting two observations into a sweeping productivity percentage.
Make the work reusable without taking it over
Ask the learner to update the runbook with the diagnostic branch they found missing. Review whether someone else can follow it and whether it explains expected outputs, not only commands. Keep their authorship visible. The mentor's contribution is the learning structure, feedback and safe review, while the learner owns the investigation and improvement they performed.
If the learner repeatedly reaches for a restart, investigate the cause of that habit. They may lack access to metrics, have a runbook that only offers restart, or be responding to pressure to close tickets quickly. Coaching alone cannot repair an environment that rewards hiding uncertainty. Improve access and incentives alongside the exercise.
An interview answer should describe the starting gap, one concrete intervention and observable evidence of greater independence. Use a real example from your experience. If you did not measure reduced on-call load or incident duration, say what you actually observed rather than inventing an efficiency claim. Project narratives explains how to separate contribution from outcome.
Self-check: a teammate can reproduce your fix perfectly but chooses it during an unrelated failure without checking scope. Are they ready for wider unattended authority? Not on that evidence. Rehearse a case where the familiar fix is inappropriate and ask them to state a stop condition. Readiness includes recognizing when the known procedure does not apply and seeking help before increasing impact.
Runbook validation turns the missing procedure into explicit applicability checks, stop conditions and a rehearsal another responder can repeat.