Career Nav #79: You Can Be a Mentor: How and Why

iTunes – Spotify – Google – Video – More Episodes

Sumayyah Ahmed, Technical Lead at Square, shares her talk, “You Can Be a Mentor: How and Why.” She discusses how you can mentor on an individual, company, and industry level. She also shares the value of peer mentoring.

Mentoring skills for everyone, regardless of level and experience, can become a hurdle the further on you get in your career. You can be a mentor. You can build these skills and use them to propel your career forward. These are skills that translate across programming skills or backgrounds.

I’ve been an Android engineer for about nine years. I spent much time getting mentored throughout my time here and the companies I worked with. I had a couple of formal mentors, but I also got mentored by many other people and many other sources. In the past five or so years I started giving back this knowledge, filling in knowledge gaps for teammates and starting some sort of learning or organization. Just engaging in communities, engaging with people. 

My mentoring story starts back in 2013. Android was a very young platform. This was the time when Google technically owned Android, but there was very little support or tutorials or resources or design. When I started, I struggled to figure out what to do and how to do it. People were just throwing together what error code they could. You could upload this to the play store. There was no real guidance.

Things slowly started to change. By 2015, I had started reading more blog posts and watching YouTube videos, caught up on the single Android podcast that existed at that time. I was no longer making such catastrophic mistakes. Between 2015 and now, I joined Comcast and I was suddenly working with this large team of people on a very large scale application. We started going through major transformations in the app. Things like moving from a monolithic code base to a modularized microservices style architecture moving from Java to Kotlin, from Retrofit callbacks to RxJava, to Coroutines, MVP to MVI, to MVVM.

If you’ve been in tech for any amount of time, you know that there’s always the next thing coming. The industry always outpaces the educational material. It ended up being me and my teammates just working together using online resources, trying to figure out how to do all of these things. We were getting help from various resources because of the nature of engineering. We sort of pluck together all these sources and put them together to come up with these solutions that people haven’t done before. This is all mentoring.

I was mentored by my teammates and also online resources like Stack, Overflow, YouTube and Medium. I learned, made catastrophic mistakes, learned again and gradually started to share the knowledge I had accumulated from all these sources. Every engineer at every level can be a mentor to others. It doesn’t matter if you’ve been working for 10 years or for two years, or if you’re a student or if you haven’t programmed at all. You can get started with mentoring skills. You don’t have to wait for permission or authority. It doesn’t have to be in your job description. You can start mentoring. 

I started with focusing on Android communities, but really you can put in your program in a community of choice. Engineering and programming communities really need mentoring. By mentoring, we can start to have an industry-wide impact. We all have knowledge to share. Everybody has some experience, solution, fix, or story to share. If you’ve been an engineer for any length of time, if you’ve ever worked on something fairly complicated, you probably know something that’s not out there online. That makes you a knowledge repository, that makes you a potential mentor.

We are expected not just to be technical experts or domain knowledge experts. We are increasingly evaluated on our ability to impact people, large numbers of people across teams, organizations and sometimes across business. Mentoring is a huge part of having an impact on others. This is something that can propel your career forward from mid-level to senior or from somebody who’s writing code to somebody who starts getting leadership opportunities.

We’ll start by redefining what we think of as mentoring. You often have to be at a certain level or meet some requirements to qualify as a mentor. That means that the pool of available mentors is just a small group of maybe your senior most people. Then you’re also limited by their time and availability. Not everybody gets to participate in these relationships. All of us work in teams. All of us work with other people. These people are a great resource to start building these relationships for teaching and learning. Peer mentoring is using your peers as a network of learning and teaching opportunities.

You have the people around you to use as resources. We have trust built in. We have open channels of communication. We have a shared context that we work in. This makes the buy-in for mentoring much lower than creating up-down relationships from scratch. Onboarding is a classic example of lateral or peer mentoring. An old engineer takes on a new engineer and basically just teaches them, this is our code base, this is our documentation, this is the context of our technical decision making. These are the people to go to for help, everything they need to know to be successful in this new team. 

When I started peer mentoring, I got stuck because I thought, what can I teach? If I’m trying to mentor my peers, we all have the same amount of experience, we’re all competent, we’re all smart. Look at your team and find the knowledge gaps. What is that gap between the technical needs of your code base or the future technical needs of your code base and the team’s current skill set right now? Once you start building bridges, you’re actually facilitating knowledge transfer among the team. You’re upskilling an entire team at once. This is powerful. That’s what mentoring does. You can mentor many people at once and raise the bar for a large number of people. 

Now we’re doing glue work. If you’re unfamiliar with this term, it comes from Tanya Reilly’s talk, Being Glue. She defines glue work as all the non-coding work that makes tech teams effective and productive. It’s things like communication, documentation, processes and mentoring. Glue work is expected when you’re a senior, and it’s risky when you’re not. If your official job description doesn’t include mentoring, you’re potentially risking your job by taking time out to mentor others.

You must focus on relevancy, which seems obvious but important. Find relevant topics and figure out what knowledge gaps will move the needle for your team. Find the technical goals that are important and figure out those gaps. Not only do we not want to get fired for mentoring, we also want to get credit, because mentoring skills are probably as complicated as technical skills. It’s a skill that will take time, effort, and consistency. Everything that you’re doing mentoring-wise should never be a surprise to your manager. Who you’re mentoring, how much time you’re spending with them, what you’re doing, what you’re mentoring on, your manager should be aware of all of this. Make sure your work is quantifiable, with a measurable impact. We talked a lot about working in the context of a team, working in the context of a company, specifically tech teams. What about mentoring outside of a company? Let’s talk about having an impact on people regardless of what company you work for or what particular team you’re working with. Mentoring can happen across engineers everywhere. There’s no guarantee that you understand what is going on when trying to start your career as an engineer. All of this makes mentoring necessary.

Anybody who has that experience now is way ahead of somebody just starting out, and this is knowledge that doesn’t exist online. It doesn’t exist in books or documentation, it exists in the people who’ve done the work. We ask people who have something to share. They now can make an impact across the industry. There are probably local meet-ups near you. These are good places to be. There are tech bootcamps that are in the middle of training. They often need mentors to help guide students with the work. It requires us to put ourselves in new environments make new connections, and it takes deliberate effort. You have to approach it from a place of humility and be open to learning yourself. A big part of mentoring others is being open to being mentored yourself. These relationships aren’t one way, there’s always going to be a two-way relationship here.