In my last article I discussed the trade-offs between the sometimes conflicting goals of team autonomy versus leverage. Quite a few of you wrote to me and said this was a hot topic at your company, and several asked about the same basic topic, but less from an engineering perspective and more from a product and design perspective. This issue comes up enough in different forms that I thought it was worth elaborating on.

Here’s some examples of the trade-off I’m referring to:

• What if one of the teams decides that they see a better opportunity pivoting their effort to serve a different type of customer?

• What if a team decides they don’t want to do the work to support a major company initiative (e.g. Internationalize the product)?

• What if a team is convinced that they need to change course to take advantage of the mobile opportunity, even though they control just a part of the overall experience?

• What if a team is convinced that they need to move to a different user experience design, even though it would be different than the other teams?

Each of these is a case where the team might have one perspective and the leadership might very well have another. Many teams will argue that if they are truly empowered, then they should be able to make these sorts of decisions for themselves.

In healthy teams and organizations, the way we normally reconcile these views is that the leadership has control of two major inputs to the decision process. The first is the overall product vision, and the second are the specific business objectives assigned to each team.

Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don’t, there’s a vacuum and that leads to real ambiguity over what a team can decide and what they can’t.

The product vision describes the big picture of the customers you are working to serve, and the services you wish to provide each type of customer. That product vision is in support of a business strategy. For example, if you have a business strategy built around a low-touch sales model, this drives a very specific type of product vision. If a team were to try to build a product that strays from this vision and model, they would have a very hard time getting the product to market.

The specific business objectives assigned to each team might be in the form of a prioritized set of KPI’s (also known as a product scorecard) or increasingly a set of OKR’s (Objectives and Key Results), which also ends up with a prioritized set of KPI’s. If, for example, the business objective is to significantly lower the customer churn rate, then that’s the team’s mission.

Note that while the product vision and the key KPI’s are provided to the team by leadership as part of the context, nothing is said about how to do that. That’s where the team has the autonomy and flexibility. I like to describe strong product teams as collaborations to solve hard problems. Reducing the churn rate can definitely be a hard problem, and there are likely any number of ways to approach fixing this. Similarly if you’re trying to increase customer lifetime value, or decrease customer acquisition cost, and so on.

Assuming the leadership is providing this product vision and KPI’s, the real difference between an autonomous team and others, often turns out to be whether or not there’s a company roadmap. If the leaders or company stakeholders provides the team with a list of committed features, which customers and company stakeholders already are counting on, then there’s little room for the teams to figure out the best way to solve the underlying business problems (not to mention even deeper issues).

This is why I’m so happy to see the resurgence of OKR’s. When used properly, they help to reframe this situation from output (features on roadmaps) to outcome (business results). I’ll say more about this topic in my next article.

There’s two special cases worth calling out here as they are such common points of stress for companies.

The first has to do with design. There’s little question that having an embedded designer on each team (that has user-facing functionality) is a huge win for the team and the customer. These designers get to truly partner with their product and engineering colleagues and are first class members of the team, and not trying to work in some form of internal agency-like model. That said, how do you ensure that each designer is not optimizing the experience for their own team’s goals, rather than for the user overall? Users could care less about your team structure. How do you encourage autonomy, yet enforce consistency?

There are different techniques for this, ranging from having a manager of design (or senior designer) review and okay the design work of each designer, to automating as much of this as possible with pattern libraries and style guides and style sheets.

In the name of empowerment and also speed, my personal preference is to invest in the necessary automation so that the team can get the design (interaction and visual) mostly right pretty easily, and acknowledge that on occasion, you will incur some “design debt” where we realize that the design needs to be corrected, and that’s fixed as soon as the problem is spotted. I like this approach because the manager of design is still responsible for developing a strong set of designers, but doesn’t have to be in the review cycle for everything (which tends to slow things way down, as well as undermine autonomy).

The second special case is company initiatives. These are those projects that necessarily span several teams. I mentioned a common one above, which is internationalization. Another common one is responsive design. Another common one is taking mobile seriously. You get the idea. Hopefully these initiatives align well with the prioritized KPI’s for each team, and there is usually an explicit OKR objective about supporting this initiative. But it’s important to acknowledge that sometimes an important initiative is not a clear and obvious win for every team. Yet if every team doesn’t do it’s part, the initiative fails. I tell teams that sometimes we just need to do our part, as part of a larger company. The consolation is that often these initiatives are really big wins for the product and the customer, so we at least can feel good about that work.

So if you have teams where they are not feeling the level of autonomy you think you’re providing them, make sure you are providing each team a very clear product vision and an unambiguous set of prioritized business outcomes. That context is their mission, and ensure they understand it, and then give them as much latitude as possible in how they accomplish their mission.