If you work in any sort of management position or in a team environment, it is very likely you have heard the term "self-organizing" team. This is something that has become a key ingredient in high performing and motivated teams and when I first learned about it it made total sense. However, it is such a high-level concept that I had no idea how to actually go about coaching and encouraging teams to effectively self-organize. After a great deal of research, experimentation, and failure, here is a list of tips that I wish I would have had when I was first getting started.
Why Self-Organizing Teams?
"It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do." - Steve Jobs
To me, this quote really helped clarify the idea behind self-organizing teams. I have worked in organizations where teams wait for their orders to come from above and then grumble when they don't like the orders. They are often afraid to push back for fear of stepping on anyone's toes or because they feel that they will not be listened to. With the amount of time and money it takes to hire good people, this is very wasteful.
Organizations that have embraced the idea of self-organizing teams, such as modern tech companies and the military, understand that the people that are closest to a problem are going to be able to find the best solutions. Whether it is a customer service department, a warehouse, or a battle zone, leaders that are two or three levels removed from the frontlines will not fully understand the nuances of a team's day to day challenges and that will prevent them from being able to come up with ideal solutions for those challenges. Even for larger strategic initiatives that impact an entire company, leaders will still need buy-in and feedback from their teams that are on the ground to make sure that there isn't something that has been missed and to actually do the work of implementing the initiative.
Another big reason for organizations to embraced self-organizing teams is that they can help address the stress, multi-tasking, and micromanagement that eats up many leaders' time and prevents them from focusing on the work that would allow them to have the most impact (rocks vs sand). I have worked with many leaders who, with the best of intentions, would dive into the nitty gritty details of projects and want to help the team whenever they got stuck, but this ended up eating a ton of their time and the strategic initiatives they were also working on never seemed to move forward. If a leader can learn to allow the teams that are closest to problems come up with the solutions for them, they can then look up and better focus on the bigger picture.
Set a Clear Vision and Goals
One of the first things that needs to be in place for teams to start to self-manage are a vision and goals that can serve as guide posts as they are on their journey. Any company or project that comes into existence is trying to solve a problem or answer some sort of question. In a traditional management structure, there are the people that are higher up that come up with the "brilliant" solutions that are passed down to the teams on the lower levels to implement. Although modern organizations are beginning to flip this model and empowering their teams to come up with solutions, those teams still need to know a direction to head in.
In response to these changes, there has been a shift to outcome focused goals and definitions of work. Many companies now use concepts such as User Stories, which define an end goal and motivation for a customer that a feature is meant to help. The User Story format is short and intentionally left open-ended to allow the teams to decide the best way to solve the problem they are presented with.
Regardless of the format, the goals and vision should be clear enough that the team can use them to make decisions without having to ask someone higher up every time a tough choice comes up. A good example of this in action is the idea of sprint goals (a great rundown on writing effective sprint goals can be found here). In Scrum, when a team is starting a new sprint, a goal should be defined for what the purpose of the sprint is and what success would look like if that goal is achieved. During the sprint, if a team member is unsure which task to work on next or someone tries to introduce new work into the sprint, everyone can refer to the sprint goal and ask if what they are doing is helping to accomplish that goal.
When teams are first starting to self-organize, one of the toughest things is knowing how far they can go with what they want to do. For example, if an angry customer calls a company wanting to return a product, can the customer service representative simply refund the order? Send a replacement? If so, does that only apply up to a certain amount before they have to discuss with someone higher up the chain? Another example might be if a salesperson is almost ready to close a deal, but the customer wants a price break due to the size of the order, can they do that without approval? How much of a price break can they give?
In order for team members to be empowered to solve problems, they need to have some boundaries or constraints to work with that are still lenient enough for them to be creative. If they have to run to their managers every time that they are presented with an unexpected situation, time is wasted and everyone feels frustrated and helpless. Whether its sales targets, number of product defects, or a training budget, leadership can set a range that provides an ideal state and a minimum viable state that the team can then combine with a goal or challenge that they have been presented with and start running. To circle back to the examples above, in Tim Ferriss's the Four-Hour Workweek, he talked about how much time he was spending answering questions for the customer service team at his supplement company around customer returns. In order to address this, he told his team that any return that was below a certain amount could be refunded with no questions asked. After that policy was instituted, the amount of questions raised by his team was dramatically reduced.
When team members are ready to jump in and start solving a problem it is very easy to be derailed or discouraged if there is not a high degree of transparency on what the rest of the team is doing. There have been many projects I have been involved in where I wanted to help, but it wasn't clear which tasks would be ok for me to start on, or if someone else was already working on them. I would always do my best to ask, but many times it wasn't clear who had the answer, or the people who could clarify were unavailable so I would end up waiting and then have to remember to ask again when they were available again.
Transparency is also important from an oversight perspective. A team that is working on a difficult project or trying to meet a tight deadline will feel increased stressed when their manager or leadership team regularly ask for progress updates. These repeated questions come from a lack of information and the answers are important so that the leadership team can monitor the situation at a more strategic level and be able to adjust their plans or inform key stakeholders of any changes or risks. As teams increase their level of transparency this will help build more trust that they can manage themselves and allow leadership to work more in a supporting role to get the team any resources or help they need as opposed to becoming micromanagers.
In order to begin facilitating transparency, the key is to keep things simple:
In addition to the items above, here are a few things to keep in mind to help enable transparency beyond the team level and across departments of an organization:
Remove Fear of Failure
One of the biggest obstacles to teams successfully self organizing is a fear of failing on a project or missing an important deadline. When the pressure is on, many organizations will quickly default to old ways of working and jump in when it looks like a project is in trouble and start to micromanage. If this happens, teams will quickly start to lose motivation and they will revert to waiting for instructions as opposed to proactive problem solving. In order to avoid this, organizations need to create an environment where it is ok for an experiment to fail. For newer teams, maybe allow them to work on a project with slightly less visibility or that has more flexibility in when and how it can be delivered. Regardless, the important thing is to reassure team members that they will not be punished for attempting to take action.
Ask Lots of Questions
Even when you are trying to step back and let your team own the work they are doing, there are usually so many tasks involved that is very possible (especially when they are starting out) that something may fall through the cracks. As a servant leader, it is important not to get so far removed or hand's off that you are unable to help your team become aware of any issues that are coming up. One thing I have learned however, is that this doesn't mean that you point everything out to the team or do it for them.
A more effective method is to continuously ask questions. If there is a meeting that was supposed to happen, ask the team if they are still planning to have it. If they say yes, ask if someone is going to send out a meeting invite. If there is a deadline approaching and it doesn't look like something is finished, ask how the team is feeling about the upcoming deadline. At first, I was hesitant to ask questions like these as they seemed really obvious or naggy, but what I quickly realized is that the team would get so deep into their work that these things would slip out of their mind and they would always appreciate the questions to kind of wake them up.
Learning to work with self-organizing teams has been (and continues to be) a tricky, but very rewarding journey. For anyone who has experienced success in their personal or professional lives it can be very difficult to give up control and trust that others on your team will be able to do things effectively without your direction. However, if you want to help your teams build a true sense of ownership and pride over their work and really hit their full potential, it is something you have to learn to do and continuously practice.
If you want to learn more and get some great in-depth tips around building self-organizing teams I definitely recommend reading the book Extreme Ownership by Jocko Willink. The book has a very easy format to follow and provides some very concrete examples of ways to better help your teams. Another great resource is this video from Mike Cohn who is a very well-know voice in the world of Agile development. The video provides many real-world examples and tactics that he used when working with teams who are not used to self-organizing.
What are some things that have helped your teams self-organize more effectively? Any books or other resources that you would recommend?