The idea of self-organizing teams is a strange one with which many traditionally structured organizations struggle. In this article, our own John Krewson makes a strong case for self-organizing teams in Agile organizations.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
As both a trainer and a consultant, I often have to undo some of the things that organizations (and their leaders) think about so-called Agile organizations. When we discuss—as we often do—the role of self-organizing teams, many people hear “management-free teams.” That’s not at all what we mean when we talk about self-organization and self-management.
You may have heard of J. Richard Hackman’s 60-30-10 Rule. Hackman was digging into the elements of what determines team success. His well-documented research breaks down like this: Roughly sixty percent of the variation of team effectiveness is based on the actual design of the team: How the team is selected, how the goal is defined, and the other originating dynamics of the team. Thirty percent comes from how you bring the team together and how they begin to engage with each other. Ten percent is based on the coaching after the team is started.
Managers absolutely have a role in Agile organizations. In fact, managers should see themselves as service providers and partners of self-organizing teams. You will have influence in making proper staffing decisions, for example. Your organizational success is highly dependent on who you bring together.
Self-organization involves moving product direction and strategy into the team’s arena of responsibility. It’s not enough to have technical skills on the team. If your team does not include the authority to decide where to go next, it’s not a truly self-organized team.
Even the most self-directed team is still greatly impacted by oversight. What I see in practice, and as a leader, is that when you align with the real values of agile, your teams will evolve faster and develop skills more efficiently. Taking a backseat and not falling into a “command position” allows your team to decide, for example, how work is allocated.
When teams work together and trust each other, they are able to solve large problems that individuals can’t solve on their own. Self-organizing methodologies satisfy a more effective pathway to deliverables. Placing the right people in the right roles gives the team the autonomy they need to troubleshoot and solve problems.
One common misconception I hear is that teams aren’t going to succeed until the project is more clearly defined.
I mean, if that were true, no team would ever really succeed—ever.
Self-organization thrives when a self-managing team is empowered to structure the roadmap from day one; it’s also naturally occurring phenomena that is more of a characteristic than a strategy. The key ingredient in that self-organizing team is having the right people with the right experience. People whose insights, experiences, and authority lead to emerging clarity.
Self-organization isn’t treated independently from other components of modern work practices. It thrives in an environment that values simplicity, and learning. An Agile environment embraces and even appreciates failure, and prioritizes cross-functionality over siloed functions. Without those, self-organization is useless at best and harmful at worst.
Self-organizing teams aren’t controlled so much as they are enabled. It’s a matter of talent and delegation over dogmatic oversight and control. Remember, your job isn’t to match the right skills to the right person. The initial challenge is assembling the right team. (Self-organization often thrives best when the people being managed have higher technical skills than the manager.) Then, that team will use its collective skills and experience to identify which team member brings what to the table in that specific situation.The rock band is a great example of a self-organized team. True, the drummer mostly plays drums, and the lead singer mostly sings. But sometimes the drummer takes the lead on a ballad (I’m looking at you, Phil Collins). Great rock bands usually have members whose skills traverse the landscape of music skills, so they can put innovative music together.
Here’s the thing: Rock bands have managers. It’s just that the reporting structure is reversed. The rock band hires the manager and provides a service of finding them gigs and engagements that suit the band’s goals. Managers of other domains should take note. What service are you providing to your team?
The “who handles what” question flares up when a team enters a storming or norming state (see Tuckman’s Stages of Team Development). Once the norms of the team have been solidified, this becomes less of an issue. (It’s why we promote team stability.) New teams may gel a little faster, but that still requires patience and clarity from you.
Stability is at the root of all healthy organizations. If team members have lingering uncertainty about one another’s skills, all you have to look forward to is some relatively rotten fruit at the bottom of your tree. If those insecurities aren’t addressed immediately and explicitly, those feelings could quickly morph into resentment and disengagement.
When you confront that uncertainty, you inevitably present the team (and you, as the leader) with choices. Remember: Stability always requires that you provide clarity, insight, and direction. Provide that clarity, confront those misgivings directly and calmly, and do it as soon as it rears its head. As a wise man’s father used to say: Deal with it, change it, or end it. Any IT leader should be prepared to confront and deal with uncertainty.
As soon as it’s clear that someone has been cast in the wrong role, you face two choices: Let the team simmer in resentment, demotivation, and skepticism (and further let them disengage from you as a leader) or embrace the opportunity to change it. Again, in any IT environment, this is a common situation most of us find ourselves in regularly.
So, you’ve discovered the imbalance. You’re ready to change it.
How?
First: Arrive at agreement that the role was miscast. It might be a perception issue. Perhaps the leader has a different, implied role in mind for the person. If that’s the case, it’s the leader’s job to make sure everyone knows what that role is.
If there’s still a problem, you need to figure out what’s driving the miscast. Does that person not share the company’s values? Say, for example, a company really values humor. If humor is at the root of your culture, and this person is just flat unfunny, they’re a miscast. People arrive at odd crossroads all the time in companies with folks when there’s a cultural mismatch. It’s not a judgment on skill. They’re just not a good fit for the company or the team.
Then, ask yourself the question: Do they not have the skills to do the job? That’s another issue entirely. If the skills are there and, in this analogy, if they’re funny: Maybe they just need some training and facilitation. Or maybe they need a mentor. Perhaps it’s as simple as giving them the space to fail safely so that they can learn from mistakes that don’t jeopardize the health of the company.
Here’s my bottom line: If the values all match, they should stay on the team. Structure the team and your relationship with them so you can identify the appropriate issues that are destabilizing the project.
As a leader, you always have to be aware of any obstacles to success and team performance. Identify those destabilizing forces, and cut them down before they take root. Engage the team and welcome their engagement and ideas about how to bring balance back to the force.
Ninety-nine percent of what a good leader does is to provide stability and success by way of transparency and encouragement. I like a good quote and I think this one is relevant here (it’s also a pretty famous one, so forgive me in advance if you’ve seen it in thousands of slide decks).
“The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it.”
—Theodore Roosevelt
A good manager does not get in the way of teams. Management has a huge and different role to play in Agile and uses teams differently to get projects completed. Self-organizing does not mean you fire all the managers. It means that as a group, the people you serve are able to problem-solve when you introduce new problems to them. They’re firmly attached to your servant leadership, and because you give them control over their creativity, they discover new ways to overcome obstacles.
Assemble the right team, inform them of the larger context, and leverage your leadership succinctly as you need it. Sounds about right, doesn’t it?
Easier said than done, right? If you’re ready to learn more about how to bring Agile principles into the workplace, register for our Agile Fundamentals Bootcamp today.