Elastic Leadership or How to Be a Better Team Leader

First time I heard about the Elastic Leadership, where the leadership changes based on the three team phases, was in March 2011 during QCon in London . I knew the speaker Roy Osherove already because of his book “The Art Of Unit Testing”. However this time he gave a talk with the title “Team Leadership in the Age of Agile” as a part of the „Software Craftsmanship“ track. Roy talked about things I’ve felt or even done already, but they were not transparent to me. He gave those things the names. At the end of the Session Roy played guitar and the whole audience was simply delighted. Me too.

From this day forward I decided to follow up the activities of Roy at his 5whys.com homepage. His idea about the Elastic Leadership got matured and my personal experiences I’ve collected during last months have confirmed he was right! So let’s explain shortly what the Elastic Leadership is and how it suits to the agile software development.

The Roy’s main idea behind the Elastic Leadership is based on the realization that the role of the team leader is not to solve the team’s problems. If you do so, the only person who learns is the team leader and additionally having the control over all topics, caused the team leader to be a bottleneck.

The role of the team leader is to get the team grow. If you grow people the value delivered by the team grows and additionally the commitment of the team to work effectively and efficiently grows as well. Your team is motivated internally, loyal and happy.

The role of the team leader is to get the team grow.

To grow the team, the team leader has to help the team members to learn, to acquire new skills. And because my definition of Agile says “Agile is about learning”, this type of the leadership suits ideally to the needs of the agile software development.

I fully agree with Roy that if you as a team leader want your team to learn, you have to challenge it, challenge the team members to solve their problems on their own. Agile frameworks like Scrum have this challenge in focus due to their empirical pillars knows as transparency, inspection and adaption.

Roy points out however that sometimes this way of leadership named “challenge to grow” might not be the perfect solution. Sometimes the team leader has to take the control, make hard decisions and decide for and not with the team. On the other side sometimes the team has to be left alone, because the guys know what they are doing. Regardless if you are already a team leader or if you are just a team member I suppose you do agree with these observations.

These three leadership styles can be named, according to the Roy’s definition as a command and control style (I name it commander style), coach style and facilitator style. As a commander you are the decider, you tell people what to do. As a coach you are challenging the team to solve its own problems, teaching the team members how to make decisions and how to be self-organizing. As a facilitator you make sure that the project environment delivers everything the team needs to get project done.

There are three leadership styles: command and control style (or commander style), the coach style and the facilitator style.

However, the question is how to recognize which leadership style is right? Do you have to change the leadership style, and if so what are the conditions to do it and when? The foundations for the answer on these questions are so called “three team phases” a team can belong to: the chaos phase, the learning phase and the self-organizing phase. Depending on the team phase, the team leader has to change the leadership style he or she uses. And that is the core of the idea. Elastic, adaptable or I would simply say, agile way of leadership, where the leadership style changes depending on the phase of the team.

There are three team phases: the chaos phase, the learning phase and the self-organizing phase.
Depending on the team phase, the team leader has to change the leadership style he or she uses.

According to the Elastic Leadership, a team is in the chaos phase if it has not enough time to learn. The main goal of the team leader in such situation is to get the team out of this phase by creating so called slack time. This time the team needs to focus on learning. It is quite obvious that in this phase the most appropriate style of leadership is the commander style.

If a team is in the learning phase it means it learns to solve its own problems. The team is still not self-organizing (it learns to solve) but it has enough time to learn and experiment. In this phase the team leader should change the leadership style from commander to the coach style.

The team leader’s goal should be always to get the team into self-organizing phase. In this phase the team knows what and how to do, the members have proper skills to solve their problems, they are able to experiment and evaluate on their own. The leadership style should be changed into facilitator style.

What is additionally important is the pace of leadership style changes. Roy defines two assets their changes can force the team leader to change the way he or she leads the team: team skills/knowledge and the amount of slack time (I would prefer to call it schedule). So any changes to the team structure, any changes in the scope of the project that requires additional knowledge or any changes to the schedule that impact time the team has to learn could cause the change of the team’s phase, thus change to the leadership style. And we know how our projects are, such changes can happen every day.

The Elastic Leadership is a great tool and I’d like you to convince you to use it in your projects. Roy has written a great book about his concept “From Chaos to Self Organization – Growing Effective Software Teams”, that can be found at his 5whys.com .

As a final comment I want to let you know that the Elastic Leadership is a first citizen in my Lead Framework (Lead = learn to adapt) I’m working currently on. It addresses topics missed in the most agile software development frameworks and consists of subjects like agile leadership, agile culture, agile capabilities, agile laws, and so on. I will write an independent blog entry about the Lead Framework soon. Stay tuned.