by Marty Cagan
Autonomy @ Scale
Most leading tech companies have jumped on the empowered, dedicated/durable, cross‐functional, collaborative product team model I have described here, and I think they are much better for it.
The results speak for themselves, but I attribute most of the benefits to the increased level of motivation and true sense of ownership when teams feel more in control of their own destiny.
I attribute most of the benefits to the increased level of motivation and true sense of ownership when teams feel more in control of their own destiny.
However, while most leaders tell me they have empowered, autonomous teams, some of the people on those teams complain to me that they don't always feel so empowered or autonomous. Whenever this happens, I try to get to the specifics of just what it is that the team is not able to decide or where they feel constrained.
Most of what I hear falls into one of two cases:
In the first case, the team simply isn't trusted yet by management, and management is reluctant to give too long of a rope to the team.
In the second case, the team wants to change something that the leaders had assumed was part of the foundation.
In general, most teams would probably agree that there are some things that are wide open for the team to do as they think best and other areas that are part of the common foundation that all teams share.
As an example of the latter, it would be unusual for each team to select its own software configuration management tool. If the engineering team has standardized on GitHub, then that is usually considered part of the foundation. Even if one team had a strong preference for a different tool, the total cost to the organization of allowing its use would likely far outweigh any benefits.
While this might be a straightforward example, there are many others that are not so clear.
For example, should each team be able to approach test automation in its own way? Should teams be able to select the programming languages they wish to use? What about user interface frameworks? What about browser compatibility? How about expensive features like offline support? How about the flavor of Agile they wish to use? And does every team really need to support several company‐wide product initiatives?
As is so often the case with product, things boil down to a tradeoff—in this case between the team's autonomy and leverage of the foundation.
I will also confess here that, while I love the core notion of autonomous, empowered teams, I am also a big fan of investing in a high‐leverage foundation. This means building a strong foundation that all teams can leverage to create amazing products and experiences much faster than they would otherwise.
For the record, I do not believe that there is one answer to this question. The best answer is different for each company, and even for each team, and the best answer is also a function of the company's culture.
Here are the key factors to consider:
Team Skill Level
There are roughly three team skill levels: (1) A team—an experienced team that can be entrusted to make good choices; (2) B team—these people have the right intentions but may not have the level of experience necessary to make good decisions in many cases and may need some assistance; and (3) C team—this is a junior team that may not even know what they don't know yet. These teams can unintentionally cause substantial issues without significant coaching.
Importance of Speed
One of the main arguments for leverage is speed. The logic goes that teams should be able to build on the work of their colleagues and not spend time reinventing the wheel. However, sometimes it's simply an accepted and acknowledged cost of empowerment to allow teams to potentially duplicate areas or proceed slower in the name of autonomy. Other times, the viability of the business depends on this leverage.
Importance of Integration
In some companies, the portfolio is a set of related, but largely independent, products in which integration and leverage is less important. In other companies, the portfolio is about a set of highly integrated products in which integration leverage is critical. This boils down to whether the team should optimize for its particular solution or optimize for the company as a whole.
Source of Innovation
If the main sources of future innovation are necessary at the foundation level, then there will need to be more freedom for teams to revisit core components. If the main sources of innovation are expected to be at the solution level, then the company needs to encourage less revisiting of the foundation and, instead, focus the creativity on application‐level innovations.
Company Size and Locations
Many of the problematic issues with autonomy arise because of issues of scale. As companies grow, and especially as companies have teams in disperse locations, leverage becomes both more important and more difficult. Some companies try to deal with this with the center of excellence concept in which leverage is focused on teams in a physical location. Others try stronger holistic roles. Yet others add process.
Company Culture
It is also important to acknowledge the role that an emphasis on autonomy versus leverage plays in team culture. The further on the spectrum that the company pushes toward leverage, the more this can be perceived by the teams as chipping away at their level of autonomy. This may be acceptable for B‐ and C‐level teams but more problematic for A‐level teams.
Maturity of Technology
One frequent problem is to try to standardize on a common foundation prematurely. The foundation isn't yet ready for prime time, in the sense of the leverage it is designed to provide. If you push too hard on leverage before the foundation is ready, you can truly hurt the teams that are counting on this foundation. You're building a house of cards that may collapse at any time.
Importance to Business
Assuming the foundation is solid, there's likely more risk in a team not leveraging that foundation. This might be fine for some areas, but with products or initiatives that are business critical, it becomes a question of which battles to pick.
Level of Accountability
Another factor is the level of accountability that goes along with the empowerment and autonomy. If there's no accountability—and especially if you don't have strong A teams—there's little reason for the teams to stress about these tradeoffs. But you want the teams to stress over these tradeoffs. If I believe the team is strong and they fully understand the consequences and risks, and yet they still feel they need to replace a key component of the foundation, then I tend to side with that team.
As you can see, there are no lack of considerations in the tradeoff between autonomy and leveraging the foundation. But, I find if you discuss these topics openly, most teams are reasonable. Sometimes, just a few key questions about some of the implications can help teams make better decisions regarding this tradeoff.
If you find that teams are consistently making poor decisions in this regard, you may need to consider the experience level of the people on the team, but most likely, the teams are missing the full business context.
The critical context is comprised of two things:
The overall product vision
The specific business objectives assigned to each team
We will discuss both of these key topics in the coming chapters. 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.
Note that while the product vision and the team‐specific business objectives are provided to the team by leadership as part of the context, nothing is said about how to actually solve the problems they are assigned. That's where the team has the autonomy and flexibility.
CHAPTER 21
Profile: Lea Hickman of Adobe
For startups or smaller companies, often all it takes is a strong product team with a strong product‐oriented CEO or product manager. But, in larger companies, it usually takes more than t
hat. It takes strong product leadership, in the very best sense of the word, including providing a compelling product vision and strategy.
One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and financially successful company. It's easier in many ways if the company is in serious trouble, and it is feeling big pain, because that pain can be used to motivate the change.
Of course, great companies want to disrupt themselves before others disrupt them. The difference between Amazon, Netflix, Google, Facebook, and the legions of large but slowly dying companies is usually exactly that: product leadership.
In 2011, Lea Hickman led product for Adobe's Creative Suite. Lea had spent several years at Adobe helping them to build a very large and successful business for itself—on the order of $2 billion in annual license revenue—with its desktop‐based Creative Suite.
One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and financially successful company.
But Lea knew the market was changing, and the company needed to move from the old desktop‐centric, annual‐upgrade model, to a subscription‐based model supporting all the devices designers were now using—including tablets and mobile in all their many form factors.
More generally, Lea knew that the upgrade model was pushing the company to take the product in directions that were not good for Adobe customers and not good in the long term for Adobe. But change of this magnitude—revenue from Creative Suite was roughly half of Adobe's overall $4 billion in annual revenue—is brutally hard.
Realize that every bone and muscle in the corporate body works to protect that revenue, and so a transition of this magnitude means pushing the company far outside it's comfort zone. Finance, legal, marketing, sales, technology—few in the company would be left untouched.
You can start with the typical concerns:
The finance staff was very worried about the revenue consequences of moving from a license model to a subscription model.
The engineering teams were worried about moving from a two‐year release train model to continuous development and deployment, especially while assuring quality. They were also concerned that responsibility for service availability was now going to be much higher.
The sales side expected that this transition would change the way the Creative Suite products were sold. Rather than a large reseller channel, Adobe would now have a direct relationship with their customers. While many people at Adobe generally looked forward to this change, the sales organization knew that this was risky because if things didn't work out well, the channels would probably not be forgiving.
And don't underestimate the emotional changes—to both customers and sales staff—of moving from owning software to renting access to software.
With more than a million customers of the existing Creative Suite, Lea understood the technology adoption curve and that a segment of the customer base would strongly resist a change of this magnitude. Lea understood that it's not just about whether the new Creative Cloud would be better, it would also be different in some meaningful ways. Some people would need more time to digest this change than others.
Realize also that the Creative Suite is, as the name implies, a suite of integration applications—15 major ones and many smaller utilities. So, this meant that not just one product had to transform, but the full suite needed to transform, which dramatically increased the risk and complexity. It is any wonder that few companies are willing to tackle a product transformation of this magnitude?
Lea knew she had a tough job in front of her and her teams. She realized that, for all of these interrelated pieces to be able to move together in parallel, she needed to articulate clearly a compelling vision of the new whole as greater than the sum of the parts.
Lea worked with Adobe's then‐CTO, Kevin Lynch, to put together some compelling prototypes showing the power of this new foundation and used this to rally executives and product teams.
Lea then began a sustained and exhausting campaign to communicate continuously with leaders and stakeholders across the entire company. To Lea, there was no such thing as over‐communication. A continuous stream of prototypes helped keep people excited about what this new future would bring.
Because of the tremendous success of the Creative Cloud—as of this writing, Adobe generated more than $1 billion in recurring revenue faster than anyone else has—Adobe discontinued new releases of the desktop‐based Creative Suite to focus their innovation on the new foundation. Today, more than 9 million creative professionals subscribe to, and depend on, the Creative Cloud. Thanks, in large part to this transition, Adobe has more than tripled the market cap it had before the transition. The company today is worth roughly $60 billion.
It's easy to see how big companies with lots of revenue at risk would hesitate to make the changes they need to not only survive but thrive. Lea tackled these concerns and more head‐on with a clear and compelling vision and strategy and clear and continuous communication to the many stakeholders.
This is one of the most impressive, nearly superhuman examples I know of a product leader driving massive and meaningful change in a large enterprise company. There's no question in my mind that Adobe would not be where it is today without someone like Lea working tirelessly to drive this change through.
And I'm very happy to say that today Lea is a partner at Silicon Valley Product Group, helping other organizations through the transformation to modern product practices.
PART III
The Right Product
In Part Two, we considered the people—looking at the structure and roles of strong product teams. In Part Three, we explore how to determine what the product team should be working on.
Product Roadmaps
Overview
Now that we've got some strong product teams, we need to answer this fundamental question: What should our product team work on?
For most companies (especially those described in Chapter 6, “The Root Causes of Failed Product Efforts”), that's not a question the teams have to worry much about because they are usually handed down the things to work on in the form of a product roadmap.
One of the key themes of this book is focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results.
Most of the product world has the same definition for product roadmap, but there are a few variations. I define product roadmap as a prioritized list of features and projects your team has been asked to work on. These product roadmaps are usually done on a quarterly basis, but sometimes they are a rolling three months, and some companies do annual roadmaps.
In some cases, product roadmaps come down from management (usually referred to as a stakeholder‐driven roadmap) and sometimes the roadmap comes from the product manager. They don't usually include little things like bugs and optimizations, but they do normally contain the requested features, projects, and big, multi‐team efforts often called initiatives. And they typically include due dates or at least time frames for when each item is expected to be delivered.
Management knows that many parts of the company need things from the product organization; yet, we are rarely staffed to be able to do everything that's needed. So, management may help mediate this battle over the constrained resources. That's where stakeholder‐driven roadmaps are especially common.
Typical roadmaps are the root cause of most waste and failed efforts in product organizations.
Management has fair reasons for wanting product roadmaps:
First, they want to be sure you're working on the highest‐value things first.
Second, they are trying to run a business, which means they need to be able to plan. They want to know when key capabilities will launch so they can coordinate marketing programs, sales force hiring, dependencies with partners, and so on.
These are reasonable desires. Yet, typical roadmaps are the root cause of
most waste and failed efforts in product organizations.
Let's explore why product roadmaps are such a problem, and then let's consider the alternatives.
CHAPTER 22
The Problems with Product Roadmaps
Even with the best of intentions, product roadmaps typically lead to very poor business results. I refer to the reasons for this as the two inconvenient truths about product.
The first inconvenient truth is that at least half of our product ideas are just not going to work. There are many reasons for a product idea to not pan out.
Sometimes customers just aren't as excited about this idea as we are, so they choose not to use it or buy it (the value isn't there). This is the most common situation.
Sometimes they do want to use it, and they try to use it, but it's so complicated that it's simply more trouble than it's worth, which yields the same result—the users don't use it (the usability isn't there).
Sometimes the issue is that the customers might have loved it, but it turns out to be much more involved to build than we first thought, and we simply can't afford the time and cost to deliver (the feasibility isn't there).
The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.