The key to scaling a software engineering organization is stable teams. A while ago I wrote about the need to focus on stable, autonomous teams. Teams with members that trust each other and thereby become more than the sum of their parts. That is, in the end, the ultimate dream of a software development manager: to create cross-functional, self-organizing, high-performance teams. Teams self-organize around a compelling mission and have a big sense of ownership.
The consequence of this is that a lot of focus is on the team instead of the individual members. It is often said in the context of “agile” that you have to forget titles (everyone is “team member”) and forget heroic actions. This is easier said than done. It requires a cultural change and even then you will probably notice huge differences in the performance of your teams.
Not so surprisingly, just putting some random people together and calling it a team is apparently not the solution to everything. Peter Drucker already said it: “Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership.”
So, what does “leadership” mean in the context of agile teams? How do we build strong, high-performing teams?
What makes a team great?
Before we can try to answer these questions we need to explore the factors that distinguish great teams from mediocre teams. Sam Walker actually did this for sports teams in his book “The Captain Class“ (I highly recommend to read it, it’s fun and thought-provoking).
In this book, he sets out to answer one of the most hotly debated questions in sports: what are the greatest teams of all time? He devised a formula, then applied it to thousands of teams from leagues all over the world, from the NBA to the English Premier League to Olympic field hockey. When he was done, he had a list of the sixteen most dominant teams in history. At that point, he became obsessed with another, more complicated question: What did these freak teams have in common?
You would think it depends on the star players, the ones that all fans know and that are basically the public face(s) of the team. Or the coaches, they are often celebrated as the strategic masterminds that brought the big successes. However, as Walker dug into the stories of these freak teams, a pattern emerged: each team had the same type of captain. There is a clear pattern in the dominant periods of these freak teams: they started when a certain person become captain of the team and ended when this person left. Or to say it in other words: there is a strong correlation between the captain and the performance of the teams, stronger than with other factors like the coach, overall talent, and money.
Apparently, what we need in order to build a strong team is a strong leader. But a strong leader might be someone with a different skillset than you expect.
We need to update our view on what makes a great team leader
When we think about a strong leader we have a certain type of person in mind. Brave, steadfast, charismatic, inspirational, talented, the public face of the team. This leader gives speeches to motivate the team just before they need to face their biggest challenges. Speeches that are memorable and inspirational.
However, if you compare the captains of the teams discussed in “The Captain Class” they were quite different. They lacked superstar talent, they weren’t fond of the spotlight, they didn’t lead in the traditional sense, and they even did potentially divisive things. They weren’t the usual suspects, so to say.
These captains did resemble each other, though. Here are the seven things they shared in common (all discussed in detail in “The Captain Class”):
- Extreme doggedness and focus in competition. They leave no doubt that they are giving it everything they’ve got. The team will work harder because of their example (the opposite of “social loafing”).
- Aggressive play that tests the limits of the rules. They do whatever they can to win. They are more concerned with winning than with how the public perceives them. That means they sometimes operate at the edges.
- A willingness to do thankless jobs in the shadows. They are in most cases not the star of the team, they shun attention, they are water carriers. You could call them servant leaders.
- A low-key, practical, and democratic communication style. They do not give speeches. The secret to effective team communication isn’t grandiosity. It’s a stream of chatter that is practical, physical, and consistent.
- Motivates others with passionate nonverbal displays. They intentionally do things (sometimes dramatic, bizarre, or frightening) to ignite passion. The passion of one can elevate the performance of an entire team.
- Strong convictions and the courage to stand apart. They don’t trigger personal conflict, but they dare to communicate uncomfortable truths to defend their teammates against management or to make a practical point of what the team is doing wrong. Not driven by ego but aimed at helping the team play better together.
- Ironclad emotional control. They do not only continue playing through setbacks, they excel. They wall off destructive emotions (negative emotions due to e.g. an injury, a rebuke, a personal tragedy) in order to serve the interests of the team.
These are the seven traits that Sam Walker identified as the commonalities among the captains of the top performing sports teams in history. What can we learn from this in the context of software development?
What does this mean for software teams?
There surely is a trend nowadays to reduce hierarchy by not appointing team leaders. A team only has members, sometimes with different roles, but no explicit leader. In addition, when you research the concept of “leadership” you will be bombarded with all the positive traits that leaders should aspire. This sets an unreachable high bar.
What I like about “The Captain Class” is that it revives the importance of team leadership. It also shows that extremely successful captains (team leads) were not abundantly talented or charismatic. It shows that great team leadership is actually in reach and what to focus on: the seven traits as described above.
When I translate this into the context of software engineering and compare it with my own experience over the last years, I’m getting to these conclusions:
- Don’t take the “all team members are equal” mantra too far. The goal is to create stable teams that work well together and achieve results. Leadership is important to get there.
- Leadership in this context means leaders within your teams. For the daily performance of a team, a coach from the sidelines is less effective than a leader within the team. The right lead within the team will notice much better what happens in the team and how external factors are influencing the team.
- Carefully select the team leads for your teams. People with the traits as mentioned above. People that sometimes coach, sometimes lead by example, and sometimes just bluntly say what’s needed. Don’t be distracted by the loudest voice or the most impressive programming talent if the above traits are not there.
- Don’t be too dogmatic about the definition of the role of Scrum Master. The emphasis often is on coaching, while sometimes leading a team goes beyond that (lead by example). A team lead has a broader responsibility and in my opinion, can have HR responsibilities as well.
What is your take on leading agile teams? How do you scale your engineering organization? Please share!