Autonomy: What it is and what it isn’t

• Goldilocks Autonomy
• What it isn’t
• So what is autonomy?
• Crossing lines
  • Business leaders don’t have a clue
  • Business leaders want to be too involved in the ‘how’
  • The agile team want to own the ‘what’
• Blurred lines
• Not too much, not too little — just right
  • The goal

¶Goldilocks Autonomy

One of the principles of the Agile Manifesto:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Principle 12, The Agile Manifesto

In a word: autonomy

If you can give your agile team autonomy, they should be able to follow the agile approach and get stuff done without micromanagement. And in practice, this works really well — when everyone has a shared understanding of what ‘autonomy’ really means.

In isolation, the word ‘autonomy’ can mean a lot of things. Outside of the context of agile, it can signal freedom to do what you want.

In the context of agile though, autonomy has to be slightly less far-reaching.

If we want to build autonomous teams then we need to be absolutely clear what autonomy means and everyone on the team needs to align with that meaning so that there are no misconceptions.

¶What it isn’t

For agile teams to perform well, they need direction and a certain amount of clarity.

Complete autonomy in a broad sense brings with it a total lack of clarity and direction.

Now, for adventurous, entrepreneurial and creative people who really love a challenge, this might sound ideal! “Finally, a chance to show people what I can do.” Without the encumbrances of other people’s decisions or the limitations of a specific set of tools, they have total freedom.

But imagine you turn up to work your first day and no one says what the company does or what they need you to do. You’re completely left to your own devices. It’s like being dropped in the middle of the wilderness with absolutely nothing — no backup, no tools, no reason why, no clue where to go.

That doesn’t mean if you find yourself in this situation that it’s bad or impossible to get out of. In fact, it’s quite common, especially for a startup or when a new project team is built and simply given a blank slate, maybe with only a handful of people. Someone needs to make some decisions: what will we do, how will we do it etc.

However, as a company or project grows, becomes a source of income and a clearer strategy develops, the what we will do/are doing, may become quite well established, and so it doesn’t make sense for it to be open-ended — that freedom naturally goes away.

At that point, there needs to be a clear identification that things are crystallising and that the autonomy of the team will be changing shape.

This is a good thing for agile teams: there will be some direction and clarity already, which should mean that the team aren’t just standing around, staring at each other, wondering what they’re supposed to be doing. It means the team can grow with intent and it removes the room for politics and egos to trip things up.

In most cases though, the business and key stakeholders should already have set the overall direction of the project — a North Star that everyone on the team will be aiming for, one that generally doesn’t change and ties back to high-level business objectives, such as a product strategy or revenue targets.

This helps determine the what from a reasonably high level. And that in many ways will also inform the what at lower levels — not necessarily that there’s a single, perfect or fixed way to do things, but there will only be so many ways to achieve the goal, options limited by the high level constraints.

For example, if your goal is to increase business revenue through a new product offering, and the business has determined that an online project management tool that can be sold as a subscription service is the answer, that may pre-determine a bunch of decisions, such as that this needs to be a web application hosted in the cloud.

It most definitely precludes doing things like buying up a cheap stock of printed Gantt charts that you try to sell on at a small mark-up.

And this makes sense because in most cases its only the business leaders who have the birds-eye view of the business, the customers and the market — the agile team probably won’t have all of that.

This highlights how important trust is: we have to trust that each group:

• knows what it should be doing, and
• that they can do it well.

If there are cracks or holes in that trust, those need to be mended otherwise this falls down fast.

There are second- and third-tier decisions that may come in at this point, such as what technologies (programming languages, databases, UI libraries etc) to use and which cloud providers and solutions should be deployed to support this product.

The business (i.e. the leaders who are setting strategy and deciding what’s needed to meet objectives) doesn’t want or need to decide the answer to all of these questions.

¶So what is autonomy?

Those second- and third-tier decisions aren’t the what, they’re the how. And this is where the line should be drawn.

If the business can clearly establish the what and express that effectively to the agile team, the agile team can then focus their attention on the how.

Autonomy here allows the team to pick the most appropriate how to suit the capabilities and capacity (budget, resources, tools etc) that are available to the team.

Trust from the business leaders is imperative — trust that the team are capable of making decisions about how to achieve the what.

This clear separation of responsibilities is crucial, because no one in the business can do everything. If you want to get the best out of your people, you have to let them get on with it. Equally you have to give yourself time to do what you do best.

¶Crossing lines

I’ve seen problems arise in agile teams where the various members on both sides — the business leaders and the agile team — are unclear (or forget) which part they should be focused on: what and how, respectively.

Here are some scenarios:

¶Business leaders don’t have a clue

They’ve not got a strategy, they don’t have any ideas or theories about what will work, they simply want to offload all responsibility to a team and let them get it done.

