Funding And Governing Empowered Teams

Long-lived, empowered teams are expensive. Instead of having a business case that has clear costs and benefits, long-lived teams require companies to place a lot of trust in these teams. This causes two problems that need to be solved:

1. How can we convince companies to fund our teams?

2. How can we prove effectiveness to ensure continued funding

Convincing management to fund a team

We need to put together a compelling business case for funding our teams. A typical business case demonstrates ROI by calculating the cost of delivering a feature and the expected benefits. While the costs are often underestimated and the benefits overestimated, the perceived rigour of a business case enables people to make informed decisions.

Defining costs

When funding teams, costs are easy to calculate. We wrote about how to design long-lived empowered teams using value streams in our last article. The team make up helps us to estimate the cost of the team as salaries make up the majority of the team cost.

Defining benefits

Estimating the benefits is a lot harder. There are four different types of metrics that we can define:

1. Effort: The hours that people put in

2. Output: The features that are developed

3. Outcome: The customer behavioural changes (e.g. use of our product)

4. Impact: The revenue, cost and strategic goals of the company

Our ultimate goal is the business impact but this is too lagging and slow to help teams course correct as they are building a product. It also provides limited direction to help teams prioritise what features to build.

Effort can be correlated with impact when you are repeatedly building the same product. But they are not correlated in software where we are always building something new.

Equally outputs are not very correlated because 90% of features fail to deliver the expected benefits.

The sweet spot is outcomes. Outcomes tell us how customers use, or don’t use, our products and they are very correlated with the desired business impacts.

Selecting desired outcomes

Before you can assign outcomes to a stream team you need to be clear on the key outcomes for your product as a whole. That is outside of the scope of this article but you can use frameworks like Pirate Metrics or HEART as a starting point for your product.

With clear product metrics you can focus in on the metrics for the part of the product that is owned by the stream team. For example if you are launching a platform and you have a team responsible for acquiring new partners onto the platform then the product may have metrics like:

• Activation Rate

• Growth in Products per Partner

• Onboarding Completion Rate

• Average Time to First Sale

• % change in Partner Acquisition Cost

This is a critical step so ensure you invest the time to debate the importance of each metric and how it will drive the business impacts that you are looking for.

Justifying expenditure

Now that you have costs identified and have agreed on the key metrics you can debate whether the required investment is justified. This is the point where you may push back on the team size, or conversely, suggest a larger team or splitting the scope of the team.

Once agreed your team is ready to start!

Governing Teams

Defining Targets

With a team and metrics in place, you can now define targets for each team. This should be a collaborative exercise involving both the stream team as well as the parent product team.

When setting targets it is key to refresh on the product vision and strategy so people have the context of what needs to be achieved. The strategy should also determine the level of risk expected for the team. If there is a high growth strategy then targets should be set high, highlighting that the expectation is for the teams to take risks. For other teams, there might be a lower risk appetite but higher expectations of reaching targets.

The cadence of setting targets varies between different companies but I like the 6-week pattern that is starting to emerge. 6 weeks is long enough to build and test something but not too long that people think they can relax because the deadline is too far away.

Monitoring Effectiveness

Amazon advocate for a weekly business review where all of the product teams come together to review the performance of all of the product and business metrics. The intent of the meeting is to identify where targets are being missed as well as when product metrics are not being missed but the associated business metric is not responding as expected. If there is no correlation between product metrics and business metrics then the product metrics need to be changed.

But there is a problem with tracking teams like this. Teams can take time to start delivering because they are lacking the two key ingredients for success: zero blocking dependencies and deep customer understanding.

When Amazon set up their teams, all of the dependencies that were slowing down delivery didn’t magically disappear. Teams would spend up to 9 months abstracting themselves from the rest of the system and putting the monitoring in place so they could do real-time reporting on their key metrics. If they were expected to deliver immediately on their business metrics it would have hurt their long term performance.

So before we get to tracking teams on their business metrics we need to govern them on their progress towards autonomy. Fortunately there are some good metrics already existing for this: the DORA metrics of Lead Time, Release Frequency, Change Failure Rate and Mean Time to Recovery (MTTR). You can also put in place metrics to determine progress towards instrumentation such as Metrics Coverage Ratio, Data Freshness (because we want real-time data) and Data Quality.

Once the team has removed all of their dependencies and instrumented the product they will be able to deliver much faster than before and make up for lost time. As Amazon proved, once the team is autonomous they can start delivering outsized results.

Reacting to Performance

The final step is to ensure that the teams are performing as well as they can. If teams are consistently underperforming, product teams can look at measures like allocating more support to the team, moving people in and out of the team, or in extreme cases shutting down the team and moving the value streams to other teams.

By having a regular weekly cadence of reporting there is opportunity for teams to get ahead of problems and course correct before such drastic actions. This improves outcomes for customers, the business and the team.