Mentoring is one of the most important practices for growing a successful team. It’s essential to balance active mentoring activities — such as showing or guiding through code — with more passive ones, where junior engineers can work independently, applying concepts and patterns you introduced earlier. Having junior engineers only absorb information through shadowing or listening accounts for just 10% of learning, according to the 70-20-10 model.
During passive mentoring activities, senior engineers must focus deeply on the expectations of their role. Every interruption in the practice of junior engineers has a negative effect, because it’s important for them to step outside their comfort zone and develop the tools to get themselves out. Are they blocked? Allow them to identify it themselves. Senior engineers need to practice being quiet and calm, avoiding negative-sounding comments — and only jumping in when asked.
This will vary from person to person, but in my experience, junior engineers are more comfortable learning through examples they can copy. I had to go through some very uncomfortable experiences while mentoring junior engineers (and I’m very sorry for these) before realizing that I was bringing too many technical and theoretical concepts into my explanations. I’ll try to justify myself by saying that it’s because I’m passionate about these topics — and I enjoy exploring them deeply — but that’s not the point of mentoring. Juniors are not here to study something in depth; that would be a class or a lecture. They are here to grow, and that requires them to take small steps and receive fast feedback.
I still remember one of the first tasks I took as a developer, and how my mentor at that time gave me the right tools to thrive. I was ramping up in my first position as a junior Java developer, still at university and having recently completed my Java SL-275-SE6 training — so I knew what I was doing technically — but I had no hands-on experience. This first task required me to connect to an RDBMS (I can’t remember which one we were using). I had no idea how to do that, and asking an AI wasn’t in the roadmap for another 15 years. My mentor made it simple: “You’ll need to use a driver to connect to the DB. See this example to learn how to do that. Here’s more documentation if you’d like to dig deeper.” That’s it. That’s what any junior needs: a clear example, and some follow-up if they’re interested in more.
Sometimes I make the mistake of trying to include juniors in deep technical conversations happening in the team, with the intention of not leaving them aside — which is never nice. But most of the time that backfires: junior engineers can feel out of place, not understanding the technical topic or lacking the organizational context around the decision that needs to be made. They may feel like they are expected to contribute something they don’t yet have, undermining their confidence. Or they may just get lost and waste time they could have used more effectively.
I think it’s always better to consider what value anyone in these meetings can bring or take, and be clear about it before you start.
-
“I want you to focus on the architecture presentation and collect any questions you may have. We can go through them after the meeting.”
-
“I want you to speak up if something is unclear: this meeting is a safe space to do so.”
-
“I know you want to show you’re capable — but the team will benefit the most if you make progress on this task right now. We will share the outcomes of this meeting with the whole team.”
Final thoughts
Mentoring is a skill that requires practice, patience, and empathy. It’s not about showing off your knowledge or expertise, but about helping others grow and succeed. As a senior engineer, you have the opportunity to make a significant impact on the careers of junior engineers, and ultimately on the success of your team and organization.
More info about the 70-20-10 model: The 70-20-10 Model for Learning and Development