This is probably the worst case scenario. The business doesn’t even know what it wants and is trying to avoid making a decision. If the team are left to it, it could sorely bite them in the arse, especially if there are no clear decision-makers appointed to decide exactly what will be done.

Also, without those appointees having a clear reporting and feedback cadence with business leaders, the team could be seen as operating in a vacuum, disappearing into a hole for months or years, spending money and the business not being clear on what the results are.

Teams like this often see dramatic shake-ups and their projects may even get completely shut down, especially if the organisation changes around them.

It’s possible to still make things work in this scenario, but as mentioned, it really has to come down to leadership making at least some clear decisions and sticking to supporting them — delegate figuring out the what to someone who really cares and understands the business impact and who can vouch for the team to leadership.

¶Business leaders want to be too involved in the ‘how’

When leadership crosses this boundary, agile teams start to feel untrusted and micro-managed. Often, the technical details are get drawn out and every decision is scrutinised — sometimes by people who don’t have the necessary skills to do that well.

You might see this from an over-protective C team or where a clear scope and budget have not been set, so leadership have a lot of fear that things may get out of hand.

The way out of this is to identify the areas where the safety measures are not fully in place and remind leadership that for the team to be most effective, they need the autonomy of deciding the how without having to get approval for every little detail.

The side-effect of this is usually that business leaders will find they have to check-in less often, have more confidence that things are going well, and a greater level of trust in the team.

¶The agile team want to own the ‘what’

From the other direction, if the business leaders have already established a what, the agile team need to get behind that and simply work out the how.

If they’re not, this will cause friction as they repeatedly push back and try to get something else done instead of what they’ve been asked to do. They may even try to do this surreptitiously or undercover, ‘secretly’ (or not so) splitting the team into multiple sub-teams to try and do what they want whilst giving the impression that they’re still doing what the business wants.

This will breed mistrust from leadership who may rightly be concerned that the project is not going in the right direction to meet the overarching business objectives.

Now, pushing back on the what isn’t a bad thing. One of the main reasons for bringing a team of smart people together is to solve all sorts of problems in innovative ways — different experience and skills should all be brought to bear for everyones benefit.

If the team determine that the what isn’t right for some reason, they have a duty to tell leadership, to help avoid the company making a mistake and wasting time, effort and money.

However, it is still up to leadership to decide whether or not to change course! The team needs to be very careful when pushing back. If they are unhappy at the decision that the business leaders have made, this can cause a lot of frustration and difficulty in the team, including disagreements amongst the members about what they should be doing.

At the very least, it can lead to very lengthy and overblown discussions around minute details as everyone on the team starts to feel like they should have a say.

However, this is a time to disagree and commit. It’s especially important that Product Managers and Project Managers set a good example in this regard and establish the tone for the rest of the team so that forward momentum can be kept up.

(The same is true in the other direction: leadership can and in some cases should push back on/advise/strongly recommend alternatives to the how where appropriate. But the leadership team should still recognise and respect the boundary; that it is ultimately up to the agile team to decide how to deliver.)

¶Blurred lines

Now, the what and how can easily cross each other. When you’re getting into the detail of what a new product should do (i.e. its features), that can feel like the what to the business, but the how to the agile team building it.

For example, the business objectives (based on say customer demographics) may suggest that a project management tool should have a Gantt chart feature. Perhaps this is a common feature in competitor products — so the business may determine that in order to compete, this feature must exist.

However, the agile team may have found through research that the Gantt chart feature of competitor products is rarely used or only done so by customers of a certain size or industry. The team may have determined that it’s an expensive feature to build and that the returns on that investment could take some time to be realised.

If the product isn’t yet launched, they could fairly suggest that the team focus on building core features that will be used by the majority of early adopters first and then come back to this feature later, perhaps even some time after launch or when a paying customer specifically asks for it.

In this case, the feature may be added to the product’s backlog (what should be built has still been determined by the business), but the delivery team have been able to prioritise other features first (still deciding how it’s built). In this way, the two sides can collaborate and come to acceptable compromises.

This is not an example of the agile team being stripped of its autonomy or being granted too much autonomy.

¶Not too much, not too little — just right

If the people involved in these projects don’t agree in advance where the line of autonomy is early on, it can lead to misalignment later. In that situation, you may find some individuals starts to misinterpret the motives of the people in the other group.

It’s also really important to have these two groups made up of different people. If there are some that sit in both camps, it will be very hard for them to keep a clear view of which role they’re playing in a given setting and this can be confusing to others in each group.

¶The goal

Both sides need to remember that the goal is having a motivated team. The right kind of autonomy is just one way to help keep people feeling motivated. Too much and they’ll be flooded with indecision, too little and they’ll stall.

All of this goes hand in hand with trust and transparency from both sides that each want to and are doing the best they can do.