What do we mean by autonomy?

Autonomy is having the power to take actions that are timely, relevant, and appropriate. 

Autonomy is feeling confident that you are making a good choice, and you likely won’t even have to defend it. 

Autonomy is being able to take actions without context-switching or friction. 

The perils of autonomy

When we suggest increasing autonomy, there is always someone who resists and talks about how anarchic it sounds. That has been the common argument against self-organizing groups, agile programming, and uncontrolled traffic at intersections. But all of those examples do work, at least most of the time.

Autonomy isn’t anarchy when there is a shared goal and a set of constraints. Decisions are made in the autonomous unit, but with input from a wide spectrum of stakeholders, and the autonomous group has a reason to listen to the stakeholders. 

Autonomy works best when there’s a mechanism to stop failed ideas.

We all have a passion project that we want to be working on, but not all things we are passionate about are going to serve the shared goal, or are worth the energy it would take to make them work.

How we got to today

Autonomy is directly related to the evolution and progression of the developer experience and software production. It is the ability for independent work streams to work in parallel instead of being serialized. 

One of the things parallel work led to was developers wanting and needing to work more independently from each other. 

When Linus Torvalds introduced Git, he was trying to provide greater autonomy for an individual developer or small teams of developers to build software in parallel. The distributed and non-commercial nature of open source software meant that alignment couldn’t come from proximity or top-down management, it had to come from shared goals and agreed-upon interactions. 

Monoliths, microservices, and APIs

Along with the rise of Agile and Git, software architecture began moving from monoliths (the software as one integral unit) to microservices (subsystems of the software could be handled or replaced separately). Think of these two architecture choices as the difference between a quiche or an entire omelet bar. Microservices communicate with each other through APIs, which means that the edges of the service must be clearly defined, and their outputs and inputs had to be predictable.

Microservice and API architecture gave teams a lot more autonomy to do whatever they felt was right within the “skin” of the microservice, as long as their API calls and responses were well-aligned with the other microservices they worked with.

The API-centric world is a great example of autonomy. Data and interfaces are openly available, and it’s up to the people using them to decide what to do. We have even standardized on a handful of communication protocols and some standard expectations about what every externally-facing API will provide to developers.

Standardized interfaces and languages are an essential part of computer autonomy, because they benefit users as well as developers.

Consider how the standards between music and ebooks worked out. When I buy digital music from Amazon, I get downloadable, DRM-free files that I can freely put on any of my devices. However, when I buy ebooks from the same retailer, they are DRM’d extremely tightly, so that I cannot preserve them without the Kindle ecosystem. If I want to play that music on my iPad, Android phone, or digital music player, that’ll work fine. If I want to read a Kindle book on a Kobo reader? Good luck. This is annoying to me as a consumer, but when we’re talking about enterprise data, vendor lock-in becomes a much bigger concern.

Autonomy without alignment

When we started forming our ideas about the 4As, autonomy and alignment were always the most tightly coupled, because they work best together. Alignment gives us the substance of what we are working together to do, and autonomy gives us the freedom to execute it. Without alignment, you have anarchy. 

Most of us have worked on that team at some point, or with that co-worker. They have a vision, and they’re going to work on it — whether or not that vision actually helps the goals of the team or the company. It’s not quite the same as the popular conception of anarchy, because they are usually doing work that is at least adjacent to the work of the team and seldom openly defiant. It’s just that when you ask them for their work product, somehow it’s always not what we need for the next part of the process.

So how do we get to autonomy, what is required? Check back for the second part of this article soon.

This is the first of two articles that explores a key requirement for Progressive Delivery, autonomy. In this series we look at how to build and manage autonomous teams, so that your organization can operate more efficiently.