Think about two managers you've had — one who made you better, and one who didn't. The one who didn't probably kept you busy: tickets assigned, reviews signed off, standups attended. The one who did make you better probably did something subtler. They gave you a problem that was slightly too big, stayed close enough to catch you if you fell, and then watched while you figured it out. That's the whole craft of mentoring, right there.
I've led engineering teams ranging from eight to eleven people across startups and scale-ups, and the difference between teams that grew quickly and teams that plateaued almost always came down to one thing: whether the senior people were investing in the junior ones. Not babysitting them. Not doing their work. Investing — with time, with trust, with carefully designed difficulty.
This piece is everything I wish someone had told me before my first attempt at mentoring an engineer. It's also, honestly, a record of the mistakes I made and had to unlearn. If you're a senior engineer who's been handed someone to mentor, or a tech lead building out a team, I hope it saves you some of those lessons.
Why mentoring is leverage
There's a temptation — especially if you came up as an individual contributor — to think of mentoring as a cost. Time you spend explaining a concept is time you're not writing code. But this framing has the maths exactly backwards.
If you have eight engineers on your team, your output as a team is eight people's worth of work. The moment you help someone who was operating at 60% capacity get to 80%, you've added 20% of a person to your team's output — without hiring, without onboarding overhead, without the three months it takes a new hire to become effective. Multiply that across a team and across a year, and mentoring is among the highest-leverage investments you can make.
There's a ceiling-raising effect too. The best teams I've been part of weren't the ones with the most star players — they were the ones where the floor was highest. When every engineer on the team can be trusted to handle a hard problem independently, you can move much faster than a team that funnels everything through one or two senior people. Mentoring raises that floor.
And there's the retention angle, which matters more than people admit. Engineers don't quit jobs — they quit stagnation. The number one reason I've heard from engineers leaving teams is some version of “I stopped growing.” A culture where senior people invest in junior ones is a culture where people stay, and where your institutional knowledge doesn't walk out the door every eighteen months.
Meet people where they are
The single biggest mentoring mistake I see — and made myself early on — is pitching the challenge at the wrong level. Give someone a task they can do in their sleep and they're bored. Give them something genuinely beyond their reach and they flounder. The magic happens in a band between the two.
Developmental psychologist Lev Vygotsky called this the zone of proximal development. The idea is simple: there are things you can do independently, things you can't do even with help, and — between those — things you almost can do, that you'd be able to do with the right support. That middle zone is where learning actually happens. It's where stretch without panic lives.
In practice, this means finding the task that is one step past what they've done before, not ten steps. A junior who has handled simple API endpoints is ready to own a moderate-complexity feature, not a full system redesign. A mid-level engineer who's delivered several features solo is ready to lead one that involves coordination across teams, not to become the tech lead overnight.
How do you know where someone's zone is? You ask, and you watch. Ask them which parts of a task feel clear and which feel murky. Watch where they slow down in a pairing session. Notice what kind of questions they ask (big architectural ones usually signal they're near the edge; small syntax ones usually don't). You'll calibrate quickly if you're paying attention.
Concrete teaching tools
There are a handful of techniques I come back to over and over. None of them are exotic.
Pair programming, done right
Pairing is the fastest way to transfer tacit knowledge — the kind that doesn't live in docs, the instincts about where a problem usually hides or why that pattern causes pain later. But pairing only teaches when the junior is driving, not the senior. If you sit down and start typing while they watch, you've demonstrated competence. You have not helped them build any.
The version of pairing that actually works: put the keyboard in front of them, sit beside them, and narrate what you're noticing. "I'd look at the edge cases here first — what happens if this list is empty?" Wait. Let them think. Let them be wrong. The discomfort of not jumping in is the cost of admission for actually teaching something.
Code review as a teaching channel
Most code review is focused on the code. Good mentoring turns it into a conversation about thinking. Instead of just flagging that a function is too long, explain why — what becomes hard to understand, what breaks first as the codebase grows. I wrote more about the mechanics of doing this kindly and effectively in How to Review Code Kindly, but the mentoring angle is worth adding here: reviews are one of the few places where you can catch someone's reasoning and redirect it before it becomes habit.
One thing I learned to do: ask questions in reviews instead of issuing corrections. "What would happen if two requests hit this simultaneously?" is more useful than "this isn't thread-safe." It invites them to think through the problem; it doesn't just hand them the answer.
Explain your reasoning out loud
Senior engineers have huge amounts of compressed, invisible knowledge — they've just forgotten they have it. When you're making a decision, narrate it. "I'm going with a simple in-memory map here rather than reaching for Redis, because at this scale the extra complexity isn't worth it yet." That sentence, which takes three seconds to say, can take a junior engineer months of trial and error to learn on their own.
You don't need to narrate everything. But making your reasoning visible — especially at decision points where the answer isn't obvious — is one of the highest-yield things you can do for someone learning the craft.
Stretch tasks with a safety net
The most effective teaching move I know is assigning something slightly too big, then staying close. Not hovering — they need the space to struggle — but available. Check in at natural milestones. Let them come to you with blockers rather than anticipating every one. The goal is that they feel independent even though the safety net is there.
One important guardrail: stretch tasks need a real deadline with real stakes, but not stakes so high that failure is catastrophic. The junior engineer who burns out an entire on-call weekend on a task they weren't ready for will be more risk-averse, not more capable. Match the size of the stretch to how much the system can tolerate going wrong.
Don't solve it for them
This is the hardest one. When someone is stuck and you know the answer, it takes genuine discipline not to give it. But the moment you do, you've switched from teaching to doing. The next time they hit a similar problem, they'll come back to you rather than work through it themselves.
What works instead: ask the right guiding question. "What does the error message actually say?" "Have you looked at how we handled the similar case in the payments module?" The goal is to give them the next step in their own thinking, not the answer.
When someone brings you a problem, wait thirty seconds before saying anything. Often they'll answer their own question in that time. If they don't, your first response should be a question, not a solution.
The autonomy ladder
One of the clearest mental models I've found for mentoring is thinking about autonomy as a ladder. Where you are on the ladder determines how much context you need to give, how closely you check in, and what kinds of tasks you assign. The goal of mentoring is always to move someone one rung up — not to pull them to the top overnight, but to keep them moving.
| Rung | How they operate | What your involvement looks like |
|---|---|---|
| 1 — Directed | Needs step-by-step instructions; uncertain about most decisions. Asks before acting on almost everything. | You define the task in detail, review every PR closely, check in daily, and narrate your reasoning constantly. |
| 2 — Guided | Can handle familiar work independently; needs input on new situations. Brings blockers to you rather than guessing. | You set clear goals, define the scope, and review key decisions. You check in every few days, not daily. |
| 3 — Collaborative | Proposes their own approach, thinks through trade-offs, and flags risks proactively. Brings you options, not just problems. | You act more as a sounding board than a guide. You review the approach before execution but trust the execution. |
| 4 — Delegated | Takes full ownership of a problem: scoping, execution, stakeholder communication. Escalates only when genuinely needed. | You check in at milestones. You're available when they want a second opinion, but they drive entirely. |
| 5 — Trusted | You'd hand them any problem on the team, including the ones you're not sure how to solve yourself. | Peer relationship. You learn from each other. Your role is to give them scope and get out of the way. |
Most new graduates start at rung one. Most engineers hired with two or three years of experience land at rung two. The journey from there depends heavily on how deliberately their manager and team invest in moving them up.
The most common mistake I see is treating someone as though they're on a lower rung than they've earned. If someone is functioning at rung three but you're still managing them at rung one — reviewing every PR in detail, checking in daily — you're slowing them down, not helping them. Trust is something you extend progressively; it's not a reward you hand out when someone has definitively "proven themselves."
Trust is extended in advance of certainty — that's what makes it trust. If you wait until someone has a perfect track record before trusting them with something hard, you've denied them the conditions needed to build that track record in the first place.
Growing seniors, not just closing tickets
A lot of mentoring attention goes to juniors — and rightly so, because the delta from junior to mid-level is steep and the need for support is obvious. But mid-level engineers who plateau into ticket-closers and never make it to senior are one of the most common and most preventable losses on an engineering team.
The gap between mid-level and senior is less about technical skill than most people think. Technically strong mid-level engineers stall out because they haven't had the opportunity to own something large enough to develop the judgement that comes with scope.
Growing a senior means giving them:
- Scope, not just tasks. A mid-level engineer given a sequence of tickets will complete those tickets and nothing else. Give them a problem — an area of the system to own, a capability to build — and they have to develop the judgement to break it down, sequence it, and make trade-offs. That judgement is what defines senior.
- Visible ownership. Put them in the room where decisions about their area are made. Let them present their approach to stakeholders. Let them defend it when it's challenged. This is uncomfortable at first and invaluable over time.
- Mentoring responsibility. Pairing a mid-level engineer with a junior to mentor is one of the best accelerants I know for their growth. Teaching requires understanding at a different level than doing. It also forces them to articulate judgements they've been making intuitively, which is exactly the step from mid-level to senior.
- Technical influence beyond their immediate work. Getting them to drive a standards decision, write an ADR, or lead a technical postmortem — all of these build the breadth of influence that a senior engineer needs to have.
Mentoring mistakes worth naming
I've made most of these. The ones I haven't made personally, I've watched other good engineers make without realising it.
- Rescuing too early. Jumping in the moment someone struggles feels helpful. It isn't. Productive struggle is where the growth lives. Rescue is for when someone has been stuck for too long with no path forward — not for the first sign of difficulty.
- Vague feedback. "This could be cleaner" tells someone nothing. "This function is doing three things — naming it after any one of them would be misleading, and it'll be hard to test" is feedback they can act on. Specificity is kindness.
- Delegating only the boring work. If the tasks you hand to junior engineers are always the lowest-stakes, lowest-visibility, most mechanical work, you are keeping the interesting learning for yourself and giving them a career of drudgery. They notice. They leave. The stretch tasks have to include the good stuff too.
- Not actually investing time. "I'm available for questions" is not mentoring. Mentoring requires scheduled, protected time — a regular one-on-one with a mentoring agenda, not just status updates; intentional code review; deliberate pairing sessions. If you're doing it right, it costs two to three hours a week. If it's costing you nothing, you probably aren't doing it.
- Making it about you. The goal is their growth, not your satisfaction at having a thoughtful mentee. Sometimes the right move for them involves opportunities on another team, or feedback that your codebase has problems that are making their learning harder. Good mentors put the mentee first.
How mentoring works at different scales
The core principles don't change with company size, but the infrastructure around them does enormously.
| Company stage | How mentoring typically works | Watch out for |
|---|---|---|
| Startup (<30 eng) | Informal and relationship-driven. Mentoring happens in the flow of work — pairing, review, and daily proximity. No formal program, but often very intense because the work itself is a stretch task. | Senior engineers too buried in output to invest in others. Mentoring gets crowded out by urgency. |
| Scale-up (30–150 eng) | The company is large enough to have career ladders but often hasn't built formal mentoring infrastructure yet. Mentoring quality varies wildly by team. Some seniors are excellent; others have never thought about it. | Inconsistent outcomes. A junior on one team grows fast; a junior on another team stalls for two years. Equity becomes a real issue. |
| Enterprise (150+ eng) | Formal programs: mentorship pairings, structured career frameworks, learning budgets, dedicated time allocations. More process, which is sometimes helpful and sometimes paperwork that crowds out the actual relationship. | Process substituting for genuine investment. A mentorship pairing on paper that amounts to a monthly coffee and no real challenge. |
At one startup I was part of, there was no formal mentoring program, but the three seniors on the team had an unspoken agreement: every junior engineer would be the primary owner of at least one significant feature within their first six months. The features were scoped to be achievable with support, not trivial. The seniors would pair on the tricky parts and review everything closely, but the junior drove. By the end of a year, those junior engineers were mid-levels in everything but title.
At a larger company I joined later, there was a very sophisticated mentoring program — official pairings, quarterly check-ins, a shared document template for goals. And it mostly didn't work, because the document template became the mentoring. Nobody was tracking whether the junior engineers were actually getting better work or just better paperwork. The lesson I took from it: the relationship and the deliberate challenge are what matters. Everything else is scaffolding.
Key takeaways
- Mentoring is leverage. Growing one engineer's capability has compounding returns on team output and retention — far more than the hours it costs.
- The stretch zone is where learning lives. The task should be one step past their current ability, not ten. Too easy breeds boredom; too hard breeds paralysis.
- Teaching tools that work: junior-drives pairing, questions-not-corrections in code review, narrating your reasoning aloud, stretch tasks with safety nets, and resisting the urge to solve it for them.
- The autonomy ladder gives you a shared language for where someone is and where they're going. Extend trust one rung ahead of where you're certain.
- Mid-to-senior growth happens through scope, ownership, mentoring others, and technical influence — not just more difficult tickets.
- Common traps: rescuing too early, vague feedback, delegating only the boring work, and not investing real time.
- The relationship is the program. Formal structures help at scale, but they're scaffolding. The actual work is the deliberate challenge, the honest feedback, and the trust extended in advance of certainty.
This is the second piece in a small series on engineering culture. If you haven't already, part one on reviewing code kindly covers the mechanics of giving feedback in a way that teaches without demoralising — which is the same skill, applied at the PR level. More writing on culture, hiring, and how teams actually work is on the way.