The first act of people management for many engineers is often unofficial. They find themselves, through the luck of the draw, mentoring someone.
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.
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?
The first type of mentorship relationship we’ll cover is the temporary employee. For most tech companies, this is a summer intern, some bright student still in the midst of earning a degree and looking to get some valuable experience by working for your company. The screening process for such students varies; many companies view these opportunities as a pipeline to hiring great talent straight out of college, but if you’re taking on someone who is more than a year from graduation, it’s more realistic to expect that the candidate will a) know very little, and b) probably go elsewhere next year for his internship unless he has an amazing experience. No pressure.
So you find yourself mentoring a college student with little real experience. How can you make sure that his summer is awesome? Even if your company doesn’t love him, you want him to love you, because he’ll go back and tell all his friends about the summer he had working for your company. That can have a big impact on your ability to hire full-time from the graduating class, and the fact that you pulled interns from that school probably indicates a serious interest in hiring new graduates full-time as well. But don’t worry! Making interns happy isn’t rocket science.
The first thing you need is some sort of project for this intern to work on. It would be nice if you, as the mentor, weren’t stuck coming up with the idea for this project, because doing so can be a daunting task. Without a project, your intern has a good chance of being completely lost and bored the entire summer. Figuring out what to do in a workplace is hard enough for experienced hires, so it’s an especially tall order for an intern. You have to have a project in mind—at least something to get him started for the first couple of weeks. If you’re truly drawing a blank, look at small features of your own current project that would take you a few days to complete, and start there.
The intern’s first few days will be similar to those of any new hire: onboarding, getting used to the office, meeting people, learning the systems. Sit with him as much as possible these first few days. Get him started installing the IDE and checking out the code. Touch base several times a day to make sure he’s not feeling lost or overwhelmed by the volume of new information. In the meantime, prepare yourself for his project.
Once you have a project, start applying your budding knowledge of project management to the task at hand. Is this project broken down into milestones? If not, spend a little time in the first few days of the intern’s tenure breaking it down. Walk through the breakdown with your intern. Does it make sense to him? Listen to his questions and answer them. Remember, you’re practicing skills that you will need should you decide in the future to become a manager. In this case, these skills are listening, communicating what needs to happen, and adjusting to his responses.
Listening is the first and most basic skill of managing people. Listening is a precursor to empathy, which is one of the core skills of a quality manager. You need this skill wherever your career takes you; even principal engineers with no reports need to be able to hear what others are really saying. So, when your mentee is speaking to you, pay attention to your own behavior. Are you spending all your time thinking about what you want to say next? Are you thinking about your own work? Are you doing anything other than listening to the words coming out of his mouth? If so, you’re not listening well.
One of the early lessons in leadership, whether it is via direct management or indirect influence, is that people are not good at saying precisely what they mean in a way that others can exactly understand. We have yet to achieve Borg hive mind or Vulcan mind meld, so we’re constantly pushing complex ideas through the eye of the needle of language. And language is not something that most engineers have mastered in nuance and interpretation. So listening goes beyond hearing the words your mentee is saying. When you’re face to face with another person, you also have to interpret his body language and the way he’s saying those words. Is he looking you in the eye? Is he smiling? Frowning? Sighing? These small signals give you a clue as to whether he feels understood or not.
Be prepared to say anything complex a few times, in different ways. If you feel that you don’t understand something your mentee has asked you, repeat the question in a different way. Let him correct you. Use those whiteboards scattered around your office, if necessary, to draw diagrams. Spend the time that you need to spend to feel understood, and like you understand the mentee. And remember that you’re in a position of huge power in your mentee’s eyes. He’s probably nervous about screwing this opportunity up, trying his best to please you, and trying hard not to look stupid. He may not ask questions even when he doesn’t understand things. Make your life easier and get those questions out of him. The odds of you spending all of your time answering questions are slim compared to the odds that your intern will go off in the absolute wrong direction because he didn’t ask enough questions.
With that said, what if the intern does spend too much time asking you for help, without ever looking for help himself? Well, that gives you an opportunity to work on another management skill: communicating what needs to happen. If you expect him to do research on his own before asking you a question, tell him so! Ask him to explain a piece of code to you, or some product or process, and point him to the documents that you believe explain it. If he can’t do it even with pointers, well, you’re starting to learn something about the potential of this intern. If all else fails, give him the first milestone of the project and tell him to work on it alone for a day or two. Therein lies the value of breaking the project down before the intern starts working on it: you’ve taken on some of the harder thinking up front. He may surprise you by finishing everything much faster than you anticipated, but what a happy surprise to have! Generally, you’ll need to provide some nudging and clarity along the way to keep the intern going in the right direction.
This brings us to the final management skill for you to practice: adjusting to the intern’s responses. So many things can happen in the course of this mentoring relationship. He can far outstrip your expectations. He can struggle with simple tasks. He can produce work very quickly, but it’s of poor quality, or he can work very slowly to produce something that’s overly perfect. In the first few weeks of the internship, you’re learning the frequency that you need to check in with him to provide the right adjustments. It may be once a week. It may be once a day. It may be less frequently than once a week, but I would recommend trying to check in once a week regardless, and spending any extra time as an additional interview/sell cycle for the company.
Hopefully, the summer ends on good terms. He completed a project that has some value. You got practice listening, communicating, and adjusting. He leaves thinking happy thoughts about your company, and you have gained some insight as to whether you want to do this management thing now, soon, or ever. Congratulations!
ASK THE CTO: MENTORING A SUMMER INTERN
I’m supposed to mentor a summer intern, but I have no idea where to begin. What should the intern do? How do I prepare to help this person have a great summer?
Preparing for a summer intern shouldn’t take much time, but it’s crucial to your success in mentoring him. Here are the basic things you need to do:
Prepare for his arrival. Do you know what day he arrives? If not, find out. Then make sure that the physical and digital environment will be set up for him when he gets there. Will he have a desk near you? A computer? Access to the systems and software? Even at big companies, a lot of these steps are sometimes overlooked for interns, and there’s nothing worse than showing up for your big job with nowhere to sit and no access to the systems.
Have a project for him to work on. The best internships are those with a clear project. The trick to deciding on an intern project is that you want something specific but not urgent, something relevant to the team but also something that could be completed by an entry-level engineer in the span of, say, half the time that your intern will be there. So if he’ll be there for 10 weeks, give him a project you think would probably take a new hire about 5 weeks. This achieves two goals. It gives him plenty of time, so if he has a lot of other activities to do, such as going to training or social events set up by your internship program, he will still have time to complete it. If he completes it before the end of the program, great—he should hopefully know enough about some part of your code base to do other work for the rest of the time. Remember, this person is an intern. He’s still in school and still learning, so expect him to move slowly, and be pleasantly surprised if he overshoots.
Plan to have him present the work he did at the end of the program. This helps him get exposure beyond you and the other mentors, and gives him the clear expectation that you want him to finish a project. It’s likely that you’ll be a big part of the decision about whether or not your company makes a full-time offer to this intern, or brings him back for another summer if he isn’t graduating yet. You’ll probably need to spend some time coaching him on how to make the presentation. If your team does regular demo days or team meetings, the presentation should probably follow that format. There’s no need for the presentation to be long or detailed, but showing off his work to the team is a great way to help your intern feel like his work mattered. I promise you that interns who feel like the company appreciated their work are the ones most likely to come back after they graduate.
My first job out of college was at a very large tech company. We’ll call it BigTechCo. I was put on a team that was in the midst of releasing a project several years in the making. My manager showed me to my office and then left me alone to figure out for myself what needed to be done. I didn’t know how to ask for help, and I was afraid that I would be seen as a fool if I did. Unsurprisingly, I got discouraged, and in my discouragement I decided that the best thing to do was to go to graduate school. So I did.
My first job out of graduate school could not have been more different. Instead of being shown a desk and left alone, I was set up with a mentor. He encouraged me to ask questions. We did some pair programming so that I could learn the code base, and the way that testing worked for this project (my first taste of unit testing!). I was productive within days, and learned more in the first few months of that job than I had learned in the entire time I worked at BigTechCo. I credit this almost entirely to the mentoring I got when I started.
Mentoring new hires is critical. Your job as a new hire mentor consists of onboarding, helping this person adjust to life in the company effectively, and building your and her network of contacts in the company. It can be an easier job than mentoring an intern, but the relationship and mentoring will usually go on for a lot longer.
This is an opportunity for you to see the world of your company through fresh eyes. It can be hard to remember what it was like to experience your world for the first time. How does work get done? What are the rules, spoken and unspoken? For example, you may have a standard vacation policy in the HR handbook; this is a spoken rule. The unspoken rule is that you don’t take vacation the week after Thanksgiving because you’re in ecommerce and that’s an important week for the business. A more subtle unspoken rule dictates approximately how long you are expected to struggle with something by yourself before asking someone else to help you. There are many bits of process, culture, and jargon that are so second-nature that you might not realize they’re completely foreign to a newcomer. Noticing these things gives you the opportunity to clarify them. Unspoken rules don’t just make it harder for new people to join, they can also make it harder for you to do your job well. So take full advantage of this gift of fresh perspective.
Effective teams have good onboarding documents they provide to new hires. Things like step-by-step guides to setting up their development environments, learning how tracking systems work, and familiarizing themselves with the tools they will need for the job are crucial for new hires. These documents should constantly evolve to meet the changes of the workplace itself. Mentoring a new hire by helping her work through the documents, and having her modify those documents with any surprises she encounters during onboarding, provides a powerful message of commitment to her. It shows her that she has the power and obligation to learn, and to share what she’s learned for the benefit of your whole team.
Part of the mentoring opportunity here is the chance to introduce the new person around. Companies are full of human networks that exist to transmit knowledge and information quickly. Bringing this person into some of your networks will help her get up to speed faster, and it will give you a new entree into whatever networks she ends up forming and joining in her time with the company. People planning on staying with the same company for a long time, particularly in large companies, often find opportunities via informal networks. Your mentee may someday be on a team that you are interested in joining, or you may someday want to bring her into a team you are running in another area.
Even if you have absolutely no interest in management, it’s very difficult to build a career at any company with multiple teams without building a strong network of trusted people to share information and ideas with. The workplace is built around humans and their interactions, and these networks form the basis of any career, whether it’s focused around management or individual technical contributions. You may be an introvert, or someone who does not find socializing easy, but conscious effort and practice in getting to know new people and helping them succeed will pay off. Your attitude about this will determine success or failure. Adopt the mindset that network building is a worthwhile investment of your time and energy.
I’m only going to say a few words on this topic, because this type of mentoring is usually not directly related to the path of management. With that said, at some point in our careers most of us will engage in some degree of technical mentoring, career mentoring, or both. Many of us will also be given a mentor, or perhaps be encouraged to find a mentor. How can you make this type of mentoring effective?
The best mentoring relationships evolve naturally and in the context of larger work. When a senior engineer mentors a junior engineer on the team in order to help him be more productive, they can work on problems together that are relevant to both of them. The senior engineer gets value because the code written by the mentee is better, requires fewer revisions, and develops faster. The junior engineer obviously gets the value of hands-on instruction and access to someone with a deep understanding of the context he is working in. This type of mentoring is usually not a formal relationship and may be an expected part of the job for senior engineers because it delivers so much value to the team.
Many companies run formal mentoring programs where they match people up across teams, and while these programs can sometimes enhance networks, they are often an ambiguous obligation for both the mentor and the mentee. If you find yourself in one of these relationships, the best thing you can do is be specific about your expectations and goals around it.
Tell your mentee what you expect from him. If you want him to come prepared for your meetings with questions he has sent you in advance, ask for that. Be explicit about your time commitment. And then be honest with him when he asks questions. There’s no point in being a mentor to a relative stranger if you can’t at least use that professional distance to offer him the kind of candid advice that he may not get from his manager or coworkers.
It’s also OK to say no to mentoring. Sometimes you can feel obligated to say yes to every person who asks you for help, but your time is valuable. Don’t do it unless you think it will be rewarding for you and the person you’re mentoring. If someone asks you to be his mentor and you can’t accept, it’s best just to say that you can’t do it. Don’t feel like you must give him a reason just because he asked. When your manager asks you to mentor someone and you don’t have the time to do it, saying no is trickier. You may need to give your manager some reasons, such as your current workload, a planned vacation, or other commitments that would make mentoring impossible. Whatever you do, don’t say yes and then fail to actually do the mentoring work.
Think about what you want to get out of this relationship, and come prepared to your sessions. This advice is especially relevant if you’re getting mentorship from someone outside of your company, who is not being paid but is volunteering as a friendly gesture. You owe it to this person not to waste her time. If you don’t have the time to prepare or don’t feel that preparation is necessary, ask yourself whether the mentoring relationship is really something you need at all. Sometimes we end up with mentors because someone thinks we should have them, but there are only so many people we can meet for coffee, and only so many hours in the day. You don’t have to have a mentor. Maybe instead you need a friend, or a therapist, or a coach. It can be easy to undervalue your mentor’s time, because you usually aren’t paying for it, so be respectful and consider finding a paid professional to help you instead.
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.
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).
ASK THE CTO: HIRING INTERNS
My company has had several inquiries as to whether or not we hire interns. We have not in the past, but I’m tempted to start doing this in order to increase our hiring pool. What should I be thinking about?
Internship programs are a great way for companies to increase their hiring pipeline and find strong candidates before they graduate. However, many companies think that the goal of an internship program is to hire interns who will do a lot of work for them, and thus they miss the value of the program. I do have a couple of pieces of advice:
- Don’t hire interns who are not going to graduate in the year after their internship. These days, college graduates from technical programs have so many options, and it’s unlikely that an intern you hire who is not close to graduation is going to come back and work for you full-time. Your internship program is not a way for you to get extra work done in the summer; it’s a way for you to identify and attract talent. People who are two or more years away from graduation are likely to look for new opportunities to explore before they commit to their first full-time job. When you’re hiring only a handful of interns, you want all of them to have high potential for becoming full-time employees.
- Hiring interns is relatively easy compared to hiring full-time graduates. There is simply less demand for interns, and thus you should have a lot of options. You can choose to take this opportunity in many ways, but encourage you to push for hiring candidates from underrepresented groups. Diversity in your internship program will translate to diversity in your new grad hiring, which in turn will translate to diversity in your organization.
It’s important to focus on three actions for yourself as a mentor.
As you grow in your career, you’ll experience a lot of teachable moments, a lot of lessons in how things should or should not be. These can be “best practices,” or scars caused by mistakes. This unconscious buildup can cloud our thinking and reduce our creativity. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Technology is always changing around us, so we must continually experience that change.
Mentoring provides a great opportunity to cultivate curiosity and see the world through fresh eyes. When faced with a mentee’s questions, you can start to observe what about your organization is not so obvious to a new person. You might find areas you thought you understood but cannot explain clearly. And you’ll have the opportunity to review the assumptions you’ve collected in your time working that may be worth questioning. While many people think creativity is about seeing new things, it’s also about seeing patterns that are hidden to others. It’s hard to see patterns when the only data points you have are your own experiences. Working with new people who are learning things for the first time can shed light on these hidden patterns and help you make connections you may not otherwise have made.
Mentoring, when done well, starts to shape the skills every future leader needs. Even for those who won’t go on to make management their career, there are clear benefits to taking some time to mentor and learn from the experience, because mentoring forces you to hone your communication skills. It requires you to practice listening, in particular, because if you can’t hear the questions you’re being asked, you’ll never be able to provide good answers.
Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying. To work successfully with a newcomer or a more junior teammate, you must be able to listen and communicate in a way that person can understand, even if you have to try several times to get it right. Software development is a team sport in most companies, and teams have to communicate effectively to get anything done.
Your career ultimately succeeds or fails on the strength of your network. Mentoring is a great way to build this network. You never know—the person you mentor could provide the introduction to your next job, or even come work for you in the future. On the flip side, don’t abuse the mentoring relationship. Whether you’re in the mentor’s seat or acting as the mentee, remember that your career is long and the tech world can be very small, so treat the other person well.
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?