During our careers, almost everyone has regular one-on-one meetings, sometimes referred to as performance reviews. There we take time to go through our past, present, and future in the context of our jobs. In Futurice, these are called MyRetros, where my supervisor and I specifically look back on the last six months, the current state, and possible future endeavours.
Often it's not enough to have a minimum of two one-on-ones per year. Given that our supervisors may have many people under their supervision, it's essential that we also grow each other in a peer-to-peer fashion.
I'm happy to have been mentored by several experienced developers during my career. Still, I'm even more delighted to take that knowledge and pass it on to my mentees. Too often, we might think that advancing in our careers requires supreme technical understanding gained only through decades of hard work. Equally important is our set of soft skills and our capability to grow others.
We should set clear expectations during our performance reviews to not be promoted unless we have grown others. Our careers should have more meaning than plainly satisfying our egos and boosting our monthly salaries.
In the last couple of years, I've been actively transforming myself from a regular software developer to a mentor developer. It is challenging, but doing so keeps the spark lit, giving me a direction to progress.
In this post, I explain how you can transform yourself too.
Mentoring can sometimes be seen as a very formal relationship where you have to be a genuine senior staff member before mentoring juniors.
What is often missing from the picture is that we can also mentor each other irrelevant of our current titles. Everyone who has been a part of multiple teams knows what techniques have worked in particular contexts and can carry that wisdom to future projects.
A crucial aspect of mentoring is to understand that it is not unidirectional teaching and preaching. As mentors, we must learn and improve based on the feedback we receive from our mentees. I find the traditional division of junior and senior employees holding us back, especially in mentoring.
I've worked with seniors who have struggled with fundamentals and worked with juniors who have expanded my thinking with much more efficient solutions. In a sense, we are all juniors, but let's call ourselves people for the sake of equality.
Like our business models should not be strictly about business-to-consumer or business-to-business, our learning should not be from seniors to juniors, but peer-to-peer.
When you practice mentoring as part of your daily team routine, you end up levelling your team's competency. As a result, wide knowledge gaps occur more rarely, which is facilitated by continuous knowledge sharing.
Your design-oriented frontend developer should be able to help with databases and securing backends. Respectively, the developer handling DevOps tasks should be able to help with sketching new user interfaces. Everyone in the team should be comfortable talking to the client, bringing forth new ideas and challenging the old ways of working.
Furthermore, levelling the team helps to reduce the bus factor. The project doesn't halt when the integration specialist gets sick or when the business director burns out and is set aside for a couple of months. Thus, we need to build a team of solid generalists – also known as T-shaped professionals.
The desired side-effect of levelling the competencies is increased autonomy. When people are comfortable working in a generalist mindset, they feel a greater sense of freedom regarding what tasks they can pick. As I mentioned in my earlier blog post, autonomy leads to mastery which leads to finding our purpose. The three elements together significantly boost the retention and desire to work in your company.
Mentoring begins from the very first moment I meet someone. Interviews are a great place to practice mentoring.
If a developer is applying to your company either for a full-time position or a summer gig, I can mentor them. How could they improve their cover letter or resume? Did we give them a homework assignment? How could they improve their solution? As a bare minimum, I must give them a thorough code review in return.
When the new employee is hired, I can become a mentor for them. In Futurice, we have the concept of FutuBuddies, and we are the first ones who welcome the new employees into the house on their first day. From there on, we can agree to meet daily or weekly for a catch-up session which is naturally mentoring.
Being a good mentor is a lifelong challenge to which there are no simple answers. We can, however, define techniques every good mentor should possess in their belt. Below are six strategies I've learned to be effective.
Let's imagine a situation where a new developer approaches me with the idea of rewriting a codebase with another language. Say, for example, they want to switch from Python to Golang or from Java to Kotlin.
Chances are they have been only thinking it through themselves without proper feedback, and the cost of unnecessary codebase rewrite might be high. As a mentor, I don't shoot down unprepared initiatives. Instead, I encourage them to think more. What if the developer would organise a workshop on the said language? How could this developer mentor the rest of the team to solve domain problems using the new language more efficiently?
I have always enjoyed recognising the process bottlenecks in my vicinity and trying to optimise them. Unfortunately, some of my ideas have been shot and even ridiculed in public channels in the far past. People have stated that it couldn't possibly work the way I have imagined. While the others might have had a grain of truth in their words, their approach was not encouraging.
Luckily, I was born with a strong head and resilience (what in Finland we call sisu), so the mental damage has been minimal. However, for others, aggressive approaches might even end up terminating promising careers.
As a mentor, I must always keep in mind reciprocity from social psychology.
"As a social construct, reciprocity means that in response to friendly actions, people are frequently much nicer and much more cooperative than predicted by the self-interest model; conversely, in response to hostile actions they are frequently much more nasty and even brutal."
Wonder why that co-worker has been ignoring you or acting offensively? It might be what you did to them in the past.
Sometimes mentees approach with simple questions. Instead of doing their homework and spoon-feeding answers, mentors ask follow-up questions.
- Where is the documentation located? Where have you looked? Who have you asked?
- How can I make my code cleaner? Do you see any repeating patterns that could be abstracted to a shared function or library?
- Niko is writing crappy code, and it's killing me! What are you going to do about it? How can I help to solve this problem without firing Niko?
As you level up in your career, one of the most rewarding sensations is your increased ability to take on new challenges without feeling like an impostor. The more difficult task at hand, the more confident you are in your ability to tackle it faster and better than others.
It's not a surprise that mentors do not act like this. Instead of reserving the juiciest tasks to themselves and letting the team do mundane stuff, they delegate. Successful leaders take pride in watching their team complete challenging tasks while staying in the background and occasionally offering help. An approach like this requires rigour, but in the end, you have made your team an unstoppable value delivery machine.
It's also important to delegate responsibilities. Don't be the only one talking to the client. Let Alex book, prepare and handle the next demo. Let Emma guide the next sprint retro the way they feel would be necessary right now.
Many discussions between mentors and mentees follow the pattern of mentees explaining their situation and mentors asking questions. What's crucial and may often be missed is for mentors to share their experience as well.
Does your mentee have a difficult time focusing on work due to a personal life crisis? Try to share some of your experiences and how you overcame them – without belittling their experiences. While interviewing a candidate, make the event more relaxed by sharing how anxious you too were in one of your first interviews. Sharing is caring.
We all work under specific rules. Particular rules like reporting our hours for invoicing or delivering work on time are self-explanatory. There are also many invisible rules – conventions – which could help your team further.
For version control, small atomic commits and conventional commit messages ensure the codebase history is linear and easier to follow. For quality, test-driven development rules us to write only so much code that our tests pass. For faster delivery, continuous integration rules us to push our work into a shared main branch daily.
As mentors, we set clear rules on how the team works effectively.
Finally, the shiniest gem of them all is co-creation patterns. It makes me sad to see how many developers like to work things independently, even in the office. Outdated management views further incentivise solo work. Some managers think that people working on many simultaneous tasks is somehow more effective.
In truth, we should voraciously swarm to solve problems. We are already doing this early on in the design phase when we co-create with tools like Google Docs, Sketch, and Miro. When it comes to coding, we tend to split tasks as far as possible and let people pick their favourites to work.
As mentors, we understand that our team is a cohesive unit and not a random bunch of individuals. Lead by example. Always be ready to pair with different people in your team. Experiment and gather feedback regarding what worked and who enjoyed it. Rotate pairs and iterate.
Mentoring is an effective way of getting to know our co-workers. To give meaningful feedback and advice, we should have established a relationship with the other person. Do we know what our mentees are interested in and what goals they have for their career?
As a mentor, I can inspire these interests and goals myself. Suppose I'm practising clean code and extreme programming principles in a team and continuously showing how I build quality while delivering remarkable results on time. In that case, others will surely follow me with interest and attempt to learn. They can be set off to a great path of software craftsmanship.
Naturally, as human beings, everything we speak of doesn't have to be professional. After a weekend, I can mind the team member who had to take their cat to a vet on Friday. How is the cat doing now? Continuously showing interest in people's lives helps gain trust and respect, which goes a long way in helping you work better as a team.
Finally, here is a non-exhaustive list of traits that matter when developing yourself as a mentor.
- Knowledge. What experience and skills do you possess. How extensive is your professional background?
- Authority. Who are you? Why should people listen to you? Do other people know what you have achieved?
- Confidence. How confidently can you express your ideas and solutions?
- Charisma. What kind of body language do you use? How does your voice sound?
- Emotional Intelligence. How easy it is for people to trust you. How well can you empathise with others? How deeply can you collaborate?
- Team reputation. How successful your team and its members are in the eyes of the organisation and client?
- Thought leadership. Are you a recognised blogger or speaker? Are people lining up to work with you?
Keep calm and carry on mentoring!
Photo by John Schnobrich on Unsplash.