The majority of people, both managers and employees, aspire for their teams to be autonomous. In reality achieving that autonomy can be quite challenging. One reason is that it is poorly defined and hard to measure or sense when you might be achieving or undermining it.

At the heart of autonomy are the ideas of who decides and who takes action. This is the difference between delegation and empowerment. Delegation gives someone authority to act based based on your judgement. Empowerment gives them the authority to decide based on their own judgement. Caught up in these phrases are other emotive ideas such as micro-management, command and control or, in the opposite extreme, managers that are so far removed they are negligent.

Levels of autonomy also need to be appropriate for the situation. Whilst giving someone too little autonomy can create unproductive and unsatisfied employees too much can leave them feeling over stretched and lost.

To illustrate think about visiting a close friends house for dinner. You ask them how you can help out with the prep. What you want from them is a list of jobs to do so you can work through them one by one. However, that isn’t how you would feel if you was part of the team responsible for running a restaurant kitchen. You’d want to be part of the decisions about the menu and what equipment and ingredients we need.

Which is why I have broken the model into three broad management styles: Task, Output and Outcome. Each of these has differences in the balance between decision and action, manager and employee.

To understand these differences I have defined the key areas which determine levels of autonomy:

What responsibility gets delegated?
How are the team made accountable?
What are the incentives?
What decisions does the team make?
What decisions are made collaboratively?
What decisions are escalated to the manager?
How are issues and progress made visible?
What is the communication style between them?

In reality every team will see a mix of these depending on the manager or stakeholder they are working with, the type of work they are doing and their needs at the time.

This isn’t intended as a maturity model where teams are trying to get to the top. This is intended as a guide to help leaders and teams understand the current state of their relationship and make collaborative decisions about where they think they should be and what they could do to get there.

	Task	Output	Outcome
Delegated	Specific tasks and instructions	Delivery of a solution	Purpose or goals
Accountable	Task completion within constraints (time, potential budget)	Delivery within the criteria (time, cost and quality - the iron triangle)	Moving closer to the goal
Incentives	Number of tasks completed	Hitting deadlines, managing costs	Problem solving
Team decisions	Little but may decide method	Break down solution and schedule tasks. Delivery method.	How to move towards the outcome. Priority of problems.
Collaborative decisions	Order of tasks, deadlines	Solving delivery issues and obstacles.	Overall strategic goal and constraints (budgets etc.)
Escalated decisions	Solutions to any low level problems or blockers	Changes to scope. Feature prioritisation.	Stop, start, continue. Invest more, invest less. Feasibility issues.
Visibility	Inspection of tasks done	Status updates (progress vs time)	Data/metrics
Communication style	List of activities. Number of activities done. Deadlines.	Project or system names. Deadlines.	Customer or user outcomes. Business capabilities. Data.
Autonomy	None to low	Medium	High

Task/activity based management

It is my wife’s 40th birthday and I am planning her party. Her family and close friends want to help out. I have a clear idea of what needs to be done, so I create a list of tasks and delegate them amongst the group. I do this by giving each person specific instructions from playlists to create (with her favourite songs), recipes for dishes to follow, decorations to arrange, presents to buy, people to invite etc. Each task has key criteria and times by when they must be done. Periodically I check in on everyone to see if they have remembered to do the task and if they are doing it to my expectations and, importantly are things on time.

This style of management is task or activity based. Delegation takes the form of giving teams and individuals specific tasks or activities. Each one comes with clear completion criteria including timelines and perhaps quotas (purchase six crates of red win, three white, one of champagne etc.).

Accountability takes the form of commitment to complete the tasks within the criteria. Individuals are incentivised to take on tasks and get them done (work completion and quotas).

The teams and individuals have very little decision making rights, although they may decide who carries out what based on specialisms. The managers retain decision making rights to all solution detail. Managers and teams may collaborate over details such as order of tasks or negotiate deadlines. If the team hit any issues they have to escalate to the manager who then decides how to proceed. This is usually done by issuing further instructions.

Visibility is mainly about progress and quality of work. Teams must report back on task status at agreed periods and their work is inspected regularly.

Communication between manager and team is in terms of activities, instructions and deadlines.

In a software delivery environment this would look like a team which received lists of features or tasks from stakeholders in the form of a roadmap or Gant chart and distributed them to the appropriate team members.

Under minimal autonomy instructions are closely followed. Autonomy can be increased if the manager allows the team or individuals to decide the method. This would be the difference between following a given recipe vs you choosing a recipe for yourself. In higher trust environments the manager and team may negotiate over order of tasks and deadlines. Essentially creating a roadmap for approval.

Autonomy is risked when managers see tasks failing to complete or be done to their standard and they step in and take over. They complete the task themselves (if you want a job done properly do it yourself) or increase micromanagement through instructions (telling them what to do) and inspection (by pointing out flaws in already complete work).

To avoid this happening managers should pair with the individual or team and mentor them so they can complete the activity themselves under their support and guidance.

Output based management

