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.
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.
We hear a lot about best practices. We talk a lot about them. Many organizations are of the opinion that if they can identify the best practice, they are set. Of course, that thinking can be limiting in a number of ways. We need to be better, not best.
Googling “best practice definition” gives you “commercial or professional procedures that are accepted or prescribed as being correct or most effective.”
Wikipedia says : “A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. In addition, a “best” practice can evolve to become better as improvements are discovered. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.”
Notice in the Wikipedia definition they add the idea that they can evolve to become better. This gets to the root of what we need to be doing.
I always considered this six question format to be the Baseline Agile Retrospective Format. I say baseline instead of standard because a baseline is something to build on, not an ‘always the way’ standard (I know I’m splitting hairs here).
I believe the six question baseline agile retrospective format is a solid way to teach people how to do an agile retrospective. They can see, relatively clearly, the different parts that should be included. It can be a useful starting point to address additional questions and challenges.
