Not managing. Not teaching. Something in between.
People use “mentoring,” “managing,” and “teaching” interchangeably. They are not the same thing, and confusing them causes most mentoring relationships to fail.
Managing is about outcomes. You need this done by Friday. Here are the priorities. Let me know if you are blocked. The relationship is structural — it exists because the org chart says it does. A manager’s job is to make sure work gets done and the person doing it has what they need.
Teaching is about knowledge transfer. Here is how this works. Here is why it works that way. Let me show you. The relationship is transactional — I have information, you need it, we meet until you have it.
Mentoring is about growth. It is less structured than managing and less transactional than teaching. A mentor is not responsible for your output or your curriculum. A mentor is the person who helps you figure out which questions to ask, which paths to consider, and which mistakes are worth making.
The distinction matters because if you approach mentoring like managing, you end up micromanaging someone’s career. If you approach it like teaching, you end up lecturing. Neither helps.
If you strip away the inspirational language, a mentor does a few specific things:
The most valuable thing a mentor has is not technical knowledge — it is context. They have been in the situation you are in now. They know what it looks like from the other side. They know which battles are worth fighting and which are decorative.
“You are stressing about this code review, but the real issue is that you have not aligned with the tech lead on the approach. Fix that first, and the review will be easy.”
That kind of redirect is worth more than any technical tutorial.
A good mentor resists the urge to just tell you the answer. Not because they are withholding — because the answer is not the point. The process of getting to the answer is the point.
“What do you think would happen if you deployed that change to staging first?”
They already know the answer. But if they just say “deploy to staging first,” you learn one step. If they ask the question, you learn to think about deployment risk for every future change.
Growth requires failure. Not catastrophic failure — controlled failure. A mentor creates space where someone can try, mess up, and learn without the consequences being career-ending.
This might mean letting a junior engineer lead a sprint planning session, knowing it will be messy. Or letting someone debug an issue for longer than it would take you to fix it, because the debugging itself is the lesson.
The hardest part of mentoring is watching someone struggle with something you could solve in five minutes — and deciding that their struggle is more valuable than your efficiency.
Not harsh. Not sugar-coated. Honest.
“Your presentation had good content, but you lost the room in the middle. You went too deep on the technical details when the audience needed the business impact. Next time, lead with what it means for them.”
Most people do not get this kind of feedback. They get “great job” or silence. Neither helps them grow. A mentor is often the only person willing to say the specific, uncomfortable, useful thing.
Most mentoring relationships are not formalized. Nobody signed a document. There is no schedule. Someone just started asking you for advice, and you started giving it, and over time it became something both of you relied on.
These informal relationships are often more effective than formal mentoring programs because they are self-selected. The person chose you because something about how you work or think resonates with them. That is a better foundation than an HR matching algorithm.
If you find yourself in an informal mentoring role, the main thing to remember is: you accepted it by engaging. You do not need a title to take it seriously.