You are hiring a tradesperson and you have a specific output in mind. Build an extension, decorate a room, fix the heating, install some smoke alarms. The tradesperson will listen to your request, understand the key parameters and give you a quote with various options. As the client, you select the option which best fits your constraints (such as budget or time) and the tradesperson commits to delivering that option. If they hit any significant problems they raise them to you (the client) and you chose the best way forward together.

This style of management is output based. Delegation takes the form of giving teams responsibility to create and manage a specific output (e.g. a project).

Teams and individuals have some decision making rights about the approach to the work or the way they deliver. They can break solutions down into tasks and negotiate priority. The manager retains rights to the chosen solution and its key criteria (such as time, cost, quality and scope) and selecting priority. Any significant problems are escalated for managers to decide. These are normally resolved by agreeing a change in criteria or issuing new solutions.

Accountability is to the delivery of the output scope within the criteria, usually of time, cost and quality (the iron triangle). Teams are incentivised to get things delivered on time and budget.

Visibility is mainly through the form of status updates with output inspected at significant intervals (milestones).

Autonomy can vary at this level. Under minimal autonomy the solution and priority of work is fixed. Increasing levels of autonomy may include delegating priority decisions to the team. Autonomy can be significantly increased by giving the team the specific problem and asking them to generate possible options. The manager then picks the most solution they feel is best. This moves them quite close to Outcome based management.

People who operate in this mode predominantly communicate in terms of projects and systems. The names of these very rarely communicate the intent. For example “the CMS” or “website” project or even use non-descriptive project branding such as “Project Umbrella”. It is difficult for those without full context to understand how the projects connect or what their purpose or benefit is.

In software delivery this would look like a team which is given a specific project (build a website) with rough requirements or features. The team would use these to form a roadmap of features or tasks to be delivered by each deadline or iteration.

The risk to autonomy is that managers, who are heavily invested in the solution, step in to the team and begin to propose tasks. The team slips into task based management.

To avoid this happening managers should bring any problems they see directly to the team and ask them to generate possible options.

Outcome based management

You have some money you wish to invest for your retirement. You approach a financial advisor and give them the information they need to select the best investments for you. The financial advisor has full autonomy to choose where to put your money. They regularly update you on performance and explain the impact of the investment decisions they made.

This style of management is outcome based. Delegation takes the form of giving teams responsibility to move towards a long term direction (a purpose or vision) or set of long term goals.

The team has decision rights over how best to reach those goals, whilst staying within the guardrails and moves iteratively towards the outcomes. They identify the problems to be solved and how best to solve them. They collaborate heavily with the managers on strategic direction and potential opportunities to exploit. They will negotiate over constraints such as funding. Managers retain investment rights including ability to stop or start teams and whether to invest more or less in them. The team will escalate any significant issues in reaching the goal, generally around feasibility.

Accountability is to the delivery of value, as defined by the goals which have clear measures of success and guardrails (such as revenue targets or run rates). Teams are incentivised to solve problems and find solutions which move them towards to goal.

Visibility is mainly in the form of data and metrics usually from observations or experiments. These relate to the goal and are used to inform the stop/start/continue decisions.

Teams who operate in this mode predominantly communicate in the form of customer or user outcomes or business capabilities. They will also back these communications with both qualitative and quantitive data.

Under minimal autonomy the team leaders control direction and constraints and may even prioritise the problems. Autonomy can be increased if the manager hands prioritisation over to the team with clear criteria (such as cost of delay). Highly autonomous teams may even collaborate with leadership to challenge the constraints they are under or even adjust them themselves (for example by reforming or repurposing teams).

Autonomy may reduce when managers see teams struggling to find ways to move towards the goals, or feel they are moving in the wrong direction. To help they offer up solutions. The team then slips back to Output based management.

This usually happens because the goals are poorly written, unclear to the team or beyond their capability. One common symptom of badly formed goals is they are written as outputs (e.g. our goal is to build a website) and don’t actually articulate any user or customer outcomes (provide our clients with compelling Thought Leadership).

To avoid this happening managers should collaborate with the team either by facilitating sessions which clarify the goal from the user’s or customer’s perspective or by coaching them through problem solving.

In software delivery this would look like a product or capability team. The team would work towards a clear purpose and interact directly with their customers and end users.

Moving up the autonomy ladder

It’s important to remember that most of the time that autonomy is misaligned is because people aren’t quite sure what is expected for the situation or that trust hasn’t yet been built.

When this happens, to help leaders and teams move up the autonomy ladder to where they need to be, make small shifts rather than giant leaps by asking these key questions:

Who decides the work? Move from manager giving teams specific tasks to asking them how they would break things down.
Who generates the options? Move from manager telling teams to execute a solution to bringing problems to the team and asking them for options to solve (along with estimates on effort etc.).
Who selects the right option? Move from manager deciding which option to pursue to giving team clear guidance on criteria and trade-offs so that they can self select
Who identifies the problems? Move from manager looking for problems to bring to the team to the team identifying problems themselves and asking for prioritisation.
Who prioritises? Move from manager prioritising to giving the team clear prioritisation criteria so they can self select.
Who removes constraints? Move from team escalating blockers outside their control (time, budget, staffing etc.) to team being able to directly challenge or remove them themselves. E.g. re-organise their own team, manage their own budgets.