Why “Autonomous” Teams Don’t Realize Their Full Acountabilities

It’s important to remember that accountability for architectural decisions can be the purview of an entire team and not just individuals. In the software industry, there has been a shift away from the over-identification of certain roles, and a movement towards a team mindset. This is because no one person has the skills on their own to deliver valuable software systems. You need groups of people–teams–to achieve this. That is why teams, not individuals, are the most meaningful units of consideration in software development.

In recent years, the term “autonomous teams,” has gained popularity in software, largely because of Team Topologies. An autonomous teams is able to operate with minimum supervision and interference, meaning they shouldn’t get blocked by others; teams, or individuals. However, this view can be problematic because it implies that a team should be completely independent. Such behavior isn’t ideal when a multi-team collective is trying to collaborate on a complex system. It can also prevent teams from realizing the full extent of their accountabilities, which is particularly concerning when a team participates in an advice process.

First, if a team is built as a collection of standard job titles then the expectation is set that everyone will stay in their lane, as a collection of individuals rather than a dynamic team. A standard team in this approach would contain multiple “developers” to write the code, a “business analyst” to write User Stories, perhaps an “XD” to interview users and design screens, and maybe a “delivery manager” who looks after dates and the risk register. A better way to bring together a team is to consider the capabilities a team must embody collectively to deliver, run and evolve their systems. Such capabilities for example might be “run a live service” or “conduct product experimentation”, or “deliver outcome for user-base X”. This takes attention away from the individuals, focusing instead on the team as a whole

Second, once staffed, if a team is independent up to a certain point, but doesn’t have control over their delivery outcomes–what they build, and when and how they build it for example–then their influence won’t be broad enough to be effective in a post-revolutionary, decentralized world. In order to really own and realize their full accountabilities they must have sufficient power to be truly accountable for their outcomes.

So if “autonomous” is unsuitable the wrong word for how teams should think and act, what’s a better term?

Well, while it is still fundamentally hierarchical in its basic outlook, the book EDGE: Value-Driven Digital Transformation discusses how, instead of being autonomous, teams need to be both self managing and self-sustaining. This clarity regarding the purpose of their autonomy enables them to fully own and deliver on their accountabilities. How can they achieve this?

First, teams first need to contain, or have free and sufficient access to, all the skills they require to deliver on the outcomes they are accountable for. Second, they need to maintain this skill availability by paying attention to signals and look to refactor their team make-up and boundaries of responsibility as required. The former is out of the scope of this book. The latter, on the other hand, is directly in our architectural-practice wheelhouse.

The earliest signals of this boundary-refactoring will arise as teams work on tasks earlier in the delivery lifecycle of a new product or programme of work. This is when teams their schedules, decide what to work on, who works on it, whether they are going to buy-or-build something (or a mix), and start examining, mapping, and planning to reduce risks around integrating their work with other teams.

Even when all this is in place, and nothing else is getting in everyone’s way, this boundary-refactoring process still takes time. (This is a system, an open one, which has a lot of forces acting on it.) Remember, it not only takes time for teams to form, but it also takes time for teams to understand the full extent of their accountabilities. The skills to work in this new paradigm and to nurture that trust take time to learn too. And the structures and ways of working need to change too. The transition to self-management doesn’t happen overnight. Those working across teams don’t learn how to interact with such teams overnight either. The understanding of the new operating model and the mutual trust that it requires takes time to grow, and fears take time to be dispelled.