Effective Organizations Value Autonomy

I believe that autonomy is one of the most important values of effective organizations. But I also think it’s a value that’s misunderstood and misapplied. I’m going to do three things:

1. Define what I mean by “autonomy”. I have a specific definition for what autonomy means in the context of businesses and their inherent hierarchical nature.
2. Explain what autonomy isn’t, and the situations in which organizational autonomy shouldn’t apply.
3. Try to articulate why autonomy, as an organizational value, leads to more effectiveness.

By the end, I’m hoping you’ll understand autonomy and why it’s important, and seek to increase it at your organizations to the extent that you can.

What “autonomy” means as an organizational value

In the context of an organization, autonomy means something specific:

Autonomy means that a person or a team is held accountable for the results they deliver, but not directed explicitly in the methods they must follow to deliver those results.

In other words, autonomy doesn’t mean a lack of direction, a lack of supervision, or a lack of oversight. Organizations that do autonomy well do those things well, too. It does mean that, once you and your manager are in alignment, the specific tactics are (mostly) up to you.

The main way I think of autonomy is by analogy to the the 10th Amendment to the US Constitution. The Tenth states:

The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.

Which means, in essence, that any powers not explicitly assigned to the Federal government are automatically assumed to be assigned to individual states.

So, the organizational version is: unless a function has been explicitly assigned to someone above you, or to another part of the organization (e.g. HR, IT, Finance), it belongs to your individual teams, or to you individually.

What autonomy is not

Now, this definition of autonomy may be a bit different from what some people had in mind. There’s a misunderstanding of autonomy which seems somewhat common among engineers: it manifests as “I want my manager to leave me alone”, or “I want to work on whatever I want.”

This isn’t autonomy, at least not in the organizational sense. Good managers are highly involved in their teams’ work while still fostering strong autonomy. There can even be highly autonomous organizations that also have a very strong top-down command-and-control style of management – see L. David Marquet’s Turn the Ship Around for an account of how that works.

Again, autonomy means accountability for outcomes, but wide latitude on methods. “Work on whatever you want” means no accountability, no direction, no required outcomes. I guess it’s still technically autonomy, in that the wide latitude still exists, but it’s a very ineffective, unsatisfying version.

Autonomy also doesn’t mean a lack of feedback. Yes, a manager who values autonomy will give their staff wide latitude to choose methods. But if a given method doesn’t work, or has negative side-effects, that person needs to know about it so they can do things differently next time. And of course if something works particularly well, they also need to be told about that so they can understand why something worked.

For example, let’s say I ask an engineer on who’s really good with spaCy to help the rest of the team learn the basics of the library. This is a high-autonomy way to ask: I’m giving an outcome (“the rest of the team knows this library”) without dictating a particular tactic. This person might choose a variety of tactics: a group presentation; individual coaching or pairing sessions; finding a specific work task that requires spaCy and showing the team their example code; etc. Whatever tactic they choose, I could give them feedback on its effectiveness – if it worked well, or poorly, and why or why not I think that is. I’m not micromanaging and dictating a specific method, but I am being clear about the results I want and giving them feedback on how well they accomplished those results.

Finally, autonomy doesn’t mean that managers never give specific methods. I once had a manager who would never tell me what to do – even when I directly asked “what do you think I should do here?” That’s not autonomy; that’s bad management. Managers who respect autonomy do give specific advice, but they do so in a framework of consent. They make sure that their direct is asking for specific guidance, or they ask first. I’ll often have ideas about how someone on my team might proceed, but I always try to ask “do you want some suggestions?” before I offer them (and, importantly, if they say “no”, I shut the fuck up).

Exceptions to autonomy

Now, there are a couple of exceptions to autonomy. While the general principle is to give staff wide latitude, there are some areas where this isn’t appropriate:

• Basic organization expectations and standards – things like responding to emails in a timely fashion, keeping your shared calendar up-to-date, dress codes, working hours, etc. Every organization has some basic expectations, and it’s reasonable for these to just be dictated. A staff member who decides not to keep his shared calendar up-to-date isn’t “exercising autonomy”, he’s just being a jerk and making life hard for his colleagues.

• Practices and policies explicitly assigned to other groups, e.g. HR, IT, Finance, etc. A team can’t, in the name of autonomy, just decide they’re going to use their own laptops instead of the company-provided ones, or decide they’re going to spend the company’s money in a way that violates rules, etc.

