Mentoring…

I’ve been a software engineer for almost a decade now, and in this journey, the most credit for my success is because of the great mentors I’ve had. During this stint, I’ve picked up some of the better practices I could follow to mentor my mentees as well.

Mentoring is an indirect responsibility, and a learning source for both the parties. Noting down some of the points here, that has been working well for me. I’m an engineer, so some of the practices may/may not apply to you.

I believe in dedicated mentoring. Whoever I am responsible for, I ensure regular 1–1 meets at regular interval (no more than a month).

I try and walk my mentee through this guiding principles, and explain the process. If there’s anything to be added/removed, we discuss and agree upfront (haven’t seen much changes usually).

The Whats…

I divide mentoring in three buckets:

1. Everything tech
2. Execution
3. People

Everything Tech

This is to improve core engineering competency. Be it tech breadth, coding, advance/depth of technologies, languages, knowledge, hands on experiments, etc.

Whatever you should do to improve as an engineer belongs to this bucket. It is important for both mentor and mentee to know the strengths and area of improvements for the mentee. Depending on the level of engineer, I ask some questions to help figure out where does the person stands. Result of this exercise should be a written down note/document with points of strengths and area of improvements for next 6 month/1 year. Yes, noting down is important to have the clarity for both the persona.

Whenever you ask an engineer, what does he wants to improve upon, the answer is mostly from this bucket. It is evident and easy to think on these lines, because this is our bread-and-butter. However, there’s much more to the role than just tech. Let’s dive in the other two.

Execution

Being an excellent engineer, who designs amazing systems architecture, but are impractical is useless in the real world. Building a feasible a required solution is the P0 for any systems. Execution becomes crucial to achieve this.

Everything on feasibility, planning, dividing a fuzzy problem statement into logical releases, estimations, what can be in parallel and what has to be in sequence, etc is all about execution.

To deliver a best quality product in the optimal timelines is the main objective to learn all about execution.

People

Well, it may look like, engineers do the best coding while in zen mode in silos, but, its not all about solution & coding. People skills are also very key to most of the engineers working in teams. Collaborating with your team, juniors/seniors, other team members, product/business counterparts, etc also require you to cultivate a very different set of skills.

Many engineers struggle with this. If you know how to convey your thoughts, how to articulate, the rest of the world becomes easier around you. You can figure out when you’re wrong easily, and you can convey your opinion easily as well; so convincing is no longer a convincing, rather a brainstorming with your peers.

So identify where your mentee stand for people skills, and help him figure out where he could improve upon as well. Similar to others, you can do this exercise also via some questions, and hypothetical/real world scenarios that you’d have encountered during your working relationship.

The Whens…

Now, once I know the strengths from each bucket, and area of improvements, I take one or two as a improvement goal for next 3–6 months depending on the time it would take for that person. It is very important to take a goal that can be practiced. For example, if a company does half yearly planning, taking a planning goal in middle for senior folks might not work out, as the person couldn’t really do anything major to practice. So map the goals with the opportunities coming in next 3–6 months.

The Hows…

Taking a goal just means, that we will be double conscious when we do something about this. For example, if we’ve taken planning as a goal, when we plan, we will reiterate the whole thing to ensure we’ve done best we could. We could do some research on planning as well, and verify if things are done better. This way we may spend slightly more time for the items around goals.

Other areas of improvement, and advancing more on strengths usually becomes continuous activities with some improvements overall.

Mentor may also not always be expert in all areas, it is okay to be vulnerable in front of your mentee. And as a mentor, it is our responsibility to put in some efforts, to learn and help learn.

This way, the person achieves something every quarter, and at the same improve in the other areas as well.

Some of the evergreen books that have helped me and my mentees to become better engineers:

1. Emotional Intelligence
2. What got you here, won’t get you there
3. Some of the articles from Coaching for Leadership
4. Good to Great
5. Whale Done
6. How we communicate
7. Domain Driven Design
8. Designing Data Intensive Applications
9. Java Concurrency in Practice
10. Clean Code
11. Refactoring: Improving the Design of Existing Code
12. Follow some authors like Robert C Martin, Martin Fowler, Mark Richards, …

Summary:

Mentorship is a partnership to learn and boost your skills. Mentor could learn from mentee as well. Typically mentors should be somewhat senior, more experienced/skilful than you are. Finding the mentor, with whom your chemistry fits is also as much important.

Being vulnerable, honest, and putting effort to improve and help improve are the keys to mentorship. Be a good listener, and ask more guiding questions. It’s all about helping each other, and becoming a better engineer!

Be disciplined, Be enthusiastic, Be passionate — Have a Happy Learning…