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.
“We want to know how aligned people are around the new product development strategy. How can we do that?”
A group of senior leaders at a software company asked me this question as I was helping them to prepare for their annual kickoff meeting. They’d just completed a challenging year of development on a new product initiative. While it had generated some impressive results, they recognized that they needed to approach the following year differently. They were bringing the core team of twenty-five or so key contributors – usually distributed across the United States – together for several days to roll out their plans for the new year. They’d brought me in to help plan and facilitate the event. I knew what I needed to do: help them create a shared understanding of the new strategy.
We often describe the impacts of decisions, challenges, and plans in desirable yet vague terms. Projects will “improve communication,” “make us more customer-centric,” or “increase innovation.” This vague language obscures the importance and urgency of these actions. Why they matter here-and-now isn’t clear, so they don’t motivate people and don’t help people make decisions. Perhaps worst of all, vague language hides a lack of alignment by making us think we agree. Avoid these drawbacks by clarifying the impacts you want.
We have done a huge disservice to leaders and managers, as well as teams. There are plenty of people that will say we don’t need managers and leaders. People can lead themselves. While there is an aspect of this that may be true, there are a lot of steps to get close to that idea.
This article will explore what leaders and managers need to do to succeed as they get started with agile or to help teams move from individuals to a team or even a high-performance team. It builds on Agile Leadership Myth #2: Self-Organizing Teams Don’t Need Any Help.
Self-organizing teams do need help. Self-organizing teams are not instant, automatic, or magically created, despite what is often implied. There is a process to become this type of team, and it is rarely, if ever, a straight line. The help they need differs from more traditional directive assignments and task management.
To unravel this myth, we must look at what self-organizing means, what teams and managers experience, and what you can do to shift your help to a more ROI-friendly approach!
