How to mentor effectively?
I was recently promoted to Senior Software Engineer and am new to mentoring. I've been coaching a mentee who tends to jump into coding without fully considering the trade-offs of his approaches. Despite my instructions to align with me on a planning document before starting, he began working immediately after sending it, without waiting for my approval. He often focuses narrowly on solving problems, missing the broader implications and potential risks, which can lead to inefficient efforts and time wasted chasing incorrect solutions. He is energetic and quick to code, but this sometimes leads to tunnel vision.
In mentoring him, I've employed a Socratic method to prompt deeper thinking about his strategies, but he struggles with creative critical thinking and often reverts to the initial problem or gets bogged down in details instead of evaluating the overall correctness of his approach. I think part of the issue is that I'm not directing his energy efficiently. Perhaps instead of asking him to get alignment with me first, I should give him a clearly defined problem where he understands the steps and approach, while I ask him to come up with solutions for other issues. This would allow him to have a pipeline of tasks he can switch between while waiting for asynchronous feedback from me.
To improve his critical thinking, I've tried encouraging him to brainstorm more about the potential consequences and risks of his approaches. However, he often misses the mark with his strategy—it's not completely wrong, but he doesn't consider the long-term implications, focusing instead on quick fixes. I wonder if I should meet him where he is, doing more of the strategic thinking myself and providing him with the steps and approach so he can focus on execution, which he is motivated by. Alternatively, there may be room for him to develop better brainstorming skills, and I may need to adjust my expectations and provide more targeted guidance to help him think more broadly about the problems he tackles.
Discussion
(1 comment)- 0
2 months agoMentor Coach for SWEs | Former Staff Software engineerThis is an interesting problem to have!
Since you mentioned "quick to code" and "quick fixes" a couple of times, have you tried to dig into why he wants to solve things so quickly? I am wondering if he misunderstands the incentives!
Sometimes, people incorrectly pick up cues that skew their understanding of incentives. Is velocity highly rewarded in your team or the larger engineering culture at all costs? Do engineers tend to be fast and loose with quality and not mind accruing tech debt? Does he want to impress you with his quick turnaround time? Is he impatient in waiting for your feedback?
Some of the approaches you are applying can be more effective if you could dig into what's actually driving his behavior. This will also help you become a better mentor because you will help people uncover their unconscious habit patterns and address them in addition to providing tactical suggestions. The change you bring about will result in a lasting transformation in your mentees.
As for tactical suggestions, have you considered giving him a set of questions in writing? I'd try writing down the questions around consequences, risks, and other strategic aspects that you'd like him to consider. Ask him to write down his answers in return and have a working agreement that he wouldn't begin coding until the two of you have discussed the answers.
Writing down his answers will force him to think more clearly than in his rushed, discursive thought. If this approach is successful, he will start seeing patterns in the questions you ask and his answers, which can teach him to think strategically through practicum. Since you're officially mentoring him, you can also ask him to find common patterns among the written notes after you've done this exercise with him a couple of times.
Your idea to give him some well-defined problems along with a strategic task is also a good one. He will be able to scratch his coding itch and keep showing progress.
