All excellent tips, Raviraj. I'm a self-taught mentor, and I wish someone told me these sooner. I'm guilty of making the 2) mistake early in my mentoring.
I figured the cause for that, so I would add a 6) Not building confidence.
I have to work on this because I felt that sometimes people were afraid of communicating if they were stuck because they had ideas about where they should be and things like that.
Very insightful article indeed. I wanted to share in case there is a better approach out there. I had struggle with a developer who doesn’t test their work, late on delivery, bugs from past work interrupted current work and so on. At first I helped her navigate requirements, put guard rails to test the work but nothing worked.
I did this next thing and it is on going and give it some time. Since I noticed the QA person had a better hold on the requirements so now I paired her with that QA person. I am thinking that blurry requirements (in developer head) are the root cause of the developer behavior.
Maybe your assessment is right. Typically I have observed - lack of motivation, direction and connection(to the problem) are the reason for slacking work. Pairing with someone motivated and can provide the right support on the ground can help.
ncredibly insightful, Raviraj , your approach to coaching engineers to be effective mentors is truly commendable. The clear distinction between the mentor's role and your role as their coach provides a solid framework for growth. Your emphasis on customized support, care, and fostering a bond between mentors and mentees is spot-on. The attention to detail in your 1:1 discussions to ensure mentors are genuinely engaged and providing direct feedback is a game-changer. Navigating the delicate balance between hands-off and hands-on mentoring is a skill you've clearly mastered. Congratulations on the milestone of 10K subscribers – a testament to the value your content brings to the engineering and leadership community!
I fully agree with not giving the solution but allowing for "struggle time".
Something I'm trying is to help/teach by example. I share the mechanisms I used or that I'm using in the situations that overlap between me and my new grad mentee. (In my case, it's not mentoring about mentoring but mentoring about engineering. But same principle applies)
For example, we both share:
- Joining a new team -> He joined my last team, I moved teams 1 month ago
- How to be a good mentee -> He has me as a mentor, and I have a Senior engineer as a mentor
Sharing openly what I do helps on this part of giving the tools, not stepping in and solving the problem.
All excellent tips, Raviraj. I'm a self-taught mentor, and I wish someone told me these sooner. I'm guilty of making the 2) mistake early in my mentoring.
I figured the cause for that, so I would add a 6) Not building confidence.
I have to work on this because I felt that sometimes people were afraid of communicating if they were stuck because they had ideas about where they should be and things like that.
Good addition, Akos!
Very insightful article indeed. I wanted to share in case there is a better approach out there. I had struggle with a developer who doesn’t test their work, late on delivery, bugs from past work interrupted current work and so on. At first I helped her navigate requirements, put guard rails to test the work but nothing worked.
I did this next thing and it is on going and give it some time. Since I noticed the QA person had a better hold on the requirements so now I paired her with that QA person. I am thinking that blurry requirements (in developer head) are the root cause of the developer behavior.
Maybe your assessment is right. Typically I have observed - lack of motivation, direction and connection(to the problem) are the reason for slacking work. Pairing with someone motivated and can provide the right support on the ground can help.
ncredibly insightful, Raviraj , your approach to coaching engineers to be effective mentors is truly commendable. The clear distinction between the mentor's role and your role as their coach provides a solid framework for growth. Your emphasis on customized support, care, and fostering a bond between mentors and mentees is spot-on. The attention to detail in your 1:1 discussions to ensure mentors are genuinely engaged and providing direct feedback is a game-changer. Navigating the delicate balance between hands-off and hands-on mentoring is a skill you've clearly mastered. Congratulations on the milestone of 10K subscribers – a testament to the value your content brings to the engineering and leadership community!
Thank you! Truly appreciate it.
I fully agree with not giving the solution but allowing for "struggle time".
Something I'm trying is to help/teach by example. I share the mechanisms I used or that I'm using in the situations that overlap between me and my new grad mentee. (In my case, it's not mentoring about mentoring but mentoring about engineering. But same principle applies)
For example, we both share:
- Joining a new team -> He joined my last team, I moved teams 1 month ago
- How to be a good mentee -> He has me as a mentor, and I have a Senior engineer as a mentor
Sharing openly what I do helps on this part of giving the tools, not stepping in and solving the problem.
Nice article and great visuals, Raviraj!
Thanks Fran!