Somewhere around my third year leading engineering, I realised I was using two words interchangeably that I had no business confusing. I told a senior backend engineer I was going to "coach" her through a tricky promotion case, and what I actually did was tell her about the time I navigated the same thing six years earlier. That is mentoring, not coaching. She nodded politely, took my war story, and walked away with my answer to her problem rather than her own. It worked out, but it was the wrong tool, and the fact that it worked out anyway is exactly the kind of false signal that lets a leader keep making the same mistake for years.
In a regulated fintech environment, where the cost of a mishandled decision can be a compliance finding or an outage that moves real customer money, the distinction between mentoring and coaching is not academic. The two practices solve different problems, draw on different authority, and produce different kinds of growth. This is my attempt to be precise about what each one is, when I reach for which, and how I have learned to stop blurring them.
Two Different Jobs Wearing Similar Clothes
Mentoring is the transfer of accumulated experience. A mentor has walked a road the mentee has not, and the value lies in shortening the distance: here is what worked, here is the trap I fell into, here is the context you cannot see yet because you have not been in the room. It is inherently asymmetric. The mentor knows something specific the mentee wants, and the relationship exists to move that knowledge across the gap.
Coaching is almost the opposite posture. A coach does not need to have done the thing at all. The coach's job is to help the other person find their own answer by asking the right questions, reflecting back what they hear, and holding space for the person to think more clearly than they would alone. The coach assumes the answer already lives inside the person being coached; the work is to draw it out, not to pour something in.
Both are legitimate. Both build people. But they fail in characteristic ways when you use the wrong one, and most of the awkward, unproductive development conversations I have had as a leader came from grabbing the mentoring tool when the moment called for coaching, or vice versa.
The Direction of the Arrow
The cleanest way I have found to tell them apart in the moment is to ask which direction the information is meant to flow. If I am talking more than I am listening, and the value I am adding is content the other person did not previously have, I am mentoring. If I am listening far more than I am talking, and the value is in the quality of my questions rather than my answers, I am coaching.
This sounds obvious written down, but in practice the lines blur because we default to whatever is comfortable. Most engineers who become leaders got promoted partly because they had good answers, so the reflex under pressure is to give an answer. That reflex is what turns nearly every coaching opportunity into an unsolicited mentoring session. I have had to physically slow myself down in one-to-ones, sometimes by literally counting to three before responding, to keep from filling silence with my own experience when the person in front of me was about to work it out themselves.
The hardest discipline in coaching is resisting the dopamine hit of being the one who knew the answer. Every time I solve it for them, I rob them of the rep they needed to become someone who can solve it without me.
When Mentoring Is the Right Tool
Mentoring earns its keep when there is a genuine knowledge or context gap that the person cannot reasonably close on their own in a useful timeframe. A new engineering manager who has never run a performance improvement plan does not benefit from me asking how they think it should go. They benefit from me telling them what the documentation needs to contain, where managers commonly create legal exposure, and how to keep the conversation humane while being clear. That is experience they do not have and cannot intuit.
The same applies to domain-specific knowledge that is expensive to acquire by trial and error. In payments, there are things about settlement timing, chargeback windows, and regulatory reporting that you simply have to be told. Letting someone discover the correct handling of a reconciliation discrepancy through Socratic questioning would be reckless when a senior person can transfer the right answer in five minutes. Some knowledge is too consequential to be reinvented.
I tend to reach for mentoring in a few recurring situations:
- Onboarding into a domain with hard-won, non-obvious rules, such as our compliance and audit obligations.
- Career navigation where the person genuinely cannot see the political or organisational landscape yet.
- Technical decisions where a known failure mode is about to be repeated and the cost of learning it the hard way is high.
- Moments of genuine crisis, where the person needs direction now and reflection can come later.
When Coaching Is the Right Tool
Coaching becomes the right tool when the person already has the raw capability and the relevant information, but is stuck on judgement, confidence, or clarity. A staff engineer deciding whether to advocate for rewriting a fragile service does not need my opinion on the rewrite. They have more context on that codebase than I do. What they need is someone to help them separate the technical reality from their frustration, to surface the assumptions they are treating as facts, and to think through the consequences they are avoiding.
The signal that coaching is appropriate is when I notice I would be guessing if I gave an answer. If the honest truth is that the person in front of me knows more about their specific situation than I do, then any directive I offer is worth less than a good question. My job shifts from supplying content to improving the conditions under which they think. Questions like "what would have to be true for this to be the right call" or "what are you most worried about that you have not said out loud" do far more than my opinion ever could.
Coaching also compounds in a way mentoring does not. Every time someone reaches their own conclusion through a coaching conversation, they get better at reaching conclusions. They build the internal muscle. Mentoring transfers a fish; coaching, done well over time, builds someone who fishes better than I do and eventually in waters I have never seen.
The Authority Problem in Coaching Your Own Reports
There is a complication that the classical coaching literature tends to gloss over, and it matters enormously for engineering leaders: I am not a neutral coach to the people I manage. I sign their compensation reviews. I influence their promotions. When I ask a direct report what they think they should do, the question is never fully open, because they know I have an opinion and they suspect there is a right answer I am waiting to hear.
This is the central tension of coaching inside a reporting line. Pure coaching assumes a degree of safety and non-judgement that a manager cannot fully provide, because the manager is also the evaluator. I have learned to be honest about this rather than pretend it away. When I genuinely want to coach, I say so explicitly: "I do not have a preferred answer here, I actually want to help you find yours." And when I do have a strong view, I name it as a view rather than dressing it up as an innocent question. Manipulative coaching, where you ask leading questions to walk someone toward the answer you already hold, is worse than just mentoring honestly, because it teaches people that your curiosity is a trap.
For deeper coaching that requires real psychological safety, I am a strong believer in external coaches and cross-functional mentors who sit outside the reporting line. There are conversations a person simply cannot have safely with the individual who controls their next pay rise, and recognising that limit is itself part of doing the job well.
Reading the Situation Before You Open Your Mouth
The practical skill is diagnosis: figuring out, in the first minute of a conversation, which mode the moment actually calls for. I have a short internal checklist I run almost unconsciously now. Does this person lack information, or lack clarity? Is the stake high enough that a wrong answer is dangerous, or is the learning worth more than the efficiency? Have they asked me to tell them, or have they asked me to help them think?
That last one is underrated. People often signal what they want if you listen for it. "What would you do?" is frequently a request for mentoring. "I am trying to figure out how to think about this" is almost always an invitation to coach. The mistake is to override their request with my preference. Sometimes I will even ask directly: "Do you want my take, or do you want me to help you work through it?" Naming the choice respects their autonomy and stops me from defaulting into lecture mode.
The diagnosis also changes over the life of a relationship. Early on, a new hire needs a great deal of mentoring because the context gaps are real and wide. As they grow, the ratio should shift steadily toward coaching, until ideally I am mostly asking questions and they are mostly making excellent decisions. If I am still mentoring someone heavily after two years, either they have not grown or, far more likely, I have failed to let them.
The Cost of Getting It Wrong
Using the wrong tool is not neutral; it has a real cost, and the costs run in both directions. Over-mentoring creates dependency. If I always have the answer, people stop developing the capacity to generate their own, and I become a bottleneck. The team's ceiling becomes my ceiling. I have watched talented engineers stay junior in their judgement far longer than they should have because a well-meaning senior person kept solving things for them.
Over-coaching is the subtler failure, and arguably the more fashionable one now that coaching is in vogue. Asking probing questions of someone who genuinely lacks the information they need is not empowering; it is abandonment dressed as enlightenment. If a junior engineer is staring at an incident they have no framework to understand, responding with "well, what do you think is happening?" is unkind. They need teaching. Withholding knowledge that someone needs, in the name of letting them grow, is a way of avoiding the harder work of actually mentoring them well.
The skill, then, is not preferring one over the other. It is matching the intervention to the person and the moment, and being willing to switch modes inside a single conversation when you notice you have misdiagnosed.
Building Both Into the Team Culture
Beyond my own conversations, I try to build both practices into how the engineering organisation operates, because neither should depend solely on me. For mentoring, that means deliberate pairing, documented context, brown-bag sessions where senior people transfer the non-obvious, and a culture where asking a more experienced colleague is treated as competence rather than weakness. The goal is to make experience flow without it having to route through my calendar.
For coaching, it means training managers in the basic mechanics of asking before telling, normalising the question "what do you think" as a genuine inquiry rather than a quiz, and investing in external coaching for senior leaders where the reporting-line problem bites hardest. It also means modelling, out loud, that I do not have every answer, so that asking good questions is seen as leadership rather than indecision. When a team sees their leader comfortable saying "I am not sure, let us think it through," coaching becomes a shared norm rather than a manager's trick.
The healthiest engineering cultures I have been part of had both running at once: a rich substrate of experience moving freely between people, and a strong habit of helping each other think rather than reflexively rescuing each other. The two reinforce one another. People who have been mentored well have more raw material to draw on when they are being coached, and people who have been coached well know which questions to ask the next time they go looking for a mentor.
Conclusion
Mentoring and coaching are not the same thing, and the difference is not pedantic. One transfers what you know; the other develops what they can do. One is the right answer when a context gap is real and the cost of discovery is high; the other is the right answer when the person is capable and the learning is the point. The leaders I most admire move fluidly between the two, diagnosing which the moment needs and switching without ego when they get it wrong. I am still learning to do it well, but naming the distinction was the first step, and on the day I stopped calling my war stories coaching, I started getting better at both.