Autonomous teams — how you work constrains your team’s autonomy
If you believe in autonomous teams, developing and engaging the people in your team should be your number one priority. But the ability to engage your team also depends on understanding what limits their level of autonomy.
Anything that limits your team’s ability to be autonomous ultimately limits their engagement meaning if you don’t take into consideration how “How you work” impacts autonomy, you will find it difficult to engage your people.
Engaged teams need to feel they have autonomy, mastery and purpose in what they do, but depending on how the work gets done in your company, this might not be possible.
How you work constrains your team’s autonomy and indirectly limits the amount of engagement you can create.
The dynamic relationship between “How you work”, and “Who does the work” means that any changes you make in one will not be fully effective unless supported by an appropriate level of investment in the other.
In fact, it can even be worse where a sustained lack of investment in either can completely negate any investments you have made in the other.
Instead, taking the approach of investing in both areas at the same time can help ensure a sustained uplift in both engagement and autonomy.
Provide as much autonomy as is possible…
A common mistake is to attempt to provide complete autonomy without appropriate boundaries. In some cases complete autonomy can be just as debilitating for teams as being given no autonomy at all. Boundaries need to be set that are appropriate for the team. This means that boundaries should be set based on a team’s comfort with ambiguity and their ability to make good commercial decisions.
Instead of complete autonomy, provide as much autonomy as is possible — for some teams this be complete autonomy.
A common concern in some companies is that “teams can’t be trusted to make the right decision” and hence “can’t be trusted to be autonomous”. Although I’d often like to be able to discount this argument completely, I do believe that it is underpinned by some valid concerns.
Often these concerns revolve around the competence and capability of a team. A lack of either of these undermines the trust in a team’s ability to be autonomous. What this means is that you are more likely to allow your “A team” of highly skilled employees to be autonomous while on the other hand you are less likely to allow your “new team” of recent hires to be autonomous.
The key difference between these groups is their perceived difference in skills, business knowledge, and alignment toward the company’s goals. These factors ultimately influence how much autonomy leadership will feel comfortable giving to a team.
In defining your way forward you should take into consideration how much autonomy is currently possible, how much more autonomy can be absorbed, as well as how the current working environment limits autonomy.
A longer term goal of increasing the capacity for autonomy within your teams will ultimately lead to the engaged learning environment many companies are striving for.
Designing your working environment
To help leaders design their work ecosystem, I use a simple model for thinking through how work gets done alongside the supporting ecosystem for engaging staff.
The model helps flush out and focus discussions around the approaches currently use to solve key activities while enabling forward looking planning around what needs to change.
How an organisation works has four main parts
If you are attempting to build autonomous teams, your company should focus on four main areas. Although what is done in these areas can be quite different from company to company, at a high level these four main activities define the system of how we work. (Unsurprisingly if you think about companies as decision engines these steps actually follow an OODA Loop decision cycle).
The four areas are:
- Blocker Escalation (Observe)
- Prioritisation (Orient)
- Team Design (Decide)
- Delivery Framework (Act)
What you do in these areas will sets the limits of autonomy for your teams.
Blocker Escalation — no structure is perfect
The first thing to remember is that no structure is perfect and your first priority is to find out about issues or problems that don’t fit the predefined rules. Being able to deal with these issues rapidly is a key factors to enabling teams to become autonomous. Not only does a commitment to resolve issues promote servant leadership, but by demonstrating commitment to resolve issues blocking teams, you provide teams with the confidence that they are being heard and supported in adding value to the company.
For small companies this escalation can often be supported by adhoc channels and relationships but as you grow organic escalation may start to become less effective. In these situations the use of a structured approach such as a scrum of scrums or alternate can provide you with the the escalation path needed to ensure blockers and issues are effectively escalated, hopefully promoting greater autonomy within your teams.
Your choice of whether you deal with escalations and the speed at which this occurs affects the limits of autonomy.
Prioritisation — how capable is your team
Once you’ve established an effective escalation path you’ll need to think about what to do with the issues that are escalated. This generally results in a prioritisation call. For example, is an issue important enough for teams to work on even though it wasn’t originally planned? Do teams need to be restructured because they don’t have the right balance of skills? or should teams redirect some of their time to changing how they are working because some processes that use to work no longer do?
The possible approaches we could use here are dependent on how capable the team is. The higher their capability in terms of both business acumen and technical competence, the greater their supportable level of autonomy.
Self selecting, self driven teams like those at Valve are sometimes considered the holy grail of agile prioritisation. In practice though, limited companies are currently able to support this model of prioritisation.
For companies like Valve where any employee is a good proxy for the customer, complete self selection is a feasible reality. For companies where employees are not reflective of the customer base, the ability to empathise with customers and make good business decisions limits their capacity for autonomy.
In these situations, having the direction set by an individual that understands your customers may be more appropriate.
However if you still have a longer term strategy to decentralise the prioritisation process, investing in customer centric skills such as design thinking and lean startup capabilities can help increase the ability for teams to prioritise appropriately.
Helping your team members build empathy with your customers enables teams to have alternative prioritisation approaches than just the highest paid person’s opinion (HiPPO) approach.
Your choice of how decentralised prioritisation should be affects the limit of autonomy.
Team Design—know how you add value to your team(s)
With strategic priorities set, teams can be formed around them. When designing teams you should focus on minimising the dependencies between teams. This reduces how many handovers are required to create value, and increases autonomy of a team.
A plethora of approaches exist in this space such as flat structures, matrix structures, feature teams, component teams, squads, tribes, chapters etc. We use these terms to distinguish the different characteristics and responsibilities of team and virtual teams.
The most important factor when implementing whatever model you choose, is to ensure that it is clear to team members are how they add value to the teams they belong to.
As opposed to mainstream agile thinking, I believe that individuals CAN belong to multiple teams as long as they understand the value they add to their teams and understand the competing demands and priorities of these teams. Sure, this will often mean that people shouldn’t be on two “delivery teams” but being part of a skill based team as well as one delivery team is generally acceptable.
Understanding how individuals add value to teams will ultimately help increase the level of autonomy as they are able to prioritise competing demands more effectively.
How self contained a team is and how clear it is they add value affects the limit of autonomy.
Delivery Framework — pick the approach based on the flexibility you need
With teams defined, it’s important to consider how consistent or flexible delivery needs to be. Consistency allows work to be managed together as a whole, but flexibility provides better tailored solutions for specific teams. Depending on what you prefer there is a range of Agile delivery frameworks to draw from.
Scrum, Kanban, SAFe, LeSS are the most popular approaches used and differ in how flexible/consistent they are.
At team levels Scrum provides light-weight consistency but less flexibility than Kanban.
At a scaled levels, SAFe provides higher levels of consistency but less flexibility that LeSS.
The more flexible the approach, the more autonomy teams will have, but the harder company wide transparency becomes.
Picking the appropriate level of the company to introduce consistency will influence how much ownership a team has over how they work.
Note: Although I speak of this as the Delivery framework, this term really represents the value-stream of the company, the more your framework encompasses all parts of the value-stream the higher a team’s autonomy will be.
Your choice of how how flexible and/or consistent your delivery framework, affects the limit of autonomy.
So what’s the right mix?
Every company is different so unfortunately there are no silver bullets.
Not only do companies differ in the types of business they do and the customers they serve, but they also differ in the mix of people they have, and the skills they bring with them.
The right mix of activities considers the differences in these factors and makes choices about organisational design that respects the varying capacities for autonomy and engagement.
Based on the capacity for autonomy and where you want to be, you can design an ecosystem that helps you be effective now, while also moving you in the right direction for the future. Hopefully it does this without scaring everyone off at the same time.
Three important factors of designing for autonomy
Because there are quite a number of different factors to consider, I usually focus on just these three factors to keep me on the right path.
- Ensure teams are aligned on intent and know how they contribute to the bigger picture
- Provide clear but wide boundaries to encourage autonomy, but be ready if the boundaries are too wide to provide more of them — using strategies and tactics as an alignment tool can actually help increase how wide boundaries can be.
- Invest in improving a teams understanding of your customers and their technical capabilities. Trust is critical for delegating authority, but trust can’t exist without teams that are both highly capable, commercially and technically.
These three factors are critical in defining how successful your system is at increasing autonomy.
Partnered with an engagement program this should help make your agile change stick.
If this topic interests you feel free to shoot me some questions or have more details look at the other part of this model focused on developing and engaging people.
