3 REASONS A TEAM LEAD SHOULDN’T CODE – AND 11 ALTERNATIVES

A team lead, should she lead the 15 minute daily standup and then start coding for the rest of the day? I am of course exaggerating but it seems like it has become quite common to have team leads for software development teams be leaders for roughly half the time and take up coding for the rest of the time. Sometimes, we see a request for a team lead that the person should also be a technical leader.

Mind that what we are talking about is not team leads that does not know development or programming, just simply team leads that have focused their energy into leadership instead of coding.

Often, the thinking behind this is that there is not enough leadership tasks to fill a full time role and the major other task for the team is coding so then this is what the person should combine her work with and thus something the person should excel at.

The problems

But there are multiple problems with combining team leadership with coding. I will go through 3 of the ones I have encountered.

Problem #1: Low skill overlap

Do not confuse a tech lead with a team lead. The set of skills needed for team leading (handling complex people and process issues) and coding (handling complicated technical issues), overlaps too little, so by focusing too much on getting an awesome coder you are limiting yourself to mediocre team leads.

And of course vice versa – which becomes a real problem in companies which defaults to promoting the best coder to the team lead as a standard career ladder way of increasing responsibilities.

Problem #2: No leadership when you need it the most

When under pressure, and be honest most projects end up in there from time to time, the team lead will counterproductively stop leading and only crunch out code. Then, when under pressure, our ability to handle complexity decreases and we start equating being efficient with being busy (coding). With no person leading, we will all lose the big picture when we need it the most.

Problem #3: Loss of perspectives

If you build a team where everyone has the same technical background you will crunch out code very efficiently. But the risk is that it won’t be effective – as in solving it the customer’s problem. To be able to work effectively in a complex environment you need a lot of different perspectives. And by only having team leads with the same technical background as the developers you miss out of an opportunity to get new perspectives into the team.

The alternatives

Depending on the size of the team and the complexity surrounding them, I would argue that letting a great team lead actually lead 100% is the best use of her time. Leading is definitely not just holding a 15 minute a day stand up meeting. But even if, for example, the Scrum ceremonies does not take up 100% time there are a lot of other leadership tasks to do. Here are a few examples:

  1. Leading community of practices
  2. Driving change outside of the team
  3. Coaching individuals
  4. Training new team leads
  5. Coordinating pre-studies
  6. Leading a second team

But even if we are not in a situation which warrants a full time leader, I would still argue that she should not be coding on the critical line. As a servant leader, there are many other development tasks that a team lead can do such as. Here are just a few:

  1. Document reviews
  2. Code reviews
  3. Manual testing
  4. Automating manual tests & other processes
  5. Guiding the team in slicing large work into smaller batches

All above without risking being placed on the critical line.

My call to action to you the reader is to figure out how you are using and selecting your team leads. Are you choosing the best developer or the best leader? And even if the latter, are you using them for what they are best at?