Team Leadership on Agile Teams

Yesterday, I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team “works.”

I was taken aback by this, partly because of the surprise that two people would say the same thing on the same day, but more so because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me, there is a great pleasure in being challenged on my opinions, especially ones that I was so sure of and have given a lot of thought to.

My Experience

I have worked for other people for more than 25 years and have spent a great deal of time witnessing leadership in action. I have also managed teams myself and have coached quite a few. By a very quick count, I would say that 70-80% of team leads were poor leaders. For sure, there were a few that got the job done by force of will, by leveraging authority, or by imposing death marches on the team. The organization sometimes saw them as successful, but the teams thought them to be more like dictators or bullies.

Many team leads – often insecure at accepting other people’s ideas – simply were unwilling to see or consider any other perspective. But there were a few good or even great leaders who didn’t see management as a tool for control, but as a scaffold for building the team and achieving great things – if only these leaders could be cloned.

So I am probably tainted by my experiences, but the notion of one person in charge of the team fills me with dread. I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases, or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more likely is that those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been colored by my experiences, my colleagues have equally been colored by theirs, but they have had the good fortune to see better leaders than I have. We will also discuss this further and why this is a good approach, and whether my instinctive reaction and poor experiences are in contrast to theirs.

Before proceeding, let’s stop here and reflect for a moment. One quote that comes to mind related to what I have said is the following by Author and Former Nuclear Submarine Commander David Marquet: “Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

Oh Captain

The military is often used as an example of one named leader, but there is a distinction in the military that differs from industry, and that is that they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure.

In a business environment, it is rare that a disagreement is so urgent that it could not be referred up if there was some type of dispute. The other aspect of a military organization is that “life and death” decisions need to be made very quickly; with little time for debate or consensus-seeking.

However, even in military structures, there are examples of leaders who take the view that they are the Product Owners. This means that they will say “this is what I want to achieve, you tell me how” and then suggestions are made, and the leader simply endorses the team’s advice or at least considers it before making a final plan. Naturally, there is an element of accountability, but the trust that this demonstrates in the team is significant in empowering the team and growing it.

This notion is explored more deeply Marquet’s book: Turn this ship around. Let’s take a look at some of the principles outlined in the book.

Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

We Want Conflict and Debate

In software teams, it is often the debate that produces the greatest thinking and best ideas, so stifling the debate is counterproductive to success. Having a single person making decisions smothers debate, it thwarts conversation, and it disempowers the team. If a team is overruled often enough, they will stop making suggestions, and if one person becomes so myopic in their opinions, it can make the team feel powerless and excluded. Also, when there is a defined leader they often have a tendency to lack transparency, as information is selectively shared and this lack of information also impedes debate.

In short, I believe that having a defined leader is in conflict with another Agile principle.

Agile Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Merging “the What” and “the How”

Having the same person responsible for both the what (vision) and the how (implementation) also stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again, this is at conflict with Agile principles, and while you may say that a good leader wouldn’t let this happen, experience and evidence speaks to the contrary. Power corrupts, and if someone has the responsibility and authority, it becomes hard for them not to use it, especially if he or she perceive the team is making a mistake. And if teams are prevented from making mistakes they will stop experimenting.

We Want Balance

Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often than not, a single individual prioritizes one above the other, driving to a deadline, or gold plating a solution. In some instances, any other single aspect usually becomes prioritized at the expense of the rest of the project needs.

I believe that a model based on shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on “the what,” others focused on “the how ” and someone else focused on team improvement and consistency might create conflict (deliberately), but it might also create balance and harmony, and it becomes a catalyst for (great) debate.

We Don’t Want a Silo

If we make one person responsible for the direction, implementation and team growth, we are putting all our eggs in one basket. If this person is on leave, out sick, or leaves the firm, his or her absence can have serious repercussions to the project’s success. There can be so much knowledge tied up in one person that they become indispensable, and of course, this puts all at great risk.

Problems with Shared Leadership

However, I would be remiss not to consider downsides to a shared leadership model. First and foremost, there is a cost. For small teams, it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part-time Product Owners or coaches/scrum masters. It can be a tricky situation when these roles are not officially named, but the responsibilities are shared.

But even then, I would say that calling one person “Lead” or “Manager” can again be destructive. And the notion of combining Coach with Product Owner and implementation into just one named role can lead to dysfunction. In many respects, I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. If the team is too small to warrant the explicit roles, then get rid of named roles entirely. If a team is that small, then naming a leader should be unnecessary and should be self-organized within those boundaries.

This may sound hypocritical, after all, I have spent a good proportion of my career with leader or manager in my job title, but my experiences have been one of an internal conflict in that role. As a Software Development Manager, you become the de facto Product Owner, Project Manager, architect, and team coach.

But there’s often pressure from somewhere, and normally that pressure was to the detriment of the team. In the past, when I challenged it, I did so at personal risk.

Customer and senior management pressure to deliver, cuts costs and drive timelines, which mean that team growth becomes secondary, and team welfare is deprioritized. This leads to making a safe place for teams to learn from mistakes very difficult. Some of that is company culture, but I believe much of that comes from the expectations of responsibility, and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after reflecting on my interaction with my colleagues about having a single person as a team leader, I am even more convinced that a named leader – whether it be a Team lead, tech lead, manager, senior or nerd wrangler – goes against the principles of Agile. While deconstructing that conversation, I believe more than ever that it undermines self-organizing teams and leads to dysfunction and imbalance. There are exceptions, and there are some team leads that are effective, but I wonder if they would be just as effective, or even more so, in a self-organizing team structure. That being said, there are much more examples of ineffective team leads where power corrupts, and they dominate the team, stifle debate and innovation, and disrupt or impede team growth.

In my opinion, the best leadership model is a balance of “What, How and Team Improvement,” and the more people that share those responsibilities, the better. In practical terms, I’d like to see a team with a Product Owner to determine “the what” but a PO who actively engages with the team. A coach that is focused on the team’s improvement and process improvement and the rest of the team is responsible for “the how.” Within the team, there is no need to identify a senior or a leader as the team can work out decision amongst themselves without titles getting in the way. This model may come with a cost, and it may be difficult to get the balance right, but in my experience, this balance leads to the best results.

Ironically, the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeably made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively, why not make that the model from the start?

One Final Thought

I came to adopt an Agile mindset from seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.
To my delight, in most cases, Agile has done that and so much more, in a creative environment like software, the gains of self-organized teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words “lead” or “manager” have no place in job titles on an agile team.