Empowered: Ordinary People, Extraordinary Products

by Marty Cagan

So many companies still have the old IT mindset when it comes to technology. It's viewed as a necessary cost rather than the core business enabler it needs to be. The people who work on the technology teams are literally there “to serve the business,” and the technology managers and leaders are there to facilitate serving the business. Or it's shoved off to the side in some “digital” business unit. The technology teams are disconnected from the real customers—in fact, they're encouraged to think of their stakeholders as their customers.

Whereas mentors dole out words of wisdom, coaches roll up their sleeves and get their hands dirty.

It's amazing and distressing how few managers actually subscribe to this principle—that developing people is job #1. Most say the right things about the importance of the team, but their actions tell a very different story. They see their accountability for aggregate product outcomes as their most important job and treat their teams as a means to an end.

you will find it very hard to retain strong people when they have so little sense of ownership over their work. Empowering means creating an environment where your people can own outcomes and not just tasks.

The insecure manager is so worried about being recognized for their contribution, they can see their team's success as a threat to that recognition, rather than the confirmation of the contribution that it truly is. They may deal with this by closely controlling how the team works, or by controlling the team's visibility to leadership. Truly bad managers may actively undermine their own team.

An insecure manager may suppress opinions that are different from her own.

Instead of looking at product as just a part of the technology organization (or worse, the IT organization), they need to think about product as the organization. I am not talking about power structure or even org structure. I am talking about how product needs to be the value driver of the organization as opposed to just a feature factory for the rest of the organization.

if the executive team isn't on board with this product operating model, the chances of successful transformation are slim.

Certain executives have the skills and personality to drive the necessary change, and others don't. The leader's behaviors can make or break the ability of an organization to transform to a true product culture.

Empowered engineers are the single most important thing that you can have in a company. —Bill Campbell In your journey to empowered teams, if I had to pick just one concept from this entire book that I hope you would take to heart, it would be the idea of an empowered engineer.

the best single source for innovation is your engineers (because they're working with the enabling technology every day, so they're in the best position to see what's just now possible). The product vision is intended to attract and inspire these engineers. The product strategy is intended to ensure these engineers are working on the most important problems.

just letting your engineers decide how to code a solution is not what is meant by empowerment. Of course, they need to decide how to implement the solution. Letting your engineers determine the architecture is also not what is meant by empowerment. Of course, they also need to be able to decide the architecture. Empowerment of an engineer means that you provide the engineers with the problem to solve and the strategic context, and they are able to leverage technology to figure out the best solution to the problem.

You will hear: “My engineers are not interested in anything but coding.” This is by far the most common excuse from people that don't understand empowered teams. I have heard it countless times, mostly when I ask a product manager or product designer why their engineers aren't participating in the product discovery work. The first thing I should acknowledge is that occasionally this is true, and I'll come back to this situation later. But in my experience, this is the exception.

sometimes the engineers do tell me they don't really care much about discovery. They prefer to code and are fine building “whatever.” In this case, I ask them to tell me the last time any of the engineers were able to personally visit with a customer. The answer is usually between “a very long time ago” and “never.”

You have designed your team topology to optimize for empowerment and autonomy. The people on your product teams feel real ownership over a meaningful piece of the larger whole, and they understand how and when to work with their colleagues on other teams to collaborate on larger problems.