• Culture: it’s appropriate for organizations to dictate culture in broad terms. So if an engineering organization commits to agile delivery, one team can’t just opt out and only ship once a year without buy-in from the rest of the org. But, on the other hand, it’s probably inappropriate for a engineering director to dictate that all teams use this specific definition of story points, hold standups at 3:30 ET, etc.

• Professional behavior. It’s normal for an organization to say, sometimes very specifically, what behaviors are allowed and not allowed at work. For example, yelling at colleagues is never OK. Saying, “cut that shit out” to someone who shouts at colleagues isn’t stepping on their autonomy; it’s setting appropriate professional boundaries.

• The first-timer exception: when someone’s completely new to a task, sometimes they do need explicit instruction the first time or three. This is particularly the case for people fairly early in their career: a mistake managers often make with juniors is not giving them enough instruction. Throwing staff into the deep end isn’t the same as respecting autonomy.

• The poor performer exception: finally, when someone’s close to failing at their job, it’s reasonable (though not required) for a manager to throw autonomy out the window. When someone’s in danger of getting fired, giving them very specific instructions – even to the point of being patronizing – is reasonable. I never want to fire anyone because they just didn’t understand how to do the job. So making sure it’s really a failure to perform (and not just a failure of instruction) is a step I think is worth taking with someone who’s in danger of getting fired.

Autonomy story time

To illustrate autonomy more clearly, here’s an example – of both “bad” and “good” autonomy – from my time at Heroku:

From the earliest days (before I joined), Heroku had this idea of Maker Day. One day a week (we used Thursday), was set aside for focused heads-down engineering work.

When I joined, the scope of work for Maker Day was wide open: it was pitched as “work on whatever you want.” This is one of those seductive phrases that sounds like autonomy, and is, but not in a good way. In Heroku’s case, as we grew, this framing started to cause two things to go wrong:

First, from a management perspective, this day started to increasingly represent lost time. Engineers were working on small pet projects, but they were increasingly not aligned with what the organization wanted to ship. This didn’t work any better for individual engineers, who were increasingly frustrated that the work they did on Maker Day never made it into production.

The fix was simple but effective: we changed the “work on whatever you want” framing to “work on whatever you think is most important to Heroku”. These sound really similar, but they’re not: “whatever you want” implies an internal priority list, which may or may not align with the organizational one. “Whatever’s most important” forces thinking about what’s valuable to the organization right now.

Crucially, though, “whatever’s most important” maintains autonomy, but focuses it into an effective direction. Managers didn’t tell their staff what that most important thing was, simply that they should feel free to focus there, whatever “there” is. This is the good form of autonomy: trusting that everyone at the organization, each individual, knows what’s most important and can be trusted to execute against it.

This worked: Maker Day time become more effective for the organization, and more satisfying to individual engineers. Win-win.

Why autonomy is effective

I’m not aware of any scientific research here, but my observation from the dozens of companies and organizations I’ve worked with in my career, is that the highest performing organizations are the ones highest in autonomy.

I think this is for a few reasons:

• It leads to higher intrinsic motivation. As Daniel Pink argues in Drive, autonomy is one of the three key components to intrinsic motivation (along with “mastery” and “purpose”). Intrinsic motivation is particularly important in knowledge work, where innovation and creativity are required. Without high intrinsic motivation, you’re stuck with using punishments or rewards to induce compliance, and neither is very effective at getting people to do good work.

• It pushes power to those with the most information. The individual contributors at the front of the organization have the most accurate information about the state of things. As you move up the org chart, people higher up may have more context, but they will have less information. In a high-autonomy organization, a manager will make sure that their direct reports know whatever context they need to be effective¹, and will understand that the people doing the work have the most information and are thus most qualified to figure out exactly how to do the work.

• It helps build new leaders. Great managers are always looking to build new leaders. Ownership is a leadership skill that you practice by making larger and larger decisions. A manager who’s exceedingly directive is holding their staff back: if they never get a chance to practice making tactical decisions, they’ll struggle if given more responsibility.

• Finally, a culture of autonomy is simply faster than a culture of permission. Every time someone has to pause to ask for clearance to do something, that’s a potential point of organizational downtime. I can’t tell you how much time I’ve seen people fritter away while waiting for permission to do something. Save the permission checks for the places that really need them, and free people up to move quickly when they have all the information they need to make their own decisions.

I hope this has convinced you of the value of autonomy as an organizational principle. Have you been able to build high autonomy at your organizations? How’d it work out? Let me know - jacob @ this domain.