Managing for Autonomy
Autonomous teams are becoming increasingly prevalent in our culture, with 81% of the Fortune 10001 deploying some form of a “self-directed” team model in parts of their organization. As Dan Pink writes in his book Drive, autonomy is one of the key contributors to individual motivation. We all want to have control, rather than feeling like pawns without volition or choice. Behavioral science studies have linked autonomous motivation to greater conceptual mastery, better grades, enhanced persistence, higher productivity, less burn out, and greater levels of psychological well being. With all of those benefits, allowing teams and individuals to have greater autonomy seems like a no-brainer. Much of the technology industry is moving towards autonomy, abandoning if-then style incentives in favor of recognizing outcomes.
In the engineering org at Pluralsight, one of our core values is responsible, autonomous teams. Our autonomous teams, generally composed of a product manager, a UX designer, a DevOps engineer, several software craftsmen and in some cases data science engineers or machine learning engineers, share responsibility for the entire product development process from the discovery phase through production support. Breaking from many traditional management frameworks, managers at Pluralsight opt to provide context and coaching to teams. Teams can then make responsible decisions on priorities and practices, rather than being told what they should be working on, or worse, how they should be working.
The Counterpart to Autonomy
The big question when we talk about autonomy is how do you keep everyone moving in the same direction. That is where alignment comes in to play. Alignment is a clear direction, a unified goal that everyone is rallying around and motivated to achieve.
The Autonomy/Alignment Matrix2
Like so many concepts in the management world, the relationship between alignment and autonomy can be nicely summed up in a quadrant diagram2.
Low Autonomy and Low Alignment
The bottom-left quadrant is an environment with both low autonomy and low alignment. Picture an environment where you aren’t really sure what you are supposed to be doing, but your boss keeps leaning over your shoulder, telling you about a misplaced semicolon on the email you are preparing to send to your boss (ironically to ask him what you should be doing). There are few success metrics for the work but a lot of supervision over how it is done. Completing tasks in the prescribed way is the most important thing, rather than accomplishing an objective.
High Autonomy and Low Alignment
The next, on the bottom-right, is an environment where there are high levels of autonomy, but low alignment. Teams are able to choose their work, pursue areas of interest and work however they like. The teams are creating really amazing innovative things, but when it comes to creating a product for the company, no one is really interested in that drudgery. I picture this as a startup accelerator. Everyone is working on something they really care about, that they believe could change the world, but there is no common thread to bring the products together because they might as well be separate businesses.
Low Autonomy and High Alignment
The top-left environment has high alignment but low autonomy. Most of your friends who hate their jobs work in this kind of environment. In an environment with high alignment but low autonomy, everyone understands clearly what they are supposed to be doing and how they are supposed to be doing it. There is a clear mission and everyone may even value and believe in that vision. The goals are clearly defined, as are the steps to achieve those goals, and any deviation from those steps is poor performance. Employees execute on the instructions they are given rather than allowing them to decide how a task should be done. Workers feel like they aren't trusted and are unable to make an impact.
High Autonomy and High Alignment
I have saved the best for last: an environment with high autonomy and high alignment. In these environments, teams are given a direction, both for the company and for their team and challenged to find ways of achieving outcomes. Teams have the best understanding of the problems that impact their team and are given the decision-making authority to do something about it. Highly aligned, highly empowered autonomous teams are driven to create great work partly because they are given freedom in how they work and what they work on. They own their code throughout its life cycle, and build things that they will be excited to work on.
Managing Without Telling
Many companies have adopted autonomy and alignment values for their teams, but in order to reap the benefits we must teach our leaders to foster these principles on their teams. There are three functions that managers perform in order to support autonomous teams: relating, communicating and empowering.
A manager in an autonomous environment has to move between the team and the broader organization and understand how that team fits into the organizational landscape. An effective manager seeks to relate to the social dynamics within a team by listening and occasionally participating day-to-day. Some of my most valuable days of work are the ones where I set the meetings and tasks aside, and sit with one of the teams I work with, pair programming or mob programming along side them. My intention is not to spy or to make sure they are being productive, but instead to develop a greater empathy for what they are experiencing.
Relating to the team, however, is not the only important task. In engineering, we have a lot of internal customers, including sales, marketing and other product development teams, for whom we are delivering products. Developing relationships and seeking to understand the customers of the development teams is just as valuable as relating with the team itself. By understanding the customers of the development team, a manager can relay business needs to the team that might otherwise be missed, or provide additional context to a request that is made. Building personal relationships with the teams, peers and other organizational partners creates trust and accountability to each other.
Turning Relating to Discovery
Managers of autonomous teams must also seek information from teams, peers, and the rest of the organization. Managers have an opportunity to spend the time developing context around problems that can arise, either on the team or outside of the team in the organization. It is a manager’s responsibility to gather facts and diagnose problems as they occur. Discovery can happen in a variety of forums, whether that is in meetings where new organizational information is surfaced, 1:1s with team members who voice concerns, or just as part of casual conversation. As managers, our role is to gather the information available and to start shaping a more holistic picture of the dependencies on any given team.
While relating with teams, managers are able to get a broader picture of how their team impacts and is impacted by the broader organization. It is the manager’s responsibility to communicate upwards, downwards and laterally, keeping people informed and up to date. My manager always reminds me that even if I feel like I have told someone something, it never hurts to repeat myself if the information is important (is repetition about repetition meta enough?). As managers, we say the same information over and over again to different groups. People hear and interpret that information differently.
Repetition is key.
People want to be informed about what is going on in the rest of the organization, and they need information in order to be successful.
It is important to create structured space for this communication to occur. For individuals, this means having regular 1:1s. For teams, this means being present in key team meetings, like retrospectives, plannings, and standup. I manage multiple teams, so I even created a Slack channel for my teams to make sure I have communicated cross-cutting organizational knowledge to everyone. I have found that if I have a regular cadence for communicating, the communication happens, but if I think “I will mention it next time I see them”, things start to fall through the cracks. I try to create spaces for myself where I will be successful by default.
Communication extends beyond communication to the team or teams managed. The rest of the organization needs to be informed as to what the teams are doing. Meeting with key stakeholders across functional boundaries (e.g. engineering leaders meeting with product leaders regularly) can ensure that roadblocks are anticipated and performance is recognized. Having prescribed spaces for the communication, like recurring sync up meetings or dedicated Slack channels, can start breaking down communication barriers on crowded manager schedules.
One of the hardest things for me to do when I moved in to a management role was to stop answering peoples' questions. I want to be helpful, so if someone from outside of engineering asked me a technical question, I wanted to give them a quick answer. I had to train myself to instead refer them to the team responsible for the information they were seeking. The team has a better context around the response I might give. If a team member asks me how I would approach a people problem, it is easy for me to tell them what I would do, but it is an opportunity to coach them to find a solution in their own way.
We as leaders need to train ourselves to not try to prove what we know but rather to provide information and context and allow our teams to make informed decisions. The team closest to the problem should be able to reach the best solution, and it is our role as managers to trust them to do this. It is also critical for us to convey that we trust the people that we work with. I fall into the trap of assuming that because I have stepped back from a problem, I am creating space for them to solve it, but often that leaves the team in a state of limbo, not knowing if they can move forward. As a manager, I need to be explicit with my team, acknowledging that I see the situation that they are facing, and challenging them to come up with an outcome. No one performs at their best in the face of excessive, unnecessary ambiguity.
A Few Last Words
In an environment with high alignment and high autonomy, managers should spend their time relating, communicating and empowering. That being said, a lot of other functions have to take place in order to make this environment successful, from how we structure teams, to how we structure code to how much we trust each other. Each of these could be, and probably is, a blog post of its own.
As I grow as a manager, I am continuously challenged to think about the impact I have on my team. I have an internal framework to check in on the team health and my own performance in relation to the team. When I think about the team health, I ask myself if they are aligned with the companies mission and do they see see how their day-to-day work drives the companies mission forward? When I think about my own performance, I question if I have spent unstructured time with the team recently, if I have information I haven't shared that could help them make better decisions, and how often I have been the bottleneck for the team in making a decision. Through this framework, I am able to identify weak areas in my own performance in relation to the teams success.
We, as managers, must feel empowered to iterate our practices and behaviors to meet the needs of our teams. We must seek to continuously improve in the pursuit for autonomy with alignment.