Autonomous Teams: What They Are and Why You Should Care

Autonomy and teams are inextricably linked when it comes to getting the most out of software development. With autonomy, you have the self-directing freedom of execution and can do some of your best work. As part of a team, you and your colleagues unify around a specific goal, supporting each other so that you either succeed or fail together. And teams often produce better quality work, more reliably, than working independently.

But there is a third option. Autonomous teams have the greater potential for success than either of the two alone. You have the freedom to do your best work while working as a cohesive unit to produce reliable and quality output.

How I Model This

Throughout my career, I’ve worked at a number of companies and some serve as extreme examples of what I’m talking about. Below, you’ll see I’ve broken this down into four quadrants and described what each case was like.

A chart is nice, but I'm going to put this in context for you with some anecdotes from my past that describe the relative extremes of each quadrant. (Sorry, none of these extreme examples are from New Relic.)

No Team, No Autonomy

Once I took a position where I was one of many contractors in a 'contractor room.' (An us versus them split from the get go.) Each contractor worked on a different project, so there was very little chance for the contractors to share amongst themselves. And we had very limited access to the people managing the code bases we were contributing to.

It was a very un-team like environment and we had little freedom of execution. Work was carved out to the class-level. If I wanted to create any additional classes, I had to come up with a document to explain my design. Once that was developed, I’d send it to a staff architect who’d leave it in his inbox and get back to me in about a week. All code was run through quality analysis software and all warnings had to be resolved before I could move on to the next task. Each task was super fine grained, so with all process hand-offs and responsibility splits it would take days to complete a trivial task. There was little autonomy and I certainly didn’t feel we were very successful.

Team Without Autonomy

A while back, I joined a big team at a company working on a big project. We all sat together and everyone knew what everyone else was working on. We worked together, and asked for and received help as we needed it. We went for lunch and coffee together, and had energized discussions about what we were working on. We had a clear goal that we were aiming for and identified as being a team. If our project failed, it would be a disaster and we’d all feel responsible.

Initially, it seemed as though we had a lot of autonomy. But looking back at in, the opposite was very apparent. The company was large and very corporate – the kind of company that imposes rules because it makes short-term financial sense as opposed to making sure good work gets done. The dictated organizational structure and implicit incentives doomed many projects to failure. The sales team was motivated to win bids by making promises. Systems analysts were swamped with won projects that they needed to write detailed ‘executable’ specifications for.

Project teams such as mine were delivered the final database schemas as starting points. Projects had to be built on top of a pre-existing code base that tried (and largely failed) to generalize to all possible projects. And we didn’t have the freedom to modify that code base.

Our project team was given mini-milestones with fixed deadlines. As we inevitably started to slip on the schedule, we pushed hard to have the priorities of the milestone re-evaluated in light of what we had learned. Unfortunately, the milestones were in the contract so our hands were tied. We definitely had a team that worked well together, but little autonomy. And what we had was limited to small-scale technical freedoms. This meant we were moderately successful.

Autonomy Without a Team

In another position, I took over a project that a previous employee had left behind. And I had complete freedom to do whatever I thought was necessary. So I went about making the system resilient enough to stay online most all the time. I added tests to the system, and ripped out 75% of the code base that was speculative code that we weren't using. I made it possible to deploy any time we wanted rather than a week of integration testing. What a success, right?

Well no, not entirely. I was working in a vacuum in my own little silo and so was everyone else. We only interacted with each other when we had to, usually when we needed to get something done for our own individual projects. So, we made no real progress at all from a business perspective and the system as a whole didn’t evolve at all. We had a ton of autonomy, but no team to speak of. This meant we were limited to localized successes.

Autonomous Team

I joined an established team at another company. Our team had a single product to focus on and we sat together in an open workspace. Anything resembling a meeting was a direct result of needing to make a good decision. As such, most meetings would be on a topic that the team had a strong opinion about.  Because we worked so closely together, we stayed in sync, so that any one of us was trusted to represent the team when it came to making a decision.

When we missed a deadline the whole team felt responsible. The team had earned a lot of trust due to its history of delivering and that gave us the freedom to work as we wanted. It was on us to improve our setup if we felt strongly enough that we needed a change. Over time, we made a great many small and some big changes in order to improve the way we worked.

There were limits to our autonomy. We were powerless to change the way the organization as a whole was structured. So we'd still have to struggle with organizational process in order to release our software, buy new hardware or make roll out schema changes. As a team we did make some big blunders, but on the whole we were very successful.

Generalizing From My Personal Experience

I think there is a correlation between autonomy and how well you can succeed or how badly you can fail. The more ‘teaminess’ that’s present, the more likely you are to get a well-rounded solution.

I encourage you to review your work history and draw your own conclusion. I expect you’ll find your own correlations between which quadrant you were successful in and which you weren’t. Let us know what you find in the comments below.