Building Autonomous Teams

I know that autonomous teams sound scary for a lot of organizations and leaders:

• How do we align those teams?
• How do we know they’re making progress?
• How do we compare them with other teams?

I’ve been working for organizations that were afraid of implementing autonomous teams because they were fearing a lack of control. But why can’t teams control themselves? Why can’t the leadership still get insights on what those teams are doing and be involved in the reasons behind their decisions?

Alright, it’s not easy to build autonomous teams but the benefit is enormous: Highly effective and successful teams. Those teams share 4 characteristics:

1. Compelling Direction

Those teams know what their goals are. The leadership is giving the broader vision and the team is setting their goals based on that. It’s still possible for the organization to check in to see if the team is on the right way, but the team is self steering towards the common goal.

Our teams are setting their goals based on the department’s goals, which are based on our company vision for the next 2 years. We use OKRs (Objectives and Key Results) for setting, tracking and measuring goals. Our leadership team is holding weekly townhalls with the whole organization to communicate the overall strategy and give updates on selected projects to keep ebery alligned.

2. Strong structure

For autonomous teams it’s essential to have all the expertise inside the team. That’s why we build a cross functional teams. For our product development team we often have development, product management, and design in one core team. Some teams need a QA engineer so they add those expertise to the team, others need an analyst, etc.. It doesn’t matter if you have a Triad or Squad. You should have the core competency in your team to react fast.

3. Supportive Context

Your team can’t have all the information in order to be successful. You often need the support of other departments like legal or IT to move forward. This should be as frictionless as possible. Information should be open for everyone in the organization to be discovered and used.

We use a ticket system for every request. Not only for IT requests, but also for design, finance, or if we need to travel to another office and want to book the corporate apartment. We have a service center where we can file all those requests.

The information that we need from other teams are shared openly in our intranet. That way  lot of questions are answered by reading pages or I just add a comment if I didn’t understand everything.

4. Shared Mindset

Sharing the same mindset helps a lot when working together:

• The whole team knows what the goal and the purpose of the project is because we’re sharing a project poster
• Every code change need to be reviewed so we’re spreading the code knowledge in our team
• Designers are sharing their designs and gathering feedback from the team

..and much more. We’re setting the goals together, develop together, reading through feedback together, and course correct together. All this helps us that everyone in the team is on the same page.

Help your team

If you’re coming from a traditional background the idea of having autonomous teams can sound a bit scary, but it works. Those teams are even measuring how they’re doing on their own and course correct. We use a Team Playbook with best practices from other teams to help us improve. Why should you compare teams with each other if each team is doing their best to reach a goal. I’ve never seen a good system to compare team outcome.

If you want to learn more how to build a successful team come to my talk at CTRL in London 31 Oct.  CTRL will run as a track at Microsoft’s Future Decoded event in London on October 31st. The event is free to attend so grab your tickets here