Mentor a developer without taking over the work
Give enough explanation and support for a learner to act, then check their understanding on another task. Distinguish teaching from urgent delivery.
Agree on the skill being practised, explain the missing reasoning, and let the learner make the next appropriate attempt. Review the result and gradually reduce support. Do not confuse leaving someone stuck with teaching, or completing the task yourself with developing their capability.
When someone is stuck on a test, show how you connect the failure to one assumption, then let them investigate the next case. Taking the keyboard until everything passes may finish the ticket without showing them how to begin next time.
You can be helpful in the moment and still leave a colleague dependent on you. You solve the problem quickly, explain the final answer, and return to your own work. The ticket moves, but the learner may still not know how you selected the first useful step.
Agree whether this is learning, delivery, or both
Ask what the learner is trying to do and where they are stuck. Are they missing a concept, a local convention, access, or a product decision? Not every request is an opportunity for a lesson. Sometimes the correct response is to supply the missing information or find the decision-maker.
Also establish urgency. During a serious incident, restoring safe operation may take precedence over teaching each step. You can explain afterwards. Do not turn an urgent situation into a guessing exercise to prove that the learner can cope.
For a normal learning task, agree the capability being practised and the time available. “Learn this codebase” is too broad. “Trace this error from the failing test to the relevant assumption” gives the session a concrete purpose. Mentoring needs capacity just as implementation does.
Try the decision
A mentee has a plausible approach that differs from yours. What supports learning?
The task may finish, but the mentee cannot practise the decision.
Next step: Explain the constraint you are worried about.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Make the missing reasoning visible
In an illustrative example, a developer cannot explain why a test behaves differently with an empty collection. The mentor first asks what the learner expected and what the test actually reports. This reveals that the learner understands the syntax but is unsure which branch handles the empty case.
The mentor can show one investigation step and explain its purpose: “I am checking this condition because it determines whether the later operation runs. If the empty case takes this branch, the next question changes.” The value is the connection between a hypothesis and a check, not the speed of navigating the editor.
Scott H. Young’s Get Better at Anything prompted the combination of an example, an attempt, and feedback. His public book description sets out those ingredients. Our mentoring sequence is an application, not evidence that one teaching style works for every learner.
Explain directly when the learner lacks the concept needed to answer. Repeatedly asking “What do you think?” is not helpful when they have no basis for a useful guess. A question should reveal understanding or guide attention, not conceal an answer as a test of endurance.
Leave the learner a real next step
After showing the first step, ask the learner to choose the next check and explain what each possible result would mean. Let them make a safe attempt. Keep enough support available that a small uncertainty does not become an afternoon of random changes.
Agree a point for returning to the discussion. It might be after they have tested a hypothesis or when they reach a particular uncertainty. The boundary should fit the task and risk; a rigid rule about struggling alone for a fixed period misses those differences.
Ask the learner to summarise the current understanding in their own words. If their explanation differs from yours, locate the missing step rather than immediately taking over. The purpose is to discover what support is still needed.
A useful help request gives the learner a way to return with a focused question. Bounded independence describes the destination without pretending that asking for review invalidates progress.
Review without turning preferences into orders
When the learner returns, distinguish correctness, missing evidence, and personal preference. Fix or explain a real problem. Do not automatically replace every reasonable choice with the version you would have written. That makes the work yours and obscures what the learner can already decide.
Marshall Goldsmith’s article on adding too much value warns that suggestions from an authority figure can carry the force of instructions. In mentoring, make optional alternatives visibly optional and explain the reason when a change is required.
Use the code-review distinction between a necessary correction and a preference. A beginner still deserves a clear reason for a required change. They also need enough honest feedback to avoid mistaking politeness for correctness.
Keep the relationship respectful. Do not use public embarrassment as motivation or treat a repeated question as proof of laziness. Check whether the earlier explanation, documentation, or task boundary was sufficient before reaching for a personality judgement.
Check whether the skill transfers to another task
A completed ticket shows that the task is complete. To learn whether the mentoring helped, look for the capability on another suitable task. Can the developer identify the relevant assumption, choose a useful check, and recognise when they need help?
Reduce support as the evidence permits. That might mean moving from a demonstration to a short review, then to availability only at an agreed escalation point. Do not remove support simply because a calendar says the learner should be independent by now.
Mentors also need boundaries. If the support demand is larger than the time available, discuss workload and additional help with the manager. One experienced colleague should not silently become the entire onboarding system.
The useful outcome is not that the learner always chooses your solution. It is that they can make and explain a reasonable choice within the task’s constraints. That is a capability you helped develop, not work you completed on their behalf.