Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

The most important decision at Amazon, has been, and remains, hiring the right talent. —Jeff Bezos

the empowered team model is truly a people‐first model. You are hiring capable people and giving them the space to do remarkable things.

skill in staffing is one of the most important and telling leading indicators for a company's success.

Laszlo Bock's Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead (New York: Hachette Book Group, 2015).

Staffing is one of the three key responsibilities of management, but to be clear, it's absolutely critical to ensure competence. Without competence, the person and the team cannot expect to be trusted by management or leadership. So there is no lasting empowerment without competence.

It's not that the way we think is bad, it's that what we really need are people that think differently from us. This is one of the most tangible and immediate benefits of adding diversity to your team. The chances of solving hard problems goes up substantially if you can approach the problem from several perspectives.

Bob Sutton: The No Asshole Rule: Building A Civilized Workplace and Surviving One That Isn't (New York: Business Plus, 2007).

Check out the wonderful Code as Craft blog (www.codeascraft.com) for a very effective example

Your overarching goal is to ensure you hire competent people of character, and that every hire—at least for product managers, product designers, and tech leads—should raise the average. Note that since we have more than one engineer on a product team, it is not a problem to have a range of experience and capability levels in our engineers. However, for product managers, product designers, and tech leads—since there is just one each per team—it's critical to ensure a high standard of competence. Those are not “junior” roles.

Each person should be selected both for her competence and for her character. These should be people that a strong candidate would be proud to work with and would also enjoy getting a beer with.

always remind the interview team that we are not looking for more of the same. Innovation thrives with people who think differently. So, candidates with different education, different life experiences, different cultures, or different approaches to problem solving are highly desired.

Third, many hiring managers make the mistake of hiring primarily for domain knowledge, but for most positions—if you are hiring the right person with the right skills—she will be able to learn the domain much faster than someone with the necessary domain knowledge can learn the necessary product skills. In fact, in many cases, too much domain knowledge is more of a liability (they make the mistake of thinking they are the customer).

An excellent book to help you learn how to identify competence during interviews is Geoff Smart and Randy Street's Who: The A Method for Hiring (New York: Ballantine Books, 2008).

what is most important is that the hiring manager call the candidate, and explicitly tell the candidate that if she joins and commits to putting in the effort, then you will promise to personally invest in coaching and developing the candidate to reach her potential.

Finally, and this is often counterintuitive, in larger organizations the amount of “connecting the dots” and “managing up and across the organization” goes up considerably.

Some of that is simply a function of the number of dependencies, interactions, and resulting communication, but some is a function of the interpersonal dynamics (aka politics) of large organizations.

At Amazon, a product team has a clear mission, specific goals, and needs to be cross‐functional, dedicated, and co‐located. Why? Creativity comes from people's interactions; inspiration comes from intensive concentration. Just like a start‐up, the team huddles together in a garage, experimenting, iterating, discussing, debating, trying and retrying, again and again.

The real challenge of remote employees is when we consider the discovery work. The overall methods and mechanics are not really very different when working remotely versus co‐located for discovery work.

We still have many product ideas, and we still try them out quickly—usually by creating a prototype and then testing on real users, either qualitatively or quantitatively.

First, assess the new employee and use that assessment to create a coaching plan. Be sure to provide the time and opportunities to develop the necessary knowledge and skills, and then personally ensure the new employee is competent.

For product managers, this typically includes a series of customer visits, with an extensive debrief on the learnings afterward. The debrief covers not only the customers, but the go‐to‐market mechanisms—especially sales and marketing—and how customer service is handled. The onboarding also includes time with the finance organization learning the critical KPIs—what they mean to the business and how they are calculated.

Whatever onboarding you decide on, I strongly encourage you to have deep exposure to true users and customers at the foundation.

How are decisions made? How have they been made in the past? What is important to the company now? What are we working toward? How can I get people to trust me? What's the most important thing to do right now?

This is how we empower product people—by providing them with the information they need to succeed and then trusting them to do the right thing. Remember: we're not hiring smart product people to tell them what to do—we're hiring them to solve hard problems in ways our customers love, yet work for our business.

there should never be any performance‐related surprises in the annual review. If there are, you have failed.

see the preparation notes for the weekly 1:1 going forward, and that I would also be discussing the performance issues with the employee directly (to ensure the feedback is making it to her).

