Mentoring and Growing Engineers
Mentoring gives an engineer room to reason and act with support. Agree who leads, when help or takeover is needed, and how to review the work afterward; choose tasks whose risks leave room for learning.
TL;DR: Let the learner explain the evidence and propose the next step while you provide support. Agree on takeover conditions before high-pressure work, reduce avoidable distractions, and explain any intervention. Use lower-risk tasks for early practice and review what the learner can do more independently afterward.
The arrangement, agreed before it is needed
| Element | What it says |
|---|---|
| Roles | The mentee runs the work and types; the mentor asks questions and handles communication |
| Takeover conditions | Growing impact, an irreversible next step, or the mentee asks. Stated in those words |
| Communication | The mentor posts updates, so the mentee is not context-switching between doing and explaining |
| Afterwards | The mentee writes the record; the mentor reviews before it circulates |
Splitting communication away from the mentee matters more than it sounds. Handling technical work while answering repeated requests for updates can be especially difficult during a first serious incident. Assigning communication to the mentor reduces that distraction.
Choose work with enough room for learning, then agree who leads and when the mentor will intervene.
- Learner explains the evidence
They propose a hypothesis and the next check.
- Mentor asks a useful question
What would you expect if that were true? What would rule it out?
No
- Learner runs the next check
Return to the evidence and revise the hypothesis.
Yes
- Mentor explains and takes over
Name the growing impact, irreversible step or request for help.
- Debrief together
The learner writes the record. Review what they can handle with less support next time.
Questions that do not contain the answer
These questions invite the learner to explain their reasoning before you suggest a next step.
- What does that tell you? Asked after they look at something and before they look at the next thing, which trains reading evidence rather than collecting it.
- What would you expect to see if that were true? Trains making a hypothesis falsifiable, and it is the question that catches a theory nobody tested.
- What is the cheapest thing that would rule that out? Trains ordering the investigation by cost rather than by curiosity, and it shows the two-minute check they were about to skip.
- What is this costing per minute? Trains the judgment about when to stop investigating and start mitigating, and on a GPU fleet it has a real answer in idled capacity.
Leave enough time for the learner to think, but set a limit appropriate to the task’s impact. Ten minutes might be reasonable for one exercise and far too long during a rapidly growing incident.
On-Call Narratives That Land covers how the mentee should later tell the story of the incident they just ran, and reading it together during the debrief gives them a frame for what they did.
Taking over without undoing the lesson
Say it out loud and say why. "I am taking over because the next step drains nodes and we cannot undo that quickly, watch what I check and I will explain after" makes the takeover a demonstration. Taking the keyboard silently teaches that competence looks like being fast and unexplained, which is the opposite of what the team needs, and taking over without a debrief leaves the takeover as the only thing the mentee remembers.
Choosing the situation
Not every incident is a teaching opportunity, and choosing wrong damages both the outcome and the person. For early incident practice, choose a familiar failure with an established runbook and an impact the team can safely manage. A novel, customer-facing, expensive incident should be run by the mentor with their reasoning narrated aloud, which is a different and also valuable form of teaching. Being explicit about that choice is what separates mentoring from delegating under pressure.
What interviewers are listening for
Describe a specific learning goal, the support you provided and what changed in the engineer’s work. Perhaps they handled a later incident with less help, improved a diagnosis or explained the tradeoff behind a review comment. State what you observed rather than attributing all of their progress to your mentoring.
Also explain when you intervened and why. Giving someone independence includes matching the task to their experience and the operational risk.
Key takeaways
- The mentee drives and types; the mentor asks questions and owns communication.
- Agree the takeover conditions in words before the shift: growing impact, an irreversible next step, or the mentee asks.
- Four questions that contain no answers: what does that tell you, what would you expect if true, what is the cheapest way to rule it out, what is this costing per minute.
- Narrate any takeover so it is a demonstration, and debrief with the mentee writing the record.
- Choose the situation deliberately; a novel customer-facing incident is the wrong place for a first drive.