Great read! What I noticed happens more often was a lack of focus and understanding for the bigger picture. They sometimes lack the clarity, they don’t see the forest from the trees.
Do you keep track of some of the things you and the mentee chatted about? I've had scenarios where I we keep track, but some of the action items we discuss don't get done. I try to be understanding of "I forgot" or "There was a lot going on last week" but I'm also wondering if you have advice on how to find the right balance and how to call it out effectively
level 1 - just mentally and I am ok if either of us forget. If the mentee forgets more or if the problem is more serious then level 2
level 2 - I will put it as a task for them in our 1:1 (internal tool)
level 3 - a document to with written down next steps.
I don't go to level 3 unless there are "ignoring" the suggestions.
Most people want to grow and do the due diligence. So I keep it light.
How to call out?
- Now, I just do it directly (by asking questions). I build a good working relationship with my mentees. They know I care even if I have to give them very critical feedback. I give very actionable suggestions so they don't mind me just asking directly if they did what I asked them to.
Sun Tzu: “If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders ARE clear, and the soldiers nevertheless disobey, then it is the fault of their officers.”
It's great here that Sun Tzu could look at himself and see that even as a great general that he could be susceptible to fault.
In the above article you didn't consider your instruction(s). Maybe the problem goes beyond your current instruction or set of instructions. As developers, our "commands" persist in many files.
In the relationship between the Mentor and Mentee we can't always assume that all/most of the learning will be done by the mentee.
What if their "incompetence" is as a result of your former inability to write clear and easy to maintain code.
Does your code:
- adhere to known style guides and have others battle-tested the code to give you a degree of confidence that it's easy to work with?
- utilise some personal or team inspired ism's that may be non-standard and confusing (to the mentee)?
- lack use of patterns common libraries that would have made your code easier to reason with?
- Do you use linting etc to make sure that the code is consistent?
Have you exhibited any indication that you're open to feedback on the code? Maybe it's time to pay off some tech debt on the code-base and start refactoring. Maybe they're finding it hard to find a way to tell you some issue(s) in the codebase.
It's a great article and I agree with most of what you've written, however by time we get to this point this "mentee" has most likely been tested/quizzed to the n-th degree to hold a seat in most organisations and has some portfolio that they developed themselves hopefully, and maybe experience in other companies.
They're capable of learning, so I believe that your position and belief in the connotations that come along with it is cheating you of your lesson each time you meet one of those "un-coachable" mentees!
I see this in many organisations that blindly copy the mantras of "start-up" advice...
Great read! What I noticed happens more often was a lack of focus and understanding for the bigger picture. They sometimes lack the clarity, they don’t see the forest from the trees.
Great suggestions to understand a mentee’s problem and navigate them in a successful path
Great article, Raviraj.
Do you keep track of some of the things you and the mentee chatted about? I've had scenarios where I we keep track, but some of the action items we discuss don't get done. I try to be understanding of "I forgot" or "There was a lot going on last week" but I'm also wondering if you have advice on how to find the right balance and how to call it out effectively
Thank you!
Yes, I do keep track in different levels.
level 1 - just mentally and I am ok if either of us forget. If the mentee forgets more or if the problem is more serious then level 2
level 2 - I will put it as a task for them in our 1:1 (internal tool)
level 3 - a document to with written down next steps.
I don't go to level 3 unless there are "ignoring" the suggestions.
Most people want to grow and do the due diligence. So I keep it light.
How to call out?
- Now, I just do it directly (by asking questions). I build a good working relationship with my mentees. They know I care even if I have to give them very critical feedback. I give very actionable suggestions so they don't mind me just asking directly if they did what I asked them to.
That makes sense and thanks for the clarification. Love the breakdown.
Always good to know how the pros do it so I appreciate it :D
Sun Tzu: “If words of command are not clear and distinct, if orders are not thoroughly understood, the general is to blame. But if his orders ARE clear, and the soldiers nevertheless disobey, then it is the fault of their officers.”
It's great here that Sun Tzu could look at himself and see that even as a great general that he could be susceptible to fault.
In the above article you didn't consider your instruction(s). Maybe the problem goes beyond your current instruction or set of instructions. As developers, our "commands" persist in many files.
In the relationship between the Mentor and Mentee we can't always assume that all/most of the learning will be done by the mentee.
What if their "incompetence" is as a result of your former inability to write clear and easy to maintain code.
Does your code:
- adhere to known style guides and have others battle-tested the code to give you a degree of confidence that it's easy to work with?
- utilise some personal or team inspired ism's that may be non-standard and confusing (to the mentee)?
- lack use of patterns common libraries that would have made your code easier to reason with?
- Do you use linting etc to make sure that the code is consistent?
Have you exhibited any indication that you're open to feedback on the code? Maybe it's time to pay off some tech debt on the code-base and start refactoring. Maybe they're finding it hard to find a way to tell you some issue(s) in the codebase.
It's a great article and I agree with most of what you've written, however by time we get to this point this "mentee" has most likely been tested/quizzed to the n-th degree to hold a seat in most organisations and has some portfolio that they developed themselves hopefully, and maybe experience in other companies.
They're capable of learning, so I believe that your position and belief in the connotations that come along with it is cheating you of your lesson each time you meet one of those "un-coachable" mentees!
I see this in many organisations that blindly copy the mantras of "start-up" advice...