The Case for Stable Teams, Part 1
A long-time reader, Al, asked me about jelled teams. What makes a team jell? Would I please write an email about that? This is part 1 of 3 part series about teams.
Often, a manager forms a new team. The team storms as the people establish themselves and their relationships: what each person has to offer and how each person reacts to the politics of the team.
The team norms when the team has agreement and consensus about how they work. Teams can achieve that last stage, performance when they have a shared vision of what the team is supposed to do and how to do it. Often, performing teams don’t need management guidance or interference.
How does a team achieve the nirvana of at least norming? Often, we think of jelled teams as those who are able to norm, to work together successfully.
Sherry was part of a jelled agile team. They didn't get that way overnight. Here's what she said:
“We each had to learn who could do what—some of the developers weren't quite full-stack. One of the testers couldn't automate. But their supposed ‘lack' of skills was offset by their domain expertise. And, we felt safe when we made mistakes. Being able to make mistakes, and recover as a team? That's what allowed us to jell.”
Jelled teams arise when they have complementary functional skills, deep domain expertise, and psychological safety. (See Hiring Geeks That Fit for a full discussion of these skills. See Four Dimensions of Technical Skill for a quick introduction.) Team members need all three to jell.
- The team members know they can depend on the other people.
- They trust each other to use their functional skills to create a product with meaning and impact.
- The team has psychological safety. The team—as a team—makes their own choices about how to manage and perform their work.
These might not be the only criteria for your jelled team. These are the minimum criteria.
When the team works together, solving product problems and delivering value, they can jell. And, if they know that the team will stay together over time, they can build their safety.
When teams know that they will stay together, they invest in each other. They are willing to provide each other feedback and coaching. They are willing to help each other learn and succeed.
The longer it takes a team to be able to solve problems together, the more the team needs to be stable. For example, if it takes a team in your organization six months to develop their ability to deliver value, that team needs to be stable. The more often that team loses team members or gains team members, the more the team has to relearn how to work together.
Not all teams need to be stable. In part 2 (in about 10 days), I’ll discuss the case against stable teams.
All three posts:
- The Case for Stable Teams, Part 1
- The Case Against Stable Teams, Part 2
- The Manager's Role in Creating Effective Teams, Part 3
Early Announcement of Johanna's New Book
I have finished the writing and editing for Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.
Every project and every team is unique. Your agile approach should reflect your uniqueness. And, yes, I have a chapter on teams and the interpersonal skills a team needs to be able to be a jelled team.
New to the Pragmatic Manager?
Are you new to the Pragmatic Manager newsletter? See previous issues.
Here are links you might find useful:
* My Books
* Workshops I offer
* Coaching
* Managing Product Development Blog
* Create an Adaptable Life
If you like the idea of romance between smart technical women and just-as-interesting men, I’m starting to write romance in my spare (!) time. See Johanna’s Fiction.
Till next time,
Johanna