No, you can't just empower product teams

You've seen the advice, the only thing stopping teams from performing is micromanagement and distrust from senior leaders. If we just empower the team to do great work then everything will be better.

Unfortunately, it isn’t that easy.

Lets do a thought experiment. We walk into work tomorrow and instead of projects, Water-Scrum-Fall and feature teams, every team is now empowered to solve customer problems.

Changes within the Team

The team get together to decide what to build instead of building a spec that has been handed to them. But where do they start? How should they avoid making the same assumptions that lead to the bad product outcomes that the current approach leads to.

Research

Maybe somebody raises that they should talk to customers to find out what they really need. But how do they structure those conversations? A big challenge that teams have, particularly when they are used to building products, is jumping straight into solution mode. How are they going to learn to do generative research without jumping to solutions? How do the learn to avoid directly asking what customers want and identifying the pain points in a customers description of their current ways of working? What format should they structure all of the data that they have gathered to pull out the insights?

Design

Let’s say they’ve managed to avoid the traps in generative research and have some really great insights into unmet customer needs. How should they decide what solutions are best to solve each of the problems? How do you prioritise one potential solution over another? What experiments should they run to evaluate their potential solutions and with whom? Who runs these validation experiments and how do they ensure that they are not biasing people with the experiment structure and target audience?

Delivery

The first thing a team needs to do when they become empowered is to ensure their autonomy to be able to release quickly. Do they have the architecture skills to isolate out their area of responsibility from the rest of the product’s code? Do they have the DevOps skills to set up their own code pipelines? Can the product build process take the output from multiple separate teams and package them up into the end product?

Let’s say the team is autonomous and they have a promising validated solution to pursue. Even with upfront validation we can still get things wrong because the only way to know for certain if customers want your product is when they have it in their hands. Do they have the skills to break down the solution into minimum learnable products to validate their core assumptions? Feature teams are often training to to build complete solutions efficiently. It is more efficient to build everything for one part of the product before moving on to the next piece. But the solution can only be validated when all pieces are built. How are they going to learn to break down solutions into testable pieces focused on the core assumptions? How do they manage workloads to take on board the feedback from customers after each release?

Process

Assuming the product team is staffed with people who have the necessary research, design and delivery skills listed above. How are they going to work together? The standard way of working is for each person to focus on their area of speciality and handover to the next person. That is great when you are trying to work efficiently on a known repeatable process but when working on new products and features it is better to get everyone involved at all stages of the process. What does this actually look like in practice? How do they iterate on the process to improve it? How do you prioritise different improvement ideas?

Within the team summary

There are a lot of changes needed to how teams work when they shift from building outputs to delivering outcomes. This requires new skills that teams might not possess as well as a new way of working. Just telling teams that they are empowered without helping them both understand what changes are needed, as well as supporting them through those changes will result in failure.

Change outside of the Team

As I mentioned above often managers get the blame for being the blocker for successful empowered teams. But, again, it is not so straightforward.

Structure

Teams need to be independent of each other or else you will start to get teams duplicating work or creating features that conflict with each other. But how should managers decide what parts of a product each team should work on? How do they make sure that the boundaries they draw will allow teams to work independently and not require teams to have to collaborate to release every feature? Dependencies between teams reduce autonomy, which removes accountability.

Alignment

Assuming you have allocated independent parts of the product to each team, how do you ensure that the work that they do aligns with the overall vision for the product and the current business goals? How do you stop the product having a Frankenstein type user experience where the experience differs greatly between teams? How do you ensure that the features built are viable from a business perspective? You can make customers happy by giving away products for free, but you won’t stay in business very long. And given that the brand is the sum of all interactions, how do you avoid teams building features that conflict with your brand values. One approach is to educate teams on the company vision, business goals, current strategy and objectives - but who is responsible for doing this?

Governance

Let’s say that you have very aligned and autonomous teams. How do you validate that teams are operating as effectively as possible? What metrics do you use to identify performance or underperformance? Business metrics are the result of the performance of the product as a whole so isolating out the parts can be difficult. The best approach here is to identify product metrics for each of the teams based on the part of the product that they are responsible for. But who sets those metrics? Who tracks them and how frequently? What should happen if the metrics are not met? What happens if a product metric is met but the business metric, which was assumed to be correlated, does not change?

Funding

In the structure challenge you needed to break the system up into separate, independent parts to enable autonomous teams. But how much should you fund for each of those parts - e.g. how big should each team be? Should teams sizes stay static or should they change? Who decides, when and how? If they are allowed to grow who is responsible for hiring the new staff? If they need to shrink who is responsible for letting people go? Who replaces people when team members leave through natural attrition? What about team raises?

Scaling

We have managed to get design and fund autonomous teams and defined the core metrics to enable high quality governance. The product is doing really well and we want to scale. Do you make teams bigger to handle the increased demand? Do you further sub-divide scope out from existing teams and create new teams? Are there activities that every team does repeatedly that could be better handled by a platform? If so, who identifies those activities and who pitches for and funds the platform?

As you scale there will be a mix of both skill levels and experience levels, both of which determine how well people can contribute to their teams. How do you ensure that the people on each team can contribute effectively? How do they upskill in the necessary skill and experience areas? How do you decide which skills should be in the team and which should be centralised services? Who manages the centralised services?

Outside the team summary

Empowering teams does not take away all of the managerial tasks that need to be performed. But it does make all of them harder. Instead of clarity around who does each of these tasks there is now ambiguity. Faced with this uncertainty, and the constant workload that managers are expected to complete, there is little wonder that most don’t take on the additional work to truly empower teams.

Empowering teams is harder than the sound bite

Its nice and easy to stand on the sidelines and say get rid of frameworks, management and bureaucracy but unless there is another way of helping people to answer all of these questions then it is not really a viable option.

I’ve seen many of the biggest proponents of empowering teams become a lot less bullish once they become managers because they get visibility of these issues and they’re not easy.

BJ Fogg, a professor at Stanford, has done a lot of studies on change. You can either have incredibly high motivation (e.g. the company is about to go bankrupt and we all lose our jobs) or the change needs to be made easy. We can’t motivate people enough in most organisations so our only option is to make the changes easier. We created the ZeroBlockers framework to answer all of these questions to try to make adopting the changes easier. We’d love to hear from you on whether it is delivering on this goal.