The Importance of Mentoring to Junior Team Members

Mentors are commonly assigned to junior members of a team, such as new hires straight out of school or student interns. Many organizations use mentors as part of their onboarding process for all new hires. Sometimes the mentor is another junior person on the team, perhaps herself only a year or two into the organization; someone who can still clearly remember the onboarding or internship process herself, and can closely relate to the new person. Other times the mentor is a senior engineer who can act as a technical mentor in addition to helping the new hire get up to speed on the process. In a healthy organization, this onboarding mentorship role is used as an opportunity for both parties. The mentor gets the chance to see what it is like to have responsibility for another person, and the mentee gets an overseer who is focused on him alone, without other reports clamoring for his mentor’s attention.

I remember my first mentor, who guided me through my first serious taste of working as a software engineer. I was an intern at Sun Microsystems, working on a team that wrote JVM tools. This was the first job where I had a real software project to build, and I was lucky enough to have a great mentor, a senior engineer named Kevin. Kevin was a memorable mentor because, despite being a senior technical leader in the area we were working in, he made time for me. Instead of showing me a desk and leaving me to figure out what exactly I needed to do, Kevin took the time to discuss projects with me, to sit with me at the whiteboard, to go through the code together. I knew what I was expected to get done, and when I got stuck, I could ask him for help. That summer was critical for my development as a software engineer, because under his guidance I began to see that I could actually do real-world work and that I was capable of being a productive employee. Working with Kevin was one of my first major career milestones. This experience taught me the value of mentorship.

Being a Mentor

If you find yourself in the mentor’s seat, congratulations! This is an experience that not everyone will get: an opportunity to learn in a fairly safe way about the job of management, and the feeling of being responsible for another person. It’s unlikely that you’ll get fired for being a bad mentor (unless, of course, you behave in an inappropriate manner—please don’t hit on your mentee!). For many mentors, the worst that can happen is that a) the mentee is a drain on their time and they get less coding work done, or b) they do such a poor job that someone whom the organization might otherwise want to hire/keep around has a bad experience and doesn’t join the organization, or opts to leave the organization sooner than she otherwise might. Sadly, the second outcome is far more likely than the first. Great talent is sometimes squandered by weak mentors who do little but ignore their charges, waste their time with trivial projects, or, worst of all, intimidate and belittle them out of ever wanting to join the organization. But you, dear reader, don’t want to do this. You want to be a great mentor! Or perhaps you are already a manager, looking to make your team more effective at the mentoring relationships you need them to take on. How do you create good, effective mentoring relationships without slowing development down too much?

Good Manager, Bad Manager: The Alpha Geek

In some offices, whether in a mentoring relationship or outside of one, you’ll encounter an “alpha geek.” The alpha geek is driven to be the best engineer on the team, to always have the right answer, and to be the person who solves all the hard problems. The alpha geek values intelligence and technical skill above all other traits, and believes these attributes should determine who gets to make decisions. The alpha geek usually can’t deal with dissent, and is easily threatened by those she perceives as trying to steal her spotlight or who might upstage her. She believes herself to be the best, and responds only to messages that support that view. The alpha geek tries to create a culture of excellence, but ends up creating a culture of fear.

The alpha geek is usually an excellent, effective engineer who goes into management either because she was pushed into it or because she believes that the smartest person on the team should be the manager. She tends to undermine the people who work for her by belittling their mistakes and, at her worst, redoing the work of her teammates without warning. Sometimes the alpha geek will take credit for all of the work that a team does rather than acknowledging the strength of the team members.

At their best, alpha geeks can be inspirational to younger developers, even though they seem very intimidating. He has all the answers. She worked on the original version of that system 10 years ago and still knows the authors, and if you need to figure something out, she can do it without a problem. He knows exactly why that thing you’re trying to do won’t work, and when it doesn’t, believe me, he’ll remind you how he told you so. If only you had listened to him and done things his way! Alpha geeks have a lot to teach you, if they want to, and they can design great systems that can be fun to help build. In general, alpha geeks would not have gotten as far as they have without being very smart, so they do have a lot that they can teach their teams, and many engineers respect that intelligence enough to put up with the downsides.

At their worst, alpha geeks can’t let anyone else get any glory without claiming some of it for themselves. They are the origin of any good ideas but had no part in creating the bad ideas, except that he knew they would fail. The alpha geek believes that every developer should know exactly what she knows, and if you don’t know something, she will gleefully point out your ignorance. The alpha geek can be very rigid about how things should be done and closed off to new ideas that he didn’t come up with. Alpha geeks get very threatened when people complain about systems they built or criticize their past technical decisions. They absolutely hate it when they have to take direction from anyone they don’t respect intellectually, and can be very demeaning toward people in nontechnical roles.

The alpha geek habit often starts to show up when engineers first become mentors. If you have ever wondered why people don’t seem to come to you for help despite your clearly strong technical skills, ask yourself whether you’re showing some signs of being an alpha geek. Do you view yourself as an engineer who does not pull any punches and always says exactly what you think? Are you eagerly seeking out the gotcha, hunting for mistakes, reluctant to admit that someone else has had a good idea or has written good code? Do you believe that correctness is so much more important than anything else that it is always worth fighting hard for what you believe to be correct?

If you suspect that you may be an alpha geek, mentoring can be a great opportunity to break out of that habit. If you view your mentee as someone to teach and guide, where your goal is to help her in the way that best works for her, you can start to see where your aggressive style makes it harder for her to learn. Practicing the art of teaching can help us learn how to nurture and coach, how to phrase things so that others will listen, instead of just shouting them down. On the flip side, if you’re unwilling to change your style to help a mentee succeed, please don’t volunteer to be a mentor!

