Those who know me know that I have never been in favor of the Team Lead role. Though before, I used to think that the negative connotation of this role was more of a leadership style and that it can be trained and adapted.
We all know that the style of leadership can vary. But my current belief is that if you have a built-in role of a Team Lead within a team, then the culture will eventually follow the structure. Meaning, that the power figure of a Team Lead will likely prevail over the other team members, leaving them powerless and victimized.
Me as a Team Lead
I remember being assigned a Team Lead role at my first paid job, back in 2001-2003. That happened because I had been earlier in that project and I had learned some things about the domain, the clients and the code. So I was given several developers to lead.
Some decisions I made were not too bad, actually. I did introduce Continuous Integration and Unit Testing. But looking back, I can totally see how limiting for the team and too controlling I was.
I can feel nothing but shame now when I remember telling off a bright developer for doing refactoring that had been long overdue. Why did I do that? Not because I didn't want better code. Neither because I wanted to do it myself. No. But I felt scared with the changes he was introducing. I thought they could break the code badly and delay the delivery, which I felt solely responsible for.
I felt insecure and helpless. I felt an urge to control what the other developer was doing for otherwise, he would ruin everything and my career too. The level of responsibility that was put on me (or did I worsen it myself over time?) was too much - I was unable to act proactively and openly.
I was preventing the necessary changes. I was not leading - I was blocking.
... 20 years later, I know I was probably a bit too young for that role. But on the other hand - doesn't my behavior as a Team Lead form a recognizable pattern that we can see in numerous places these days? Do you recognize yourself or your Team Lead in that story?
Responsibility put on a single person eventually leads to that person becoming overloaded and stressed. And that can result in various dysfunctions. Playing safe and reactive is just one of those possibilities that I, personally, experienced. Others can exert different behaviors under the stress of too many expectations from them. But one pattern stands above all - the level of command and control of other increases over time. Thus sucking out responsibility out of the team.
And this becomes a vicious cycle, a self-fulfilling prophecy. The team stops acting, waiting for its leader to act, and the leader has nothing to do but to act because (s)he sees no proactivity from the team. Months and years pass and all you've got is an overly exhausted individual trying to micromanage a bunch of demotivated individuals. That's a tough job and a sad way of being.
It doesn't have to be this way. We can do so much better! But first, we need to understand how we created these dynamics.
Good Intentions. Bad dynamics
Note how introducing a Team Lead (or a similar role within a team) always starts with good intentions:
"Let's have someone senior in the team to make sure the team makes the right decisions".
"Instead of having the entire team spend their time on clarifying that requirement, let's just have the Team Lead look at that".
"We need to make sure that junior developers don't contribute with bad code, so let's have the Team Lead review the pull requests".
No one has ever been fired for stating these or similar proposals. They make sense. They are logical. Furthermore, they also resemble other companies that we saw or worked in.
And yet, these are these proposals that lead to the negative dynamics we've just discussed above. Introduction of a special senior role (no matter how you call it) will likely lead to limiting the flow of work and the growth of the team. That's just how the system's bottlenecks function.
"Show me a specialist and I show you a bottleneck!" - as my fellow LeSS coach and a good friend, Greg Hutchings puts it. And a Team Lead becomes a hell of a specialist over time.
Introduce Engineering Managers Instead
The more I work with great companies these days, the more I observe this pattern: a Team Lead role got abandoned, and an Engineering Manager is introduced instead with a focus on long-term engineering prosperity. In practice, meaning that an Engineering Manager works with several teams and in a cross-functional way.
One can say that this is just "scaling" of the Team Lead role. But no. This creates entirely different dynamics:
#1 Your teams are free from the dictatorship of any kind
Teams are now just teams. No roles, no power games. Flat and proactive as defined in Scrum. All decisions that require the entire team will be made by the entire team. And if some processes require just a team representative (or two), those representatives likely will rotate and never result in forming "special" people. There are no special people. There are just brilliantly equal team members radiating with the potential to act freely when needed.
#2 Product Management leads the teams
We want people to be led, not told what to do. The presence of a business-minded person (e.g. Product Owner in Scrum) who works with a team on a daily basis can raise enough awareness for everyone to know the direction and act accordingly. We don't need another leader to digest, simplify and fence the team from the real world. We can finally start treating people as adults.
#3 Focus on long-term growth
An Engineering Manager should work with several teams, not just one. This way, we minimize the ability of this person to know all the details and then try to micromanage. This person can still be involved in development activities and short-term goals. But not full-time. And not for the sake of deliveries.
The mission of an Engineering Manager shall be to grow the capacity of teams. To make engineering great again.
Below is an example of a job description of an Engineering Manager at Gusto:
Hire, lead and grow a team of diverse engineering talent
Build and foster an inclusive, collaborative, and high-performance culture
Collaborate with our data science, operations, product management and design teams to lead and own developing end to end product experiences for complex customer needs from initial planning, execution, to final delivery
Work closely with Leadership to help set priorities for both short-term and long-term roadmaps
This is the company where Kent Beck works as an Engineering Manager (as of 2022). And he writes a lot about this role, his mission, and leadership duties.
#3 Code with the Teams
We want Engineering Managers to be ... engineers. Not HR specialists or life coaches.
We always wanted more experience engineers to pass their knowledge to others. Team Leads were an attempt to achieve that, but with bad consequences. Now, the Engineering Managers, devoid of these shortcomings, can do the right thing right.
Engineering Managers shall be following the "Go Gemba" approach of Lean Managers and code with teams, from time to time, joining feature development. But never alone! Rather, with pair programming or yet better with (remote) mob programming techniques.
#4 Engineering Managers as Scrum Masters?
I might sound heretical to some people now... But if you follow this article's line of thinking, then the Engineering Managers' mission and scope of work will somewhat overlap with the ones of a Scrum Master. My experience shows 80% overlap or more.
So, do we need both? An Engineering Manager and a Scrum Master for a group of teams? You can choose. Those two can form a powerful leadership team to coach and grow the engineering processes in an organization.
Poster POS (a Ukrainian SaaS for food services and retail businesses) made this change in the summer of 2021. They removed the role of a Team Lead from the teams and picked a few most trusted engineers who were also interested in improving the production system long-term by mentoring others. Back then, I played the role of a Large-Scale Scrum Coach and a temporary Scrum Master in Poster. Together with the Engineering Managers, we formed a team and lead the changes.
Once I moved out of the company, the Scrum Master position was not filled in. And instead, the Engineering Managers became the Scrum Masters.
What also helped was that quite a few team members were trained in facilitation. So they could run the events without relying solely on the Scrum Masters. That made the job of an Engineering Manager / Scrum Master slightly easier.
Extract Leads out of the Teams
There are options. You will see what works better... But what you need to do first is to extract the leads out of your teams!