I spent my first few years as a team lead doing everything wrong when it came to mentoring. I thought my job was to protect junior developers from the hard parts. So I'd hand them neatly scoped tasks, write detailed specs, and then review their code so heavily that I might as well have written it myself. Looking back, I wasn't mentoring anyone. I was creating a team of people who were afraid to make decisions without asking me first.
The moment that changed things was a junior named Sarah. She was smart, enthusiastic, but after six months she still needed me to approve every database query. I finally asked her why she never just tried something. She said she didn't want to break production. I had never explicitly told her that our dev environment was safe to break. I'd assumed she knew. That assumption cost us months of her growth.
So I changed my approach. Instead of giving her a task with a step by step plan, I gave her a vague problem and a deadline. 'We need a report that shows order delays by region. Figure out the data model and send me a draft.' She panicked a little. Then she started asking questions, not for permission but for understanding. She made a wrong assumption about the join, and the query returned duplicates. We caught it in code review. But she learned more from that one mistake than from ten perfectly specified tasks.
The hardest part for me was staying quiet during pair programming sessions. I'd want to grab the keyboard and just fix the syntax error. Instead, I'd ask 'what do you think that error message means?' Sometimes she'd sit there for five minutes reading it. That felt agonizing at first, like wasted time. But it wasn't. Every time she worked through it herself, she built a little more confidence.
I also learned to set explicit guardrails early. Not vague reassurances like 'be careful' but concrete boundaries. You can drop tables in the sandbox database, that's what it's for. You cannot run migrations on production without a second pair of eyes. You can push to a feature branch and break the build, but don't merge to main until tests pass. Once those rules were clear, the fear went away.
Now when I bring on a junior developer, I tell them on day one that my goal is to make myself unnecessary. That sounds harsh, but it's the truth. The measure of good mentorship isn't how productive they are in month one, it's whether they can handle a production incident alone in month twelve. And that means letting them struggle, letting them fail in safe places, and biting my tongue when I'd rather just do it for them. It's uncomfortable. But every time I've done it right, the payoff has been a developer who doesn't need me anymore. And that's exactly the point.