And this situation also makes clear that not everyone is cut out to be a manager. The most basic skill required for a competent manager is the willingness and ability to provide honest, timely, and constructive feedback to employees.

three to six months of trying to correct is about normal. If the problem persists, then it's time to move the focus to protecting the psychological safety of the rest of the team and organization.

the most visible and tangible sign of success as a manager was when your people were promoted.

One special case is worth calling out here, and that is when promoting an individual contributor to a people manager position. This is, of course, not just a more‐senior position, but a fundamentally different job, with very different skills and talents necessary. And it's critical that the person understand what's required and that she want the role for the right reasons.

if the people you really don't want to lose are consistently leaving, this is a real sign of a potential problem in management.

The archetype of a product manager evolves with the needs of the market. When the core driver of innovation and opportunity has been technical, then more‐technical PMs have been in favor. When mobile emerged as the next frontier, PMs with design sensibility who could build apps which could overcome the low switching costs of an App Store were prized. When the innovation frontier shifted to operations (think transportation, real estate, hospitality, grocery delivery), we came full circle to value the business orientation necessary for a PM‐as‐a‐general manager.

The product vision describes the future you are trying to create. In what ways will you improve the lives of your customers? You are not trying to explain how you will get there—that is to come from the product strategy and the product discovery work. For now, we are just trying to describe what the end state is and why it is so desirable.

Normally, the timeframe for the product vision is between 3 and 10 years out. Very complex products and devices are at the longer end of this range.

Remember: stubborn on vision, but flexible on details. Sharing the vision is fine, but sharing a roadmap is very dangerous.

Similarly, the team topology (described in Part V) is heavily impacted by the product vision and the architecture, especially for platform teams that encapsulate the underlying services. A product architecture informed by vision becomes especially critical in organizations suffering from serious technical debt.

Few things frustrate me more than an organization—struggling with serious technical debt—that finally generates the leadership support and funding to pursue a significant re‐platforming effort, yet does not have a product vision on which to base the new platform architecture. So the engineering organization is forced to make guesses about what will be needed, or else just build a new platform capable of sustaining what was built over the prior years, rather than what will be needed in the coming years.

Audrey recently published the book What CEOs Need to Know about Design.

There is a very old, very firm rule in directing: no line readings.

This is a huge no‐no and implies that either the director isn't skilled enough to get the performance she wants out of the actor, or that the best the actor has to offer is her ability to mimic the director. This is a limited example, but imagine if everyone on the cast and crew was limited by the best the director could do. It'd be a pretty weak show.

Given that goal, a director's highest responsibility is to bring to bear the best of what each team member has to offer in service of the shared goal. Rarely is the director the most highly skilled at any of the jobs that others on her team do. Of course, she must be knowledgeable so that she can appreciate, support, and grow each person on the team, but she isn't the best, and in some ways, that's the point.

The most rewarding experiences of my career have been identifying talent and aptitude in people who weren't aware of it themselves, and then convincing them that they're great at whatever the thing is.

They were a little bit terrifying to work for, for the same reason: they both believed in me in specific ways and to a degree that I frankly didn't believe in myself. But I had so much respect, admiration, and love for them that I was going to do everything I could possibly do to live up to their expectations, however misplaced I thought they were at the time!

As a leader, there's nothing better than assembling a talented cast, providing them a story they can get excited about, coaching them to reach their potential, and watching them create something special together.

Audrey Crane, What CEOs Need to Know about Design (New York: Sense & Respond Press, 2019).

For example, consider a team that has ownership of a product experience but also requires technical knowledge of one or more complex systems just to make basic changes. Such a team may struggle to gain the depth of understanding they need to innovate in their area of ownership. This high level of cognitive load works against the empowerment of the team.

We expect teams to use the tools of product discovery to explore different options and approaches before committing to a solution. And we trust the decisions they make because we know the team is in the best position to make them.

For example, a topology that divides teams strictly by technology subsystems makes it difficult for any single team to figure out a holistic solution to a real customer problem.

Ultimately, empowering teams is about enabling them to figure out the best way to achieve the necessary business outcomes. Team autonomy contributes to this.

in companies with large amounts of technical debt and/or legacy systems, teams may not be aligned with the architecture. Their work is cluttered with dependencies and complexity. Even simple tasks can take a long time, if they're even feasible at all.