The juniors we ended up trusting were not the ones we protected the most. They were the ones we handed something real, a little before we were comfortable, and then stood close by while they did it. Trust is not a thing you grant after enough time passes. It is built by handing over responsibility and watching it be carried.
Give them ownership, not tasks
A junior who is only ever handed pre-chewed tickets stays a junior, because the hard part of engineering is deciding what to do, and you have done that part for them. We give a junior a whole small thing to own end to end, a real feature with a real user, even if it would be faster for a senior to do it. The slowdown is the cost of growing someone, and it pays back fast once they can carry the next thing alone.
- Hand over a complete small problem to own, not a slice of someone else's
- Let them make reversible mistakes, then review what happened together without flinching
- Explain the why behind decisions, so they learn judgment and not just outcomes
- Pull back your involvement deliberately over time, so independence is the goal, not a surprise
Mentoring scales when it stops being one person
If a junior depends on a single mentor, you have built a bottleneck and a single point of failure for that person's growth. We make growth a team property. Code review is teaching, not gatekeeping. Pairing rotates. The junior gets exposed to several senior styles and learns to synthesize their own, instead of becoming a smaller copy of whoever happened to onboard them.
You have mentored well when the person no longer needs you for the thing you taught, and is teaching it to the next person. Dependence is a failure mode dressed up as importance.
Feedback close to the moment
Saved-up feedback delivered in a quarterly review is almost useless. The junior cannot reconnect it to the decision it is about. We give it small and immediate, in the review, in the pairing session, while the context is warm. And we are specific. Good job helps no one. This is the case you did not handle, and here is why it matters, is something they can act on tomorrow.
The honest part nobody likes
Growing people is slower than doing the work yourself, and it stays slower for months before it gets faster. There is a real temptation, under deadline pressure, to take the task back and do it. Every time we gave in to that we trained the junior to wait for rescue. The teams that build trust are the ones that hold their nerve and let the slower, correct thing happen, because in a year they have three engineers they trust instead of one who is exhausted.