A high-performing team meets or exceeds its clients’ expectations, becomes more effective over time, and helps all members learn and grow. A high-performing team is not merely highly productive; it is anti-fragile. Teams reach high performance through a complex process of development. How can you tell if it is moving along that path or needs a corrective nudge? By monitoring three key team processes.
Why do some teams perform at a high level while others struggle? To be clear, when I talk about a high-performing team, I mean one that is highly productive, continues to improve over time, and develops all of the people who are part of it. Teams are complex systems, so you cannot directly cause a team to perform at a high level or predict with certainty that it will or won’t. You can, however, create conditions that make it more likely a team will develop in the way you hope.
Team performance is an emergent phenomenon. You can’t control it, and attempting to adjust it directly will likely have perverse effects and unintended consequences. As with any complex system, your best option for influencing it is by managing constraints. Instead of thinking about “What do I do to create high-performing teams?” shift to considering, “How do I foster the conditions in which teams are more likely to become high performing?”
“Oh, my teams are definitely high-performing.” I’ve heard this from countless managers in numerous organizations. Sometimes I wondered where they were keeping all the low-performing teams. Understandably, managers responsible for developing teams want to be seen as doing a good job. Isn’t the promise of high performance the reason we form teams? Without a clear definition of what “high performance” means, it’s easy to defend describing many teams with that term. And if a team is already high-performing, they don’t need to get better, right?
Few words in the corporate world are abused and misused more than “team.” All the people who report to the same manager? They must be a team – even though their work doesn’t require them to collaborate. All the people working on a product? They must be a team – even though they all have different objectives and incentives. Most “teams” are collections of people that someone has drawn a somewhat arbitrary line around and said, “You’re a team.” Calling something a team doesn’t make it one. Teams have three essential qualities that set them apart from other collections of people.
Many product teams fall into the trap of fixating on the work they need to do and forgetting about the impact their work is supposed to have. When that happens, the work often doesn’t produce the desired result. When you work as part of a product team, five questions can help you to avoid this trap by re-focusing on the customer problem you are trying to solve – and why.
How did we arrive at this place where so many people believe that self-organizing teams do not need help? The fact is, self-organizing teams DO need help.
What teams can experience: Teams might not know exactly what kind of help they need or even how to describe it. This can be especially true if they had a manager-led team and were told what to do and when to do it. I hear teams say, “we don’t need managers”, but they often mean that they don’t need managers telling them what to do.
What managers can experience: Managers are often put in a position of shifting from being an expert and telling teams what to do to some new approach that is not clear to them. They may not know exactly how to help a self-organizing team. I call this clumsy management. It is not that they are doing it on purpose, they just happen to be bumping into things when trying to help. Managers are sometimes told to “stay out of the team’s way”, so they end up disengaged and not sure how to reengage. The fact that a manager may not be sure how to help a self-organizing team does not mean that help is not needed.
The Pig & Chicken is a cartoon many in the agile community are familiar with. I know some will see it and ask why this one is being rehashed (I know this because I reviewed it with a few people, and they asked). Some will be pretty annoyed since many “strongly dislike” the cartoon (which is fine – please add your comments!). So, for anyone reading this and thinking any of those things, please read on. I want to say, “Don’t worry, I have a plan,” but only you can judge how it pans out for yourself! Tweet the Agile Safari Cartoon!
For readers who are not familiar with agile (or any agile folks who have not seen the cartoon), the ideas is that the pigs are the team (or Scrum Team). The chickens are everyone else.
The most common agile retrospective focus is on the sprint (or iteration) that was just completed. For most agile teams, this is the past two weeks. We have many more options for retrospectives than simply looking back on the last sprint. We can look at a specific topic, an event, use a future focus, or look at a much longer timeline. Regardless of the focus, we are aiming to learn, generate ideas, and (ideally) agree on actions to take moving forward to improve to sustain.
