Code is just the beginning. Welcome to the rest of your journey.

Does your team need a Tech Lead?

Tech Leads come by many names and in many forms. You may know them as the Team Lead, Lead Developer, or as a responsibility connected to another title such as Technical Architect. Typically they are responsible for the code that your team writes, ensuring it is clean, well written and maintainable for the future. They may do this through mentoring, pair programming, code reviews, katas & dojos among other things.

This varying nature of the role and title of Tech Lead often creates issues however. There is a problem with job titles in general in our industry - often being awarded as a means of recognition with no meaningful change in role - but the Tech Lead seems to embody this more than other roles. I once encountered an individual with the job title of Team Lead who did nothing of the sort but rather spent their time looking after the holiday rota.

The Tech Lead usually has all or some of the following responsibilities:

• Liasing with other teams
• Code quality and processes
• Technical vision, bigger picture
• Involvement in planning and story writing
• Leadership and Mentoring

This is by no means an exhaustive list (and of course every team is different) but typically a diverse portfolio of skills are required, some technical, some personal and some creative.

"Finding a person who has all the right characteristics in your organisation is pretty difficult, let alone within your actual team."

We don't always end up giving the job to the right person either. Bestowing the title of Team lead can be used by organisations as a means to promote individuals, and give them a sense of responsibility. There are only a limited number of team lead positions however so inevitably it becomes a kind of 'first come first served' and this means some people get overlooked - particularly those that are new to the team.

In fact, finding a person who has all the right characteristics in your organisation is pretty difficult, let alone within your actual team. Hiring a new tech lead externally has it's own pitfalls - not least the matter of gaining acceptance and respect from existing members - and then it's still unlikely you'll be able to find even a sensible compromise.

Usually in this situation we just kind of muddle along, but a team I was part of recently decided to reject the notion that the Tech Lead has to be one person, and instead opted for a model we called the Federated Tech Lead.

Instead of appointing a single individual, responsibilities were shared out amongst other members of the team. Responsibilities were listed out and members of the team invited to volunteer, or suggest others that may be a good fit. In our case this was done during a retrospective so as to maximise inclusion and transparency. It allowed us to optimise the various roles according to individual skills and it turned out to be a very eye opening and empowering process.

"Instead of appointing a single individual, responsibilities were shared out amongst other members of the team."

The Federated Tech Lead approach has many benefits:

• There's no sudden upset in the (ideally flat) structure of the team due to promotion of a single individual.
• It's much easier to locate the right set of skills if you don't have to find them all in one person.
• When given the choice, people with the right skills tend to self select and this makes the process even easier.
• Those without current skills but the capacity to develop them can be included in the process as well.
• If someone happens to go off on holiday the handover and resulting skills gap is much smaller
• The reward and satisfaction of increased responsibility can be shared throughout the team.

It should come as no surprise that empowering individuals leads to a more productive and functioning team. However there are still trade-offs to be made. What works well for one team doesn't automatically work well for another and any suggestions about structuring teams should be adapted to your own particular scenario. Flat structures work well for some teams while others require a strong sense of leadership and authority.

If your team falls into the latter group you need to ensure this direction is still present if you decide to federate your Tech Lead. I must stress that although this approach worked well for us it isn't a one size fits all solution. The product we were working on was not particularly coding heavy and involved a lot of ops and infrastructure work. It was also involved work that was ongoing rather than something that was intended to be finished by a certain time.

"What works well for one team doesn't automatically work well for another and any suggestions about structuring teams should be adapted to your own particular scenario."

This isn't a new approach, but it's certainly one I've found to be useful. By dividing up the responsibilities that usually fall to one individual we can solve many of the problems caused by the traditional Tech Lead structure, particularly with regards to finding the right skills. It can also promote a flat structure and a democratic environment, but most importantly, it helps build that vital level of trust required for a successful team... and that has to be worth a crack.

Have you adopted a similar approach or been thinking about doing so? Post your experiences in the comments, I'd love to hear them.