What is an ‘enabling mindset’?

Problems between enabling and product teams
When product teams move to agile ways of working, it’s my experience that there will be tensions between enabling teams and product teams. Existing enabling team processes do not usually work for this new style of product delivery. This friction means that a lot of heat can be generated between enabling teams and delivery teams.
This can happen whenever delivery teams move to a radically different way of working, regardless of whether it’s agile or some other radically different approach.

Why enabling mindsets are important
An enabling mindset means treating the work of an enabling team as the provision of a service to delivery teams. This approach places the onus on enabling teams to meet the needs of their product team users.

Even governance and assurance can be considered as a service. Enabling teams only exist because delivery teams need specialist support to get things done. Even the need to govern and assure stems from the fact that you are trying to deliver something.

If there’s no delivery, there’s no need for governance or assurance.

We know a lot about the culture of service and great service provision. This involves understanding and empathising with your users and what they’re trying to do.
For an enabling team, providing a great service also means:

• researching users’ experience of your service
• co-designing service improvements with users (for example, developing financial reporting processes with delivery teams that have to use them)
• monitoring the effectiveness of your processes and improving them over time
• adapting your processes as the needs of delivery teams change

So if we know how to make this work really well, what’s the problem?

Problems adopting an enabling mindset
As with many things in large organisations, there’s usually more than one problem.

The first thing to consider is whether the objectives of the enabling teams and delivery teams are aligned. The overall organisational objective is to get things delivered (to meet organisational outcomes). Therefore, the objectives of all enabling teams should be aligned to the objectives of the delivery teams.

Unfortunately, this is often not the case, with enabling teams having objectives that are disconnected from delivery objectives — or worse, in tension with them.

Where I’ve seen this happen, the problem is usually that the enabling teams’ objectives are based solely around compliance — that delivery teams follow a defined process, rather than around enabling delivery. In the worst case, an enabling team can be successful when a delivery team is unsuccessful. For example, a commercial procurement process was followed compliantly (great success for the commercial team!), but no procurement was made or the procurement took so long that it was no longer relevant (the delivery team was unable to meet its objectives — big failure!).

Where enabling teams report into the same leadership as delivery teams, there’s more chance of aligning objectives. Where they report into different leadership, alignment can be difficult (for example, if your local finance team reports into a central Head of Finance rather than your Head of Delivery).

Another common problem is when delivery teams adopt agile ways of working in an organisation that has not previously worked in this way before. In organisations that use waterfall delivery methods, enabling team processes have been optimised to support these waterfall processes over a number of years.

But agile is radically different to waterfall. This means that enabling processes optimised for waterfall delivery do not match the needs of agile product teams. This creates friction between enabling and product teams and slows delivery.

In the best case, enabling teams recognise the need to adapt to the new needs of product teams and work to understand how best to support them.

In the worst case, there’s no recognition of the need to adapt or no willingness or ability to adapt. Fingers may be pointed at product teams for not following the existing processes (that don’t work for agile teams) and product leaders begin to take heat from the organisation. Enabling team leadership might even say they cannot work with these new product teams, leaving them to figure out how to enable themselves — further slowing delivery — or stopping delivery work entirely while this impasse is resolved.

Organisations need senior leadership that can direct and support enabling teams to adapt. Showing how non-adapted enabling processes slow delivery can help quantify the cost of not adapting. This strengthens the case for temporary investment for enabling teams to help them adapt.

There may be further problems where an enabling team doesn’t own its process. For example, where the process is set in some remote headquarters (very distant from delivery) and local enabling teams aren’t empowered to change it. I’ve also found some examples where HQ already has an adapted version of the process and the local enabling team is just not aware of it. (Changes take time to flow through big organisations.) And I’ve found other examples where the local team doesn’t agree with HQ’s adapted version of the process, so doesn’t adopt it.

Some professions — like accountancy — also operate to standards and processes set by professional frameworks. People following professional paths often have to do work in particular ways to conform to the rules of the profession. Where the professional body hasn’t kept pace with changes in how delivery is done, it creates a mismatch between delivery needs and those of enabling teams.

Another common issue is that the enabling team doesn’t have the capacity, capability or leadership required to make adaptations. They may struggle to manage multiple radically different lifecycle and delivery models at the same time. Here, product leadership can help by providing extra support (financial, people, coaching) into enabling teams to help them adapt while maintaining business-as-usual operations.

How to adopt an enabling mindset
Empathy is crucial to adopting an enabling mindset. Enabling teams need to understand the needs of product teams. This involves talking to and observing product teams. Product teams must also understand the needs of enabling teams. To do this, they must look beyond just following the processes an enabling team has developed. They need to understand the reasons behind the processes — and this will help them understand the enabling team’s needs.

Product teams are very focused on their objectives. They want to achieve a specific outcome. Enabling teams sometimes focus on efficiency — perhaps wanting a smaller, less expensive set of people in a product team. But this might be in conflict with a product team’s goal. There are cases where it might be better to have a bigger, more expensive product team to achieve an outcome.

Processes that are efficient for enabling teams might not meet product team needs. For example, a finance team requires a product team to create a business case for something. This is time-consuming for the product team, but efficient for the finance team, which does not bear the time cost. Instead of focusing on the efficiency of the finance team, it would be better to focus on the effectiveness of the business case process itself.

On-boarding of users is important here — new or occasional users may not know which process to use or who to speak to. Simple or supported versions of processes are also useful. This could be guidance on how to write a business case (for example) or some kind of buddy system.

Adapting processes to enable delivery
Enabling teams exist to support delivery. They should aim to:

• take the weight of the organisation away from product teams so they can focus on delivery
• bend the organisation’s rules if needed — work to the spirit of the rules, not the letter
• hide processes/activities that don’t enable delivery
• work in a way that enables delivery — be agile, transparent and collaborative

Enabling teams also need to acknowledge that as product teams’ needs change, enabling processes may need to adapt. A discovery team’s needs are different to that of a public beta team, for example. So enabling teams must keep their processes up to date and flexible according to the needs of different types of users.
Co-designing solutions with product teams is helpful. For example, a finance team member could work alongside a product team member that needs to write a business case. This helps them see the business case development process from the product team’s (non-expert) perspective. Together, they can then come up with a better process that works for more people.

Looking at waste reduction in enabling team processes also helps. This means enabling teams should:

• map out their processes
• work out what steps are needed and which add value
• get rid of any steps that do not add value

I’ve written before how enabling teams should measure their performance. Tracking performance helps enabling teams to work out which processes to improve.
Don Reinerstsen has also spoken about the problems that happen when enabling teams measure performance with the wrong metrics.