There is an industry-wide lack of developers all over the globe, and it’s worse at the senior level. Companies have to put a lot of effort into getting the best talent with a lot of experience, and this holds back projects significantly.
One possible medium- to long-term solution is to get your existing developers to senior level. You can speed the process up a lot by making sure to provide them with all the right resources to learn, improve and gain experience.
Mentoring is underutilized in the software development industry today. So, Karolina Toth did an interview with Gergely Orosz in episode 2 of the Level-up Engineering podcast. Gergely was Engineering Manager at Uber at the time of the interview, and gained a lot of experience with mentoring during his years as a developer/manager.
Let’s see what he has to share!
In this blog post, we're covering:
The biggest challenge has been becoming a manager, which is pretty much a glorified coach. A manager’s role is to help others succeed. I have completely different problems compared to an engineer. Back then, my code didn't compile, and I was frustrated about it. It’s all different now; the challenges keep changing.
Running a good team meeting used to be a big challenge for me a couple of years ago, but that has changed. I think the beauty of software engineering and a growing company is that things change all the time. Uber today is very different from what it was when I joined three years ago. In tech, your company, your team and your role can change a lot in three years.
I wanted to work more on the people side, so I became a manager. I did a lot of things in tech; I worked on a lot of different tech stacks. I enjoyed learning them, but after a while, I felt like the most interesting challenge of working in a team was the team itself and the people in it.
I'm considering writing a book on software development, so I reached out to some of my experienced colleagues, and asked them what their challenges were. It seems like the more experienced people are, the more they will say people and communication are their top challenges, and a lot fewer mention code, tools, languages or frameworks.
When I was a junior engineer, I was assigned to an experienced developer to work on a project. We worked together, and that person actually mentored me a lot. He asked me a lot of questions, challenged me, and didn't say that I was wrong; instead, he asked, “What do you think about this edge case?”
That was mentoring, I just never realized it. I never thought of myself mentoring others either, even though I was doing it via code reviews, or just giving feedback. A mentor is basically a person helping you get better at your job.
So, it was a foreign concept to me before I joined Uber. I never used the term before. This is typical for software developers, unless you work at big companies like Google, who have official mentoring programs. When I came to Uber, people asked, “Hey, who's your mentor?” And I asked, “What’s mentoring?”
Uber has an internal site where mentoring is set up. I didn’t know what it was supposed to look like at the time. Now, I think a lot more about it.
Mentoring is common in the business world, and people often discuss their mentorships. You can follow successful entrepreneurs’ processes from their books in terms of asking for mentorship, setting up an introductory meeting, having regular check-ins and so on.
Everyone is a mentee in some ways. When I became a developer, I thought I knew everything, and it took years to figure out that I barely knew anything. When I became a manager, I was thinking I should be confident, but I knew from my past experience that I probably didn’t know enough.
I wanted to have mentors to help me with their managerial experience—someone I could talk to about improving and getting some honest feedback. It’s great to be surrounded by smarter people in some areas because you get to learn from them.
At Skyscanner, I was looking for mentorship as an engineer. I talked to a few people, but I didn't feel they were open to sharing, or that I had much to learn in other areas. That was a failed approach, but at least I tried.
At Uber, I emailed a couple of people and said, “Hey, I'm really looking for mentorship. Would you be open to having an introductory meeting? Just 30 minutes to talk through and see if we can work together?”
Two out of three people I talked to said they're too busy, because they had too many other mentees, but one was up for it. We talked, it was really nice, and we started to meet up every two weeks. This was over video chat because she was based in San Francisco, but we kicked it off right there.
I think it's important that you're focused when you're seeking mentorship. It's not really fair to go up to someone and say, “Hey, can you mentor me?” and then just wait for them to do the work. You don't want to waste anyone's time. Typically, mentors are busy, and they often get many requests.
First of all, you want to tell them what they can help you with. In my experience, people tend to want to help.
The first step when you're looking for mentorship is to make a list of the people who you think could help you. Whether they’re inside your company or outside, reach out to them and be specific. For me, it was becoming better with people. It could be learning about technology or communication as an engineer. Start there, so you can set the expectation.
We had a resource inside the company with a suggestion to set up an introductory meeting, and there was a list of things that you could do there. It's nice to set the ground rules for what we want to get out of the mentorship. How often should we catch up? What is it we should talk about in the next 3-4 weeks? The more specific, the better.
I view having a mentor as a privilege, so don't take it for granted. It's important that you invest time into it. I always prepare for the meetings with my mentor. I put together things that I’d like to share or get feedback on.
This is the way to keep mentorship going, because my mentor has no obligation to spend time with me. Mentors do it because they're getting something out of it. They're enjoying it, they may be learning too, and they get to see some of their advice used.
My mentor is very experienced, with a busy schedule, and she still makes time for me, so it helps to be invested.
Once, I noticed a person who wasn't very good at writing readable code. He was not on my team, but I ended up reaching out to him saying, “Hey, I noticed this is something you might be interested in doing better; would you like to talk about it?” The point is that our topic was getting better at writing readable code, and we spent our sessions discussing how to do this.
It's easy to be a good mentor when the mentorship has clear goals. When you're a manager, in many ways, you are a mentor but with authority. That makes it somewhat different. You normally mentor people outside your team.
As a mentor, you share your experience and give advice, but it's key that you don't judge people. A mentor should always be on the mentee’s side, so you should separate it from managerial duties. If they take your advice, that's great. If they don't take it, that can get frustrating.
The more focused you are, the better. If you know what you're aiming to do, you can reflect on how things are going. I really enjoyed the mentoring relationship above, because I saw week after week how my mentee is getting better.
After a while, I ran out of things I could share. I thought he had really upped his game, and I told him so. Then we decided to catch up less frequently. We both got value out of this relationship. I got the fact that I was able to help someone without giving too much direction.
Some people may be struggling in some areas, like architecture or just expressing their thoughts on a product. Then I say, “Hey, I think you could use some help here. Why don't we go and find you a mentor?” I usually ask them to make a list of people they look up to.
For certain things, it may be better to keep it inside the company, but it could be outside as well. I give them tips on how to set up an introductory meeting. Sometimes, I just reach out myself as a manager in my report’s place. Then, they have an introduction meeting and typically set up a regular catch-up time.
When a developer approaches another for mentoring, it might also be the first time for either or both of them. I’ve heard from many developers recently that they were approached for mentorship for the first time. Some of them are a bit overwhelmed, and they don't know what to do exactly.
First, you should assess the person's expertise level. If they're an absolute novice in something and you're an expert, directing is useful, and you just tell them how to do it.
Let's say someone approached you for mentorship about how Git works. If they have no expertise, you just tell them what to do. You should only do this if the person has zero expertise.
Once they're more experienced, you should take a step back and just guide them. Instead of telling them what to do, you should ask, “Hey, what would you do if…?”, or, “Here's what I did before…”
When you're mentoring, you should be comfortable with your mentee taking a slightly different approach and not following what you did to the letter.
Finally, there's a point where they're better than you, and you can’t really help them professionally. Let’s say they’re stuck with a weird Git bug, and you have no clue how to solve it. Then you start coaching the engineers.
It's a bit of a rubber ducky situation. You ask them what approaches have they tried, what have they ruled out, and what do they think the issue might be? Anyone can coach anyone. Leadership coaches or executive coaches usually aren’t executives themselves. It's basically self-help.
If you know about these three ways, you can adjust your approach well. I usually start with a more coaching approach. When you assess the person’s expertise, you move on accordingly.
The skill I mentored people most about is project management. At my previous job at Skype, I was the scrum master, and we had a lot of different projects. Back at Skyscanner, I was a team leader, and I had pretty strong opinions on how to do efficient projects. When I came to Uber, people didn't have much expertise in this area.
I naturally became a mentor at this. I didn't want to do all the project management myself. In fact, I wanted other people to do it, so I ended up mentoring, and later coaching them. Now I have people who are better at running projects than myself, and I don't have much to add.
The biggest challenge that I see others encounter, and I've had as well, is that after a while, the mentoring process gets a bit redundant. You both get less and less value out of it. You start to get to know each other really well, so there's less to share, but you still keep meeting up. This is the point where you should admit that neither party is getting much out of it.
Find a way to reflect on how the mentoring is going. Are you both enjoying it? Are you learning from it? The thing to keep in mind is, mentorship is about growth. It's absolutely a voluntary thing.
There's no company who can make a mentorship program mandatory. It's important that both parties get something out of it; it has to be a win-win. After a while, it becomes a neutral-neutral, and it takes time to realize.
Then you should ask, “Is there something missing? Can we do it better?” Or should you just say, “It’s time to stop this mentoring relationship. There is nothing wrong, but we don’t need to keep meeting so often.” Then the mentee could look for a mentor in another area.
I've not seen many companies with good mentorship programs and this includes Uber. It's a work in progress, but at least there's something. On the other hand, despite the fact that there's not much structure or best practices, I hear people talk about mentorship all the time, so somehow it’s working.
It means that people really want mentoring and it has real value, but I think companies have a long way to go.
At companies, there are two ways a process can go: from the bottom up, or from the top down. Mentoring has to be voluntary, so neither of them will fully work. It cannot just be fully organic, because you might have some teams where people mentor each other, but it will not spread to other parts of the company. You surely can’t make it mandatory.
The number one thing that helps a lot is tying mentoring into performance. Good mentoring happens in a lot of places, but often it’s left unrecognized. The most obvious place to recognize it is when you have your performance review or promotion conversation. That makes it tangible. If mentoring doesn’t come up there, it turns into a side project some people will do and others won’t.
Companies should figure out what mentoring means to them, and add it to the list of competencies they have. I think a senior should be open to mentoring, so it could be a requirement for them. It works the other way around as well. If you see juniors mentoring others, you should recognize them for going above and beyond.
Managers should be leading by example. It's encouraging when the CEO talks about what mentors they have and who they're mentoring. I think this has helped at Uber as well. I often talk to people about who my mentors and mentees are.
Make sure that even busy people take on mentees. One of my mentors is a CTO, and she has five different mentees. Even some of the busiest people at Uber make time for it, and it trickles down.
The third one is to have some sort of framework to make mentoring easy to discover, especially when you're a big company. Make some way for people to put up their hand and say if they are looking for a mentor or if they are open to mentoring others. You can do this at a company level; make a website where people can sign up.
There are some good initiatives outside companies too. There's a website called CodingCoach.io, and other places where you can sign up as a developer and just say what you’re looking to improve on.
If you're a developer who hasn't mentored yet, but you have a couple years of experience, I recommend starting there as well, because you can do it immediately. You don't need to wait for a company. When you see opportunities to be mentored or to be a mentee, you just have to take the step and say, “Hey, would you mind having a chat and learning about these things?”
I'd like to summarize the key points for mentoring developers.
Don't worry if you've never had a formal mentor. For about 10 years in my career, I didn't think I had a mentor either. Looking back, I realize that I did, but it was intimidating when I first heard about it. In fact, someone reached out to me for mentoring, and I didn't know how to do it, because I didn't think I’d done it before. So, it's totally okay.
I truly believe anyone can use mentorship. I have a mentor right now as well.
Don't be afraid to say to old mentors after a while, “I've learned so much from you, but I feel that improvement is slowing down, so let's catch up less frequently and make it less formal.” At the same point, reach out to other people for mentorship.
When I became a manager, I found myself a mentor. Six months later, my manager, whom I really look up to, told me that he'd never had a mentor himself, and he was kind of jealous of me for having such a great one. He ended up reaching out to my mentor to set up a mentorship as well.
I think of mentorship as just growing faster with the help of someone. So, good luck to everyone!
It’s in a very early stage, but it has to do with mentoring as well.
At some point, I had a large team, about 15 people. Every week, I sat down with them and talked through how they could grow and where they could be better, and I gave some actionable feedback. Eventually, I started giving similar feedback to people facing similar issues. I've been struggling to recommend a book for them about what makes great software developers. It could also help them find areas to improve on, which beats guessing.
So, I’m thinking of writing a book about modern pragmatic software engineering. There are lots of books out there, but I feel the engineering landscape has changed a lot in the past 10 years. Teamwork is a lot more prominent and remote teamwork especially. We have tools like GitHub, Slack, and Google Hangouts. For a software engineer, communication is becoming increasingly important on top of coding.
I want to honestly share my experiences from places like Uber, Skype or Microsoft, and give it as a resource to people.
I've been in the software engineering industry for over a decade. I started working with smaller startups in Hungary. Then, I moved to the UK and worked at JPMorgan, Skype, and also Microsoft at the same time. I moved to Skyscanner, and I’ve been at Uber for the past three years and became a manager.
I joined as a software engineer, and I ended up leading the team I work with, so there are a lot of interesting challenges.
Gergely has returned for another interview on writing a great software engineer resume, and improving the hiring process of big companies!
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