The best engineering mentor I ever had almost never told me what to do. She asked questions — relentlessly good questions that made me realize I already knew the answer, or that I had not thought hard enough about the problem. It took me years to appreciate how much skill that required and how much restraint it demanded.
Now, as someone who spends a meaningful chunk of time mentoring, I try to channel that approach. It is harder than it sounds. When you can see the answer clearly and the person across from you is struggling, the temptation to just tell them is almost irresistible. But every time you give someone the answer, you rob them of the learning that comes from finding it themselves.
“The secret of managing is that almost everything you do comes down to building and maintaining a strong team.” — Camille Fournier, The Manager’s Path
Mentoring vs Managing vs Teaching
These get conflated constantly, and the conflation leads to bad mentoring.
| Mentoring | Managing | Teaching |
|---|
| Goal | Accelerate growth | Deliver outcomes | Transfer knowledge |
| Power dynamic | Peer-ish, voluntary | Hierarchical, formal | Expert-to-novice |
| Primary tool | Questions | Direction | Explanation |
| Time horizon | Long-term career | Quarter or sprint | Session or topic |
| Success metric | Mentee outgrows you | Team hits targets | Student understands concept |
| Failure mode | Creating dependency | Micromanaging | Information dump without retention |
The best signal that you are mentoring well: the person starts bringing you harder problems. Not because they cannot solve them, but because they want a thought partner. If they stop bringing you problems entirely, you either succeeded completely or they do not trust you enough. Figure out which one.
The Coaching Stance: Ask, Don’t Tell
The single most impactful shift in my mentoring was learning to default to questions. Not leading questions that steer toward my preferred answer — genuine questions that help the other person think through the problem.
| Instead of Telling… | Try Asking… |
|---|
| ”You should use a queue here." | "What happens if this service goes down while a request is in flight?" |
| "This API design won’t scale." | "How would this behave with 100x the current traffic? Walk me through the request path." |
| "You need to break this into smaller PRs." | "If you were reviewing this PR, where would you start? How long would it take?" |
| "Use a caching layer for this." | "Where are the repeated calls happening, and what would change if we could avoid them?” |
Creating Stretch Assignments
Growth happens at the edge of comfort. Not in the panic zone, not in the cruise zone — right at the boundary where something is challenging but achievable with effort.
| Step | What to Do | Why It Matters |
|---|
| Identify the growth edge | What skill does this person need to develop next? | Targets the assignment to real development needs |
| Find a real problem | Stretch assignments must be real work, not busywork | Demonstrates trust and gives meaningful stakes |
| Calibrate the challenge | Too easy is not growth; too hard is frustration | The sweet spot builds confidence alongside capability |
| Provide safety nets | Make failure safe; be available if they get stuck | Psychological safety is the foundation of risk-taking |
| Debrief afterward | Reflection is where the learning actually crystallizes | Without the debrief, 80% of the lesson is lost |
The best stretch assignments are ones where the cost of failure is low but the learning value is high. Design doc reviews, internal tech talks, leading a spike, owning a small migration — these are all great growth vehicles that will not cause a production incident if things go sideways.
| Feedback Element | Example |
|---|
| Specific behavior | ”When you merged that PR without addressing the API versioning comment…” |
| Specific impact | ”…it meant the mobile team had to do a breaking change migration.” |
| Open question | ”What was your thinking there?” |
Feedback in public is almost always a mistake, even when it is positive. Public praise can embarrass introverts and create awkward dynamics. Public criticism is obviously destructive. Default to private, always.
| Situation | Approach | Example |
|---|
| Mentee is stuck on a technical problem | Ask diagnostic questions — do not debug for them | ”What have you tried? What did you expect vs what happened?” |
| Mentee is avoiding a hard conversation | Role-play the conversation, help them prepare | ”Let’s practice — I’ll play the tech lead, pitch me your approach.” |
| Mentee underestimates their work | Help them articulate impact in concrete terms | ”Let’s write down what changed because of what you built.” |
| Mentee is frustrated with lack of promotion | Clarify expectations, identify gaps honestly | ”Let’s map your work against the staff rubric together.” |
| Mentee is overcommitted | Help them prioritize and practice saying no | ”If you could only do two of these five things, which two?” |
| Mentee disagrees with a team decision | Validate the disagreement, explore the context | ”You might be right. What do you think the decision-maker was optimizing for?” |
Delegate the Problem, Not the Solution
This is the principle I come back to most often. When a mid-level engineer asks me how to solve something, my instinct is to hand them a solution. But the far better approach is to hand them the problem and let them find the solution.
“We need to reduce the p99 latency of the search endpoint from 800ms to under 200ms” is a problem. “Add a Redis cache with a 5-minute TTL” is a solution. The first framing gives the engineer space to investigate, learn, and potentially find a better approach than the one you had in mind. A team I worked with proved this when I delegated a build-time problem expecting a caching solution — the engineer discovered the real bottleneck was a misconfigured test parallelization setup. Her solution was simpler, cheaper, and better than mine would have been.
When to Push vs When to Support
Knowing when to push and when to support is the hardest judgment call in mentoring. Push too hard and you break trust. Support too much and you enable stagnation.
A useful heuristic: push when someone is avoiding growth out of fear, support when someone is processing a genuine setback. Fear sounds like “I don’t think I’m ready.” That is a push moment. Setback sounds like “I tried and it didn’t work.” That is a support moment.
At the end of the day, mentoring is an act of optimism. You are investing time and energy in someone’s future capability. The returns are uncertain and delayed. But every senior engineer who grows makes the teams around them better, those teams build better systems, and those systems serve users better. That is the compounding return of good mentoring — it does not stop with the person you are mentoring.