Teaching autonomy

​Autonomy in the Workplace

​Autonomy is the ability to make decisions and act independently without needing constant direction or approval from others. In most workplaces, this is usually a privilege reserved for only the most senior employees. More junior people can strive for autonomy but frequently spend an extraordinary amount of time justifying and getting permission to follow their instincts. I spent two years selling one big idea in my first career role. It was transformational for me and the company, but I can’t count how many times I failed to sell an idea before that one was a success. This cost-benefit ratio isn’t worth it for many, so we create a workplace culture that rewards the “we-have-always-done-it-this-way” mindset. Because of the prevalence of taking the safe path, many folks early in their career aren’t even aware that there is another choice.

​Setting the Stage

​There is a reason I wrote three articles about creating a safe space before writing about autonomy. Too many organizations have made the price of autonomy far too high, and undoing that damage takes more than just a presentation or an afternoon workshop. Building and maintaining a self-managing team is not a zero-sum game. The amount of autonomy you empower should be proportional to the level of psychological safety your team has established.
 
I want to make one critical point about the rock star—the team’s source of all new ideas. This person is likely the hero I referenced in Collective Accountability and Quality. If you are still working on collective accountability, there is a good chance that your hero can quickly derail your work. They will do this in one of two ways: Passively, by projecting that they are the final arbiter of new ideas; actively, they quickly jump to the end state of an idea and say why it won’t work. I’ll talk about ways to address this in the next section.

How do you know when the stage is set? One of the easiest is conducting periodic anonymous survey asking people to rate their psychological safety on a scale from 1-10 and track it over time. You can also use more subjective measures like meeting participation, retrospectives, and how often new ideas are presented.

​Cultivating an Autonomous Mindset

I promise everyone has ideas about how they want to see things done. For many people, those muscles may have atrophied, and some initial ideas may need some extra time to develop. Here are some techniques I have used to encourage autonomy.
 
Performance Review Goals:
Performance review goals provide tremendous opportunities if you work at an organization that allows performance review goals centered around the individual’s or team’s interests. Encourage (even direct if necessary) everyone to explore novel solutions to existing problems as their goal. Then, set the expectation that the team will all present to each other at the end of the review cycle. Ideally, there is no overlap in the goals, so everyone can own their idea without being compared to anyone else. Not all the results will turn into an actual implementation. Still, it begins to establish everyone as an individual with their ideas and reduces the focus on the team hero. This technique is also very effective in aligning the hero while allowing them to shine when it is their turn to present.
 
Reject the Default Solution:
Rejecting an idea requires a degree of expertise in the team's work, as there is a right and a wrong time to use this approach—the wrong time is when the default solution is the only solution. You can gently reject the default solution by asking, "How would you do this if you were starting from scratch today and didn't have time and budget constraints?" Chances are they won't get exactly what they want, but it will open a dialogue about alternative approaches that could be partially adopted. Watch out for the hero explaining why you can't start from scratch. This exercise may feel like a waste of time and won't be the most efficient use of time. As such, you must ensure you have enough trust that the team will indulge this "ridiculous" question.
 
Ask What Problem We Are Trying to Solve:
Most people want to jump to a solution, especially in software, where we frequently hear things like: "Just add a button on this page at the top." We have conditioned teams to accept that a request that includes the implementation is normal and expected. It is not. A self-managed team will respond by asking what problem we are trying to solve and save the "how" for after that understanding is attained. By focusing on what needs to be accomplished, you invite everyone to share their perspective on what implementations could achieve that goal. The more skills and disciplines you have in the room when asking that question, the better the options you will get. Having differing expertise in the room will also help align the hero, as they probably won't be the loudest voice from every perspective.
 
Mob Programming/Group Work:
Mob Programming is one way to institutionalize the three previous steps. You make the default working method where people from multiple disciplines bring their ideas and find the optimal answer. This takes time. Even if you can jump into mob programming, you will still have to work to establish that deep psychological safety.

​Overcoming Obstacles

​Autonomy is scary for everyone, and there will always be reasons not to do it. Here are some common objections and some techniques that you can use to work around them.
 
Deadlines:
Deadlines are a necessary evil (mostly) and, unfortunately, are the rationale for many bad implementations. Working around deadlines will require you to take the long view. How long depends on the severity and flexibility of the deadline, but they don't necessarily preclude any autonomous thinking. One technique I have used is to once again ask, "How would you do this if you were starting from scratch today and didn't have time and budget constraints?" Take that answer and create a reference solution. Refer to that reference solution every time relevant work is being done and look for solutions that still meet the deadline while moving closer to the reference solution. In some cases, this can require a very long view and a lot of cheerleading on your part.
 
Silence:
Some people may not want to or cannot participate in autonomous thinking within the existing framework. The solution to this is going to be very individualized. If you aren’t already meeting regularly with your team individually, start doing that. Ask questions and listen. In time, most people will share what is holding them back. You will then need to be creative to help find ways for them to use their voice. One big step will likely be recognizing what you have been doing to hold them back. Humility and compassion will go a long way in opening communication channels.

A few years ago, I had a very humbling experience as I was working to develop a self-managing team. I tried to get every team member to participate actively in planning discussions but was frequently met with silence. In what I thought was a moment of exceptional cleverness, I told the team that "silence isn't an answer." Much to my surprise (sarcasm intended), it didn't work. Luckily, I was in communication skills training with my team a month or two later. I learned that almost every team member had a communication style where they needed time to process information before commenting. As soon as the realization hit me, I felt horrible. I shared the story and apologized to my team in front of the people in the training. That moment changed so much for us. I then took the time to give the team time to process. I would even provide them with a heads-up the day before if possible. It was like a light switch flipping. I learned a precious lesson that day.

​Organizational Resistance:
Sometimes, your organization may reject anything but the tried and true. Resistance could be from an old guard that won't cede control, regulatory/governance requirements, or a complete lack of incentive. Unfortunately, there may not be a lot you can do in this case. However, if you are determined to give it a go, find a low-risk/low-threat problem that hasn't risen in importance enough for anyone to do anything about. Come up with a new solution, and if possible, just fix it. If you can't do it and just ask for forgiveness, propose a way to fix it without any negative impacts on the organization. This approach is tough, but with enough perseverance, it might just be possible.

Organizational resistance will probably be the most prevalent obstacle you will encounter. I overcame this in one instance by finding a small area of senior-level support and getting some lenience to try new things. We found some measurable success and transparently shared that success with the rest of the organization. To avoid threatening the other teams, we couched the presentation as "Hey, come see what we have been up to." I would love to say that everyone saw what we were doing and signed up to go all in. We had pockets of interest and a reputation for doing new, innovative, successful things. That was a true win.

​Conclusion

In my opinion, teaching autonomy is the hardest part of cultivating a self-managing team. But when done correctly, this step in building a self-managing team can fundamentally alter the trajectory of your team's careers. They can graduate from being people who execute tasks to people who own a problem and find a solution. I have witnessed one of my self-managing teams run circles around a team twice their size because they understood how to own the problem completely. Perhaps the most rewarding part of that team was the sense of autonomy, and ownership didn't end when I was no longer managing the team. They had internalized this mindset so entirely that when moved to a team that didn't practice this way of working, they kept doing it anyway. They also tried to influence the way the other team worked. I can't imagine a better validation of our approach than that.

<< Collective accountability and quality

​The power of experimentation​ >>