Home » Agile » You may not need a Tech Lead, but others do

About Patrick Kua

Patrick Kua is an author, speaker and consultant who still finds time to code. He works as an active, generalizing specialist at ThoughtWorks and dislikes being put into a box. He is often found leading technical teams, coaching people and organisations in lean and agile methods, sometimes facilitating situations beyond adversity. Patrick is fascinated by elements of learning and continuous improvement, always helping others to develop an enthusiasm for the same.

You may not need a Tech Lead, but others do

Vinicius sent me a tweet about an article he published called We don’t need a Tech Lead in response to an older article of mine, “Do we need a Tech Lead?”

I wanted to respond earlier, but tweets were too restrictive. Here’s my response.

The argument against Tech Leads

The article rebuts the necessity for a Tech Lead with the following points (emphasis author’s, not mine):

  1. Well functioning teams in which people share responsibilities are not rare.
  2. When a team is not functioning well, assigning a tech lead can potentially make it worse.

There are many great points in the article. Some of the points I support such as how sharing responsibilities (also known as effective delegation). Distributing responsibilities can be one way effective teams work. Other points lack essential context such as the title (it depends), while other points lack concrete answers such as how to turn a dysfunctional team into a highly performing team.

Are well-functioning teams rare?

I’ve worked with at least 30 organisations over my career as a consultant, and countless teams, both as a team member (sometimes Tech Lead) and as an observer. I have seen the whole spectrum – from teams who function like a single person/unit to teams with people who simply tolerate sitting next to each other, and where one can’t miss the passive-aggressive behaviours or snide remarks.

The article claims:

that the “tech lead is a workaround – not a root cause solution

and

Tech leads could alleviate the consequences only

Unfortunately the article doesn’t explain how or why the tech lead is a workaround, nor how tech leads alleviate just the consequences.

The article gathered some discussion on Hackernews, and I found some comments particularly interesting.

Let’s take a sample:

  • (gohrt) Trusting that a pair of engineers will always come to an agreement to authoritatively decide the best way forward seems naive to me. Where are these magical people?
  • (vidhar) …we live in reality where lots of teams are not well-functioning some or all of the time, and we still need to get things done even when we don’t have the time, resources or influence to fix the team composition then and there.
  • (ep103) If I had an entire team of my great engineers, my job would be easy. I’d simply delegate my duties to everyone else, and we’d all be nearly equal. I’m jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.
  • (shandor) My experience with other developers is that there is a surprisingly large dev population who would absolutely abhorred if they had to touch any of those things (EDIT: i.e. tech lead responsibilities)
  • (doctor_fact) I have worked on teams of highly competent developers where there was no tech lead. They failed badly…
  • (mattsmith321) It’s been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions.
  • (jt2190) I’ve been on more that one team where no leadership emerged, and in fact, leadership type behavior was passively resisted… These teams (if they can be called that) produced software that had little to no overall design.

Do these sound like well-functioning teams to you? They don’t to me.

Image from David Trawin’s Flickr stream under the Creative Commons licence

Well-functioning teams do exist. However it is clear that not all teams are well-functioning. In my experience, I would even say that really well-functioning teams are less common than dysfunctional, or just functioning teams. For me, the comments are proof enough that well-functioning teams are not everywhere.

It is actually irrelevant if well-performing teams are rare – there are teams that definitely need help! Which leads to the question…

Does assigning a tech lead to a poorly functioning team make it worse?

In my talk, What I wish I knew as a first time Tech Lead, I explain how acts of leadership are amplifiers (can be good or bad). Therefore assigning a bad tech lead to a poorly functioning team will probably make it worse. However I don’t think organisations set out to give teams bad tech leads.

If a team is poorly functioning, what do organisations do? Simply leave the team to stew in its own juices until things are resolved? That’s one option. Doing nothing is a gamble – you depend on someone in the team to take an act of leadership but the question is will they? I’ve seen many teams never resolve the very issues that make them poorly functioning without some form external intervention or assistance.

Most organisations try to solve this by introducing a role who has some authority. It doesn’t necessarily need to be a Tech Lead, but when the core issues are technical in nature, a good Tech Lead can help. A good leader will seek out the core issues that prevent good teamwork, and use their role to find ways to move them towards a well-functioning team. Sometimes this may mean calling meetings, even if the team do not want to have meetings to reach an agreement about how the team handles certain situations, tasks or responsibilities. A good outcome might be an agreed Team Charter or some clarity about who in the team is responsible for what. A team may end up with a model that looks like they do not need a Tech Lead, but it takes an act of leadership to to make that happen.

The wrong analysis?

The article suggests that a full-time Tech Lead introduces risks such as a lack of collective code ownership, decision-making bottlenecks, a single point bus factor, and (reduced) impact on motivation. I have seen teams with and without Tech Leads both suffering from these issues. In my experience, teams without a Tech Lead tend to have more issues with knowledge silos, no cohesive view and less collective code ownership because there is little motivation to optimise for the group and individuals end up optimising for themselves.

The issue is not caused by whether or not teams have a Tech Lead. Rather, these issues are caused by a lack of a technical leadership (behaviour). The Tech Lead role is not a prerequisite for having technical leadership. I have seen teams where strong, passionate individuals will speak up, bring the team together and address these issues – which are acts of leadership. I have also seen dysfunctional teams sit on their hands because individual (job) safety is an issue and these issues go unaddressed.

My conclusion

The article misses the subtle but important point of good technical leadership. A good leader and Tech Lead is not trying to own all of the responsibilities – they are there to make sure they happen. There is nothing worse than expecting everyone is responsible for a task, only to find that no one is responsible for it.

“The greatest leader is not necessarily the one who does the greatest things. (They) are the one that gets the people to do the greatest things.” – Ronald Reagan

The extent to how much individuals in a team can own these responsibilities is a function of the individuals’ interests, skills and experience. It depends!

Asking whether or not teams need a Tech Lead is the wrong question. Better questions to ask include what’s the best way to make sure all of the Tech Lead responsibilities are fulfilled, and what style of leadership does this team need right now.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Spring Interview QnA
  • Multithreading & Concurrency QnA
  • JPA Minibook
  • JVM Troubleshooting Guide
  • Advanced Java
  • Java Interview QnA
  • Java Design Patterns