Alpha geeks make absolutely terrible managers, unless they can learn to let go of their identity as the smartest person in the room and most technical person on the team. Highly technical hands-on managers can be good for small teams of senior engineers, but alpha geeks are often better off kept out of management and given more of a focus on technical strategy and system design. You tend to see alpha geeks in the CTO role at technology-focused startups, where they are given a design and development focus across from an execution-focused Vice President of Engineering.

If you’re ever in the position to promote people to management, be very, very careful in giving your alpha geeks team management positions, and keep a close eye on the impact they have in that role. The alpha geek culture can be very harmful to collaboration and can deeply undermine those who feel unable to fight back. Alpha geeks who believe that their value comes from knowing more than others can also hide information in order to maintain their edge, which makes everyone on the team less effective.

Tips for the Manager of a Mentor

What you measure, you improve. As a manager you help your team succeed by creating clear, focused, measurable goals. So often, we fail to apply this basic wisdom to the process of assigning mentors, but it applies here as much as anywhere else. When you need to assign a mentor for your new hire or intern, figure out what you’re hoping to achieve by creating the relationship. Then, find the person who can help meet those goals.

First of all, figure out why you are setting up this mentoring relationship in the first place. In the two cases I discussed earlier, the mentoring relationship existed for a very specific purpose: helping a new person on the team, whether a full-time new hire or someone who will only be around for a few months, get up to speed and be productive. Of course, those aren’t the only kind of mentoring programs that companies run. Sometimes people set up mentoring programs to help junior people pair with senior people outside of their team, for career or skills growth. These programs can be nice, but often the mentor and mentee are given very little guidance beyond the fact that they have been matched together. Most of the time, these programs yield very little to either party. If the mentor is not engaged or is too busy to spend any time on this project, it’s a disappointment for the mentee. If the mentee doesn’t know how to ask for help or what to do with the mentoring relationship, it often feels like forced socializing and a waste of time for both parties. So if your company is setting up mentoring programs outside of new hires and interns, try to make sure that there is some guidance and structure to the program before you push people into it.

Secondly, recognize that this is an additional responsibility for the mentor. If the mentor does a good job, her productivity may slow down some during the mentoring period. If you’ve got an engineer involved in a time-sensitive project, you may not want to push him into mentoring at the same time. Because this is an additional responsibility, treat it as you would any other important additional responsibility you might hand out. Look for someone that you believe can succeed in the role, and who wants to distinguish herself beyond her coding ability.

Whatever the source of the mentoring arrangement, common mentoring pitfalls include viewing it as a low-status “emotional labor” position, assuming that “like” must mentor “like,” and failing to use the opportunity to observe potential on your team firsthand.

Emotional labor is a way to think about traditionally feminine “soft skills”—that is, skills that address the emotional needs of people and teams. Because the outcome can be hard to quantitatively measure, emotional labor is often dismissed as less important work than writing software. It’s assumed to be something that should just be provided without financial recognition. I’m not suggesting that you should pay people extra money to serve as mentors, but they need to be recognized for the work they put in, and the mentor should be treated as a first-class citizen with respect to other responsibilities the person might have. As I said before, plan for it, and provide the mentor the time to do the job right. You have already invested in creating this mentoring relationship, whether it’s the thousands of dollars and many hours spent on hiring, or the overhead and coordination of creating a mentoring program. It’s worth continuing the investment through to fruition by recognizing that mentoring is work that takes time, but also yields valuable returns in the form of better employee networks, faster onboarding, and higher internship conversion.

When I ask you to not assume that like must mentor like, I mean that you should not expect women to only mentor women, and men to only mentor men, people of color (PoC) to only mentor other PoC, and so on. This comes up a lot in mentorship programs. These types of mentoring relationships have their place, but as a woman in tech, I personally get tired of the only mentoring being focused around lines of diversity. As you’re thinking about creating mentorship relationships, unless the purpose of the mentoring program is driven from a diversity focus, give people the best mentor for their situation. Like mentoring like does make sense in one case—namely, having mentors from similar job roles. When the mentoring is expected to have a job skills training component, the best mentors are going to be people who are further along in their mastery of the job skills that the mentee is trying to develop.

Finally, use this opportunity to reward and train future leaders on your team. As you know by now, leadership requires human interaction to exist. Developing patience and empathy is an important part of the career path of anyone working in a team-based environment. Brilliant, introverted developers may not ever want to formally manage, but encouraging them to mentor 1-1 helps them develop stronger external perspectives, not to mention their own networks. Conversely, an impatient young engineer may find a degree of humility when tasked with helping an intern succeed (under your supervision).

Key Takeaways for the Mentor

It’s important to focus on three actions for yourself as a mentor.

Assessing Your Own Experience

Here are some questions to consider as you develop this part of your career:

• Does your company have an internship program? If so, can you volunteer to mentor an intern?

• How does your company think about onboarding? Do you assign mentors to new hires? If not, can you propose to your manager that you try doing this, and volunteer to mentor someone?

• Have you ever had a great mentor? What did that person do that made you think he or she was great? How did the mentor help you learn—what did he or she teach you?

• Have you ever had a mentoring relationship that didn’t work out? Why didn’t it work out? What lessons about that experience can you apply to avoid similar failures going forward?