Are self-organizing teams better or the same as self-managing teams? What about self-directing teams? Working with teams can be challenging due to change and complexity. So, the idea that we could have self-organizing teams or self-managing teams can sound valuable, scary, or both!
What do these terms mean, and where can they be confusing? Let’s dig into each one.
Have you ever been in a situation where your organization suddenly faces an urgent, high-priority task? If so, you’ve probably heard someone suggest forming a “Tiger Team” to tackle it. It sounds great in theory, right? “A special team of top performers laser-focused on solving the big problem.” But here’s the thing – Tiger Teams often create more problems than they solve. Let’s dive into why this approach can be problematic and explore better alternatives.
Teams rarely have a shortage of complaints. Most teams have plenty of ideas of what’s going wrong and numerous suggestions for addressing them. Noticing what’s getting in the way of great work is a sign of a healthy team. However, they often focus too much on what others can do to remove these obstacles. When teams ignore what they can do themselves, things rarely get better. One of my favorite tools for empowering teams is Circles & Soup.
Conflict is a challenging topic for many people to navigate. It’s a natural part of working together in groups, yet in the midst of it, it can feel terribly dysfunctional. There’s no shortage of ideas about how to work through it, and there are lots of tools available. The choice of what tool to use when can feel overwhelming. How do you know where to get started? One of my to-go methods for engaging with conflict is the Waterline Model.
“We don’t have time for a retrospective. We have ‘real work’ to do.”
How many times have you heard this? It comes up frequently in the classes I teach, I’ve heard it more times than I care to count. It frustrates me, and yet, I understand where it comes from. This issue isn’t limited to retrospectives. One of the challenges that managers, coaches, and consultants face is helping groups and teams to effectively balance productive work with work that builds and sustains their productivity. The key to that is understanding that working on the group’s functioning is also real work.
Some of my most spectacular failures working with teams have come from going deeper than I needed to. One particularly memorable retrospective ended with a product manager declaring, “I’m done talking about my feelings.” (It was not my finest moment.) Yes, organizations are made of people. And yes, work happens inside a container of relationships. But that doesn’t mean every attempt to address a team or organizational problem must be super deep. Choosing the depth at which to intervene is critical for every manager, consultant, and coach.
“What’s the secret to backlog refinement?”
Eighteen pairs of eyes turned to look at me, waiting for my answer to this product manager’s question. I’d spent the last two days with the group working through the challenges they faced using Scrum in their company. We discovered that most of their delivery problems stemmed from the teams not understanding what was needed. They’d identified with the story I’d told about the team that hated Sprint Planning and hit the reset button on their process. They knew they weren’t doing refinement and could see the effect. They wanted to know how to make it work for them.
The team was angry. Every two weeks, they would find themselves five hours into their sprint planning meeting with no end in sight. Every two weeks, it was the same: Their product manager showed up with a pile of requests the team hadn’t seen before – estimated by someone elsewhere in the organization – and wanted to know precisely how many the team could finish in the next iteration. Everyone hated sprint planning. It was stressful, wasteful, and unproductive. Something had to change.
The team was struggling. They were working on an industrial motion control product, porting a legacy code base to a new hardware platform. Parts of the code were decades old, and many of the original developers no longer worked at the company. They kept getting stuck trying to figure out how the code worked and what they needed to do to make it work in the new system. Neither the engineers nor the product manager had visibility into what was taking so long or how to help.
You’re a mid-level manager in a rapidly growing company. Your boss tells you that a new initiative the company has been considering for the last year has finally gotten the go-ahead from the executive team. This initiative is similar to others your company has taken on in the previous few years, but it is different in a few key ways. There’s no playbook for work like this; success will require trying new things and learning from what happens. Your job is to pull together a team that will perform at a high level in challenging circumstances. What do you do?