Most modern product companies are trying to work with empowered interdisciplinary product teams.
One of the prerequisites and most essential transformations to achieve this work model is to be outcome-based instead of output-based. There is a lot of information about it, like Marty Cagan’s articles or articles about the feature factory trap. Yet, today I wanted to go deeper into a critical factor to have a successful transformation: autonomy.
1. The foundation: output autonomy
The foundational outcome-driven transformation just mentioned implies that management expects teams to achieve goals, and they must have the autonomy to select with which tactics or new features they will implement to reach them.
Traditional or project-driven companies may hand teams a list of items to implement, leaving them with clearly defined deliverables. In contrast, modern product-oriented organizations define a series of results, agreed with stakeholders, and let the team organize and decide on the work needed to achieve them. Teams are closer to the users, the metrics, the technology. They are usually in a strong position to make the right decisions to achieve the desired results.
We can say that this is “level 0” autonomy: it’s the most elemental step (although many companies still struggle with it).
The role of autonomy in motivation
Deviating from our core discussion, I just wanted to emphasize the vital role of this decision independence in motivation.
Daniel Pink, with his book Drive, popularized motivation as a combination of mastery, purpose, and autonomy.
As product leaders, we usually have a small part to play in:
- Mastery: you can foster training and practice, but it mostly depends on the individual’s willingness to learn.
- Purpose: you may love and promote the company’s mission, but if team members do not share it, you won’t be able to change it.
But we can have a significant influence on giving the right context for teams to be autonomous. We can create result-oriented objectives, move the discussion with stakeholders to metrics and problems rather than features, and many more critical actions to give teams their freedom.
2. Autonomy towards strategy
Once you get past this foundational step, you can start talking about how much autonomy teams have towards strategy. And to discuss it, let me introduce the “Top-Down versus Bottom-Up dance”:
- The closer the decision is to execution, the bigger the team’s weight in the decision.
- The closer the decision is to strategy, the bigger the need to follow the top-down direction.
Why do we traditionally follow this path? Because at the strategic level, we are trying to align teams in the same direction. Some decisions teams may make to optimize their result can achieve a local maximum but not play along with the overall company’s best options.
Is this the correct approach?
I have to admit I currently subscribe to the method mentioned above. Nevertheless, we try to involve teams in strategic discussions:
- As said, teams are closer to the facts. They should be included in generating strategic insights to select the right path.
- Product Managers should create strategies for the pieces of the portfolio they are in charge of. Product leaders can engage in more fruitful conversations after gaining an understanding of each team’s strategic thoughts.
On the other hand, what can teams and product managers do if they feel they are not getting enough involvement in the strategic decisions?
- Create your strategy and show it to leaders and stakeholders, even if no one asked you to do it.
- Ask why: many times, after understanding a broader context, you can have more insights to add to the current strategy.
- Became an expert: the more knowledge you have about the user, competitors, the market, the product KPIs, the more likely it is leaders will reach out to get your thoughts on the strategy.
I would love to engage in more conversations about team autonomy, feel free to reach out to discuss it!