This article emphasizes the crucial role of a team leader as a coach and mentor to their team. I provide clear examples of different scenarios and draw attention to the critical differences between the “coach” and “fixer” mindsets that leaders can adopt. While this guidance applies to other management and leadership positions, I specifically focus on the role of team leads in software development teams.
The Scenario: You’re the team lead
Let’s set up the scenario:
- You’re a lead on a web development team, and one of the junior developers has been working on some code.
- It’s time to check their progress in more depth.
- The code they wrote after a few days is okay but could use some improvements, such as adding more tests or matching the code style, or there could be a significant architectural improvement.
- The junior developer is waiting for you to see how much rework they must do.
Are you a fixer? Or a coach?
If your first reaction is to jump in and fix their code, then you might be a fixer. A fixer is a manager or leader who wants to fix things to meet their high standards.
Jill Geisler discusses this in her article, “Are you a coach or a fixer?” and says, “Fixing is a temporary solution to an ongoing issue. Your employee or staff isn’t really learning when you fix. If anything, they are learning to rely on you to upgrade things to your satisfaction, while not growing their own skills.”
For example, in our scenario, the junior developer must remember to follow the naming conventions of the project. When you’re a fixer, you’ll fix their code to match the naming conventions. The junior developer will have learned nothing from this and will not develop the proper habits. They will come to rely on you to fix their naming convention problems in the future.
As a team leader, you must move away from the fixer mentality and into a coaching mentality. When coaching, you are developing someone’s skills and knowledge so that they can become more developed as a person and as a team member. On a software development team, you train your team to become better programmers. You are training your team to rely less on you by internalizing the right things to do.
Let’s return to our scenario.
You choose not to be a fixer; you step away from your keyboard and walk over to the junior developer. You get into the coaching mindset, sit beside the junior developer, and pull up the code on the screen. You walk through a few spots you think need work and ask them questions about the code.
Your goal is to lead them to find the better solutions for themselves and to figure out what improvements can be made. You lead them with a question such as, “have you considered an alternative approach?” Another good question is, “what was your thought process when writing this part of the code?”
And just like that, the junior developer has started gaining the skills needed to become more mature and capable.
A coaching mindset leads to skill acquisition. A fixer mindset leads to stress.
The best teams, whether sports teams or software development teams, have coaches. Coaching your team is far more effective than simply fixing their problems. One of the coaching bonuses is that you’ll feel less frustrated and less stressed. Team leaders can apply coaching skills daily and see their teams grow as developers and people.