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.
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.
Most people and organizations want to have an impact. They don’t exert effort for no purpose; they want to accomplish something. Waste – spending time and energy on things that don’t contribute to an outcome you want to create – gets in the way of that. Wasteful activities reduce our personal and organizational effectiveness. Waste comes in many different forms, and one of the most pernicious is task switching.
Your meeting should have a purpose, and everyone in the meeting should agree on what it is.
This is the most common advice that I give people when they ask how to make their meetings more effective. It’s also one of the most powerful.
Many people are working from home at this point and this will obviously continue for a while. Many organizations had already been working remote. I’ve worked on a number of remote teams and with a number of remote organizations well before the current situation we are in. I’ve done remote work as a coach, trainer, product manager, and team member well before the current situation we are in. Each of those instances I found myself enjoying some aspects of the work and also wishing for aspects to be in person. One of the most challenging things to do remotely is to listen.
The history of lean and kanban is a challenge to boil down, so inevitably, I know there are aspects that are missing here. The title says “short” because, while there is a lot of information here, it is short in terms of how more is out there! Additionally, there are often disagreements on certain aspects and points around the history, and we’ve sourced the various elements included in this outline. A key part of understanding kanban is going beyond the principles and practices, to understand what is behind it work. The history points us to a critical key.