On my team at work we have an underperforming junior software engineer. He does not have discipline, is not meeting the expectations we have of someone of his skill level, and is not improving despite numerous interventions and talks.
Personally, I feel for the guy. I see a lot of myself in him from earlier in my career when I was experiencing imposter syndrome and struggling with knowing even what to do.
Recently we've been talking about how to tackle this, and are considering putting him under a closer mentoring scheme. Not to micro manage him, but to check up on him a few times a day to keep him on the right track and guide him, as he isn't so great at managing himself.
Hn has been an excellent source of wisdom for me in my career so I'm hoping you can help me help us help him in his. Since he is young and relatively inexperienced, we'd much prefer to take the route of helping him than firing him.
Any advice, or links to other threads or articles would be massively appreciated. Many thanks HN.
- Sometimes underperformance can stem from a lack of engagement because of a disconnect between the work they would like to do, and the work they've been given. In this instance you could try giving them a wider variety of tasks and see if they prosper in anything else.
- You could also change the level of work given to them. If it's too easy or repetitive, this can often cause people to switch off and lose discipline. On the other hand, if it's too hard they get overwhelmed and don't know what to do. If this is the case, then mentoring is the right approach, but only if the level of work is just beyond their abilities. If you give them something miles out of their league, no amount of mentoring is going to get them over the line.
- Something I've tried when I was in your position is to enforce tighter standards in the CI pipeline (test coverage, manual testing notes, linting etc.) to enforce discipline before they push code which forces them to fix their own issues before seeking a review.
- Try getting them more involved in code reviews. Reviews are a skill that should be taught just as much as writing code, and poking holes in other people's code might prompt them to do so on their own. Reviews are also a great opportunity for senior devs to perform mentoring asynchronously - long form explanations on why a design choice was made in a git diff for e.g. and sharing that across the team.
- Finally, they could just be outright negligent, but I'm assuming this is not the case with you. If they're resistant to taking advice and improving, then this might already be a lost battle.
Good luck!