Autonomy? You Can’t Handle Autonomy!
Principles for Leading Software Teams: Part VI
I have just one topic left in my series on Principles for Leading Software Teams, but it’s a big one. Really, it seems to be three entangled ideas. That’s made it hard to figure out how to attack writing about it. I can sum it up this way: autonomy is good; orchestration is bad; hierarchy breeds dysfunction. You might be able to argue that one implies another, but I think they can each stand alone. Rather than agonize over it, I’m going to take my own advice and just plow ahead on the journey. Let’s start with autonomy. Why is autonomy good, and what should I do about it?
Why Is Autonomy Good?
In my experience, most people get it. We know we crave autonomy, and we know it motivates us. If that’s you, feel free to skip ahead. For the sake of completeness, though, I’ll lay out a bit of supportive information. Entire books have been written on the topic; I’m just going to cherry-pick a few things that I find interesting.
Speaking of entire books, let’s start with Drive. Dan Pink makes the case that the three most important ingredients of motivation are autonomy, mastery, and purpose. What does Pink mean when he says autonomy? Employees having control “…over the four T’s: their task, their time, their technique, and their team.” That feels like a pretty solid definition, but I would add one thing. I believe autonomy also means that you have both the ability and authority to achieve your intended goal. I sometimes put it this way: you’re in control of your own destiny. Pink explicitly draws a line with this saying that autonomy and independence are different. He makes the case that you can be autonomous and happily interdependent. I agree, but that interdependence has to be of your own choosing for you to truly be autonomous (more to say on that later).
As a real-world example of autonomy and its impact, Google has notoriously built a culture of autonomy that they refer to as “high-freedom”. As Laszlo Bock elaborates in Work Rules!, “Google isn’t the first to do so. For over sixty-five years, 3M has offered its employees 15 percent of their time to explore: ‘A core belief of 3M is that creativity needs freedom. That’s why, since about 1948, we’ve encouraged our employees to spend 15% of their working time on their own projects’” (emphasis added).
Team Topologies points out that, “…research indicates that enforcing standardization upon teams actually reduces learning and experimentation, leading to poorer solution choices.” It makes sense, but that’s a level of technical autonomy that I have found to be pretty rare in the industry. Similar sentiments from Creativity, Inc.: “…I strongly believe that smaller groups within the larger whole should be allowed to differentiate themselves and operate according to their own rules…” One of the things I like about this approach is that it allows for experimentation and learning while exposing the organization to less risk: only one team is impacted by a bad idea–not the entire company.
(Note that I just shifted from individual autonomy to team autonomy, but I think that’s reasonable given that “…the team [is] the indivisible, atomic unit that can do work within an organization.”)
Team Topologies and Creativity, Inc. are simply making a tangible point about a broader, more abstract economic concept: permissionless innovation. There’s a great discussion about it on this EconTalk episode. The basic point is that minimizing bureaucracy, and allowing people/businesses to create autonomously (that is, without having to seek permission) leads to a thriving economy. Ever hear the expression, “It’s easier to ask forgiveness than it is to get permission”? If you give that episode a listen, you’ll learn that it has a name: Hopper’s Law. It’s named after Grace Hopper who was a rear admiral in the navy and a software developer (of course!). I find it fascinating and telling that a military leader would choose to signal to her entire chain of command that it would be better to just act rather than try to get permission. Likely she was attempting to unleash the creativity and productivity of her team by granting them autonomy.
Another interesting example from a different EconTalk episode involves in-home nursing care. It is common in the Netherlands to try to get people out of the hospital and into their homes as quickly as possible because people recover better from home. Historically, it had been a bureaucratic and centrally standardized program. To improve it, they decided to peel off the administrative part of the work and automate it, and they left the implementation of the patient care at the discretion of the nurse: “Do what you think is right. You’re a nurse; use your judgment.” Giving that kind of autonomy to the nurses decreased the cost of nursing care by 30% because patients got better in half the time.
As a final thought, I’ll make a simple emotional appeal. Don’t you hate it when you’ve been given a chunk of work to do and every step you take is second guessed? That’s at the top of my list of demotivators, yet so many managers seem to think that’s their job: making sure their employees are doing things the “right” way.
Now What?
So maybe you didn’t need convincing, or maybe you’re convinced. Now what? In my experience, people talk a good game about autonomy, but they don’t do a great job putting it into practice.
When you’re planning to build software, do you create a big project plan that has a bunch of inter-team dependencies? Then you’re hampering autonomy. From Accelerate: “The goal is for your architecture to support the ability of teams to get their work done–from design through to deployment–without requiring high-bandwidth communication between teams.” Team Topologies refers to this type of team as a “stream-aligned team”. We have a rule in our department: “no dependencies”. If you find yourself thinking you have a dependency, then you need to understand why. If it’s because arbitrary boundaries have been created, tear those down. One of the greatest advances in our industry came when we removed the wall between development and operations giving rise to DevOps culture. No longer were developers at the mercy of an operations group to get their software deployed. It increased autonomy and therefore productivity–not to mention the improved incentive structure (i.e., I’m going to be careful because I’m responsible for this if I break it).
Recall that Pink says that being able to choose your team is an ingredient of autonomy. My organization has a few habits in place to help with this. First, we do our best to involve future teammates in the interview process, and we take their feedback seriously. If any of them are not a thumbs up, we don’t make an offer, and the hiring manager can’t override. Second, we very rarely just assign any kind of working relationship (team or otherwise). We always take employee preference as the most important factor. To facilitate experimenting with new teammates, we have a concept we call a “tour of duty”. Want to spend some time on another team? Just ask.
What about autonomy in what we work on (“task” as Pink would put it)? One way we try to accommodate this is by having a variety of things to choose from when a team is ready to pull in new work. Unfortunately, we can’t always offer a lot of variety. Many companies offer some notion of “20% time” to allow for autonomy of task. We don’t. Task autonomy is probably the area where my organization has the most room for improvement. Like I said, it’s easy to talk about autonomy but sometimes difficult to achieve.
I do my best to have clear rules of authority that allow people to act without getting hung up on gatekeepers and red tape. One example: the owner of the pull request is the “captain of the ship”. Others are able to try to influence, but in the end, the owner makes the decision. (If that seems confusing or untenable, feel free to post a comment/question below). This is similar to Pixar’s “Braintrust” exercise as described in Creativity Inc. Get a bunch of smart people into a room to candidly critique an early iteration of a movie, but in the end the Director decides what he/she will and won’t use. So refreshing. I don’t know how many times I had to bring designs before tribunals that had the authority (both explicit and implicit) to force me to accommodate their input. People in those settings are often motivated to exert their authority for the wrong reasons and you’re left with a design-by-committee mess.
We have our own incarnation of the Braintrust exercise. Anyone can pull together a larger group of engineers to share a technical solution/approach. The idea is to get as much criticism as possible. In the end, the person that convened the Braintrust decides how to handle the feedback. Managers don’t attend.
What does being a manager look like in your company? Does the manager have a clear scope of authority and mission, or is he/she just a placeholder in an org chart to keep a “healthy” ratio of manager to employee? Don’t fall for it; that’s the opposite of autonomy. At times in my career, I have had more than thirty direct reports without it becoming unmanageable. It’s not just me; Bryan Cantrill has some pretty strong thoughts on flat orgs.
You might be imagining, “Not everyone craves autonomy. I know people that just want to be told what to do.” A couple of thoughts on this. First, in my experience, most of those people really haven’t found vocations they are passionate about. Help them find something they have passion to do. Those people will be happier, and you have the chance to find a replacement that is passionate about the work. Second, having those kinds of people forces orchestration with you as the orchestrator. You want to avoid that (more on that in a future essay).
Even so, there’s work to do in this regard as a manager. Many people aren’t accustomed to autonomy and don’t understand the responsibility that comes with it. There’s a classic HBR article that makes this point very well: “Management Time: Who’s Got the Monkey?” Briefly, it’s common for a first time manager to think it’s his job to resolve problems brought to him by an employee, i.e., pick up the monkey. Soon the manager is busy wrangling all kinds of monkeys and everyone is waiting on the manager. A good manager will deflect those monkeys and leverage the autonomy of the employee to care for his/her own monkey. That’s harder work for the employee, but will result in a better outcome. As a manager, there is hard work in growing a culture where employees care for their own needs.
Because of this, I’m not a fan of “servant leadership”. If you think it’s your job to serve your employees, you become the bottleneck. In fairness, I think advocates of servant leadership would say I’m misunderstanding the point. Perhaps, but I know that early in my management career, that idea seemed very appealing and noble to me. I imagined, “I’m not somehow superior to my employees”, and I tried hard to “serve” them. I just ended up making myself miserable and frustrating my employees. Generally speaking, they will serve their own needs much better than I can. If they can’t, then it’s my job to understand why. Does this person just need to be coached into owning his/her autonomy, or is there something in the system that would enable that person to serve his/her own needs.
The HBR article is specific to the manager/employee relationship, but the concept can be applied to peer relationships as well. People often try to get peers to pick up their monkeys. Teaching people to artfully avoid this will improve team dynamics and interactions. If someone truly wants to hand off a piece of work and create a dependency, that person needs to understand the implications. For autonomy to be maintained, you’re giving up the right to demand, second-guess, and complain. If you want it done a certain way and within a certain time, you should do the work yourself. If you don’t know how, figure it out. Wouldn’t you rather be in control of your own destiny? Or maybe you prefer putting your success into the hands of others? Maybe that’s a little over-stated. As Pink said, we can be happily interdependent, we just need to be careful not to undermine someone else’s autonomy when we create that dependence.
Teach people in your organization to tune out the noise that surrounds them. People will try to guilt you into owning their monkeys. Take action because you think you should as a part of your accountabilities and responsibilities in service of your objectives. Don’t do it because you think others want you to; that way madness lies. (Those of us that are a little anxious/neurotic can imagine all kinds of things that we think others want us to do. People pleasing is an endless treadmill.)
This is a little bit controversial, but I think this concept applies to career growth as well. No one can own your career better than you–not even your manager. Unfortunately, managers are often told this is a very important part of their jobs. If your career growth is important to you, why would you outsource it to your manager? Don’t get me wrong: managers should definitely be helpful when asked and certainly coach as it makes sense, but the employee has to own it. If you’re not getting the growth out of your career that you want, you should be doing something about it rather than blaming others. Managers should do what they can to create an environment where employees can own their careers.
Goals
There you go: autonomy. What can it achieve in your organization? It draws out productivity because it creates intrinsic motivation. It breeds innovation because it makes space to harness the creativity of every individual in the organization. Finally, it allows for failure without risking the entire organization, making each failure an opportunity to learn from, which results in antifragility.
It’s often seen as a one way grant: the organization allows autonomy. But as we’ve seen here, it requires a lot of those to whom it has been granted.
What do you think? I said some pretty edgy stuff. Share your thoughts below. Maybe you can help me see things differently.
Curious to Learn More?
Check out Principles for Leading Software Teams: A Guide for related articles and reference materials.
