Qualities that make a good programming team lead

Qualities that make a good programming team lead

Recently I have been put in a position where I am responsible for a team of developers and this got me thinking…What makes a good team lead? So I decided to scour the internet and make some of my own points, here they are:

  • When things go bad be prepared to take the heat and resolve the problem. As with all teams mistakes are bound to happen, it’s just a matter of time! But what makes a good lead is someone who can stay calm resolve the problem systematically and then most importantly learn the lesson (ensure this is also communicated to the team). It’s quite easily to also play the blame game, but I think this is destructive in nurturing a team spirit and bad for confidence levels.
  • Lunching together is a great way to get your team to know each other (Create a Lunch Bunch). Socialising between team members is a great way to boost communication in the team and fosters a “I got your back” mentality. Admittedly this won’t work for everyone as some people bring in homemade sandwiches, or prefer to lunch alone. But the ones that do tag along become great team players.
  • Be willing to educate team members. As new developers join the team it will be imperative to train the new member. Personally I think this should always be done by the team lead and perhaps assisted by another dev. This allows the lead to gain an understanding of ability’s and where they can be improved. I also believe it’s important to peer program and walk through all aspects of code/infrastructure rather than pointing to a wiki and providing links.
  • Protecting the team from interruptions and distractions. Currently in our team we work in two week sprint cycles. Previously we have had situations where by people external to the team have asked a developer directly to work on a body of work immediately. This in my mind is a big no no! It upsets the flow of the team, throws the sprint schedule out of line especially when the task has hidden complexity (usually uncovered during a scoring session). All work should be channelled through a scrum master, or product owner and scored before its worked on. When the task is added to the sprint another task with equal complexity should be removed.
  • Understand the bigger picture. It’s important for a lead to continually asses where improvements can be made to process, code, infrastructure and personal development for the team. For the developers in the team this can sometimes be something out of mind as their main focus is around completing tasks, so the lead should always have a to-do list and push to get these scheduled within sprints. These improvements can also lead to a more relaxed  and confident team.
  • Dish out the credit where and when it is due. Just say “good job” every now and then…
  • Be transparent in terms of communication. Filter down information that’s coming from above. Being informed will allow yout team to be prepared for changes.
  • Hire the right people. Personality in my opinion trumps technical skills when hiring. It’s important to hire someone who can work within the team without clashing.