When I started my professional journey as a software developer, I had the impression that asking questions was a sign of weakness and that “good developers” are the ones that figure out the answer by themselves and don’t ask others. I couldn’t have been more wrong. However it’s good that I figured out quite early that the professional world does not work really like that. In fact nowadays I understand that the impression I had actually says the very opposite about a developer.
Before we get into the mentoring details let me give you some background of my current situation. A couple of months ago my current employer went through a restructure of the engineering team. This is where I found myself working on a new product with a fresh new team. Let’s refer to it as product B. The good thing was that before that restructure I had worked on product A which would be a sister product of product B. Both products had many things in common and also used many similar backend pieces.
When we started introducing the new team members to what we had to do I instantly felt that I had to share my experiences with the product A backend as the setup was slightly different than the rest of the company’s product. It originally took me a while to learn my way around it and did not want to let other go through the same process. Nevertheless, the rest of the team really appreciated the fact that I helped to make it easier for them to understand what is going on. That ended up being a smooth onboarding for everyone. 🎉
As my Frontend skills are better than my Backend ones but and also knew my way around both products I then started being more involved into taking this young product and add it to the standard deployment pipeline we use across the business. This is where I worked with the devops and SRE team to make that happen. I learned a lot of things about Docker and dealing with the it works on my machine issue.
It was clear to everyone that I was really involved into these products and a few weeks later I was assigned to lead the frontend team on delivering product B. This is where I started being closer to the product owner and also to the backend team lead of these products. Even though the deadline was quite tight, I felt like we had to introduce some good habits so that we do not do things in a rush that we will regret later. Before acting on anything it was important to see if the rest of the team was onboard with this plan.
The team consisted of different levels developers and a QA engineer. To make sure we all were on the same page we started introducing more regular catchups for pair programming, discussing code and knowledge shares about things we learned and new ideas. I wanted this team to be quite interactive. The point I was trying to make did not in any way mean “I’m the boss you do what I say”. I really wanted to apply the idea of inspiration and influence which also helped me grow earlier on in my career.
What ended up happening was that every time someone from team was struggling with something the team mates would be there to help. As long as the person had already done some research on the topic but still hasn’t found anything, we would then jump on a quick call, share screens and go through the problem together. That approach not only helped the rest of the team be more comfortable around everyone but it also let them express their frustrations which in some cases was enough for them to realise where the problem is without me saying a single word. After a point everyone realised that asking for help was not them being lazy or not good enough but a sign of strength as the team member had a strong bond and could count on each other. It is important to mention that all of this happened during the COVID-19 lockdown which also showed that people do not need to be next to each other physically in order to solve problems together.
The most important aspect of being a mentor is trust. Trust is not forced upon someone but instead it is something that needs to be earned. It is good to mention that when mentoring, it does not mean that you have an answer to everything. More specifically I found myself many time Googling things that I knew but wanted to a) confirm that what I knew was right and b) double check that I was not spreading misinformation. I remember from my uni days where we had to read papers about scientific methods etc, they mentioned that widening your knowledge on something includes several stages. That starts with reading about a topic, studying it, then teaching it and finally applying a research on it. These academics definitely know something more about this topic.
Once this trust was earned, the next step was to start introducing the good habits I initially wanted everyone in the team to have. Such habits would be good for both the product where quality would improve and also for the developers who would learned some new skills. Some of these included: