Why Empowerment Fails
Empowered product teams are at the heart of the Product Operating Model. Instead of being handed features to build, teams are given meaningful problems to solve and outcomes to achieve. The people closest to the work, with direct access to customers, data, and technology, are trusted to figure out how best to create value.
There are good reasons why so many organizations are trying to move in this direction. In complex environments, the people making decisions need access to information that is difficult to capture in a requirements document or pass through layers of management. Customer needs change, technology creates new possibilities, competitors move, and most product ideas simply don't work as expected. The faster teams can learn and adapt, the better their chances of creating real customer and business value.
This becomes even more important as AI dramatically reduces the cost of building software. If we can build more things faster, deciding what is worth building becomes more important, not less. Organizations need teams that can understand customers, discover opportunities, evaluate evidence, make trade-offs, and adapt their approach as they learn. Simply becoming better at executing somebody else's ideas will not be enough.
There is a human argument for empowerment as well. People tend to be more engaged when they understand why their work matters, can develop mastery, and have meaningful influence over how they achieve their goals. Most talented people don't want to spend their careers translating tickets into software or waiting for somebody higher up the hierarchy to make decisions they are perfectly capable of making themselves. Empowerment can create better conditions both for performance and for people to grow.
So the case for empowered teams is compelling. Yet actually creating them turns out to be surprisingly difficult. We regularly meet organizations where teams have been told that they are empowered, but little else has changed. They may now be accountable for outcomes, while strategy and priorities remain unclear. Leaders ask them to "do more discovery", but teams lack the skills, customer access, data, or time to do it well. Teams are expected to take ownership, while roadmaps, solutions, budgets, and important decisions are still controlled elsewhere. Stable teams may have been created, while organizational silos, dependencies, incentives, governance, and legacy architecture continue to make local ownership extremely difficult.
The results are predictable. Some teams wait for decisions and escalate anything important. Others enthusiastically exercise their new freedom but pull in different directions. Some struggle with the ambiguity and ask leaders to tell them what to do. Highly capable teams can become frustrated when they see what needs to happen but aren't allowed to act. Leaders, meanwhile, see inconsistent decisions, slow progress, or poor results and conclude that the organization isn't "ready" for empowerment. Control gradually moves back up the hierarchy.
We think part of the problem is a deceptively simple misunderstanding: empowerment is often treated as if it were synonymous with autonomy.
Autonomy is the freedom to make decisions. It is an important part of empowerment, but freedom alone is not enough. A team can have enormous autonomy and still be poorly equipped to succeed. If people don't understand the direction, don't have the necessary capabilities, or work in an environment that constantly gets in their way, simply giving them more freedom may create anxiety, misalignment, poor decisions, or paralysis rather than ownership.
Conversely, a team may have deep expertise, excellent understanding of its customers and business, and a clear sense of what needs to be done, but still lack meaningful authority. Giving such a team detailed instructions and requiring approval for every important decision doesn't make the organization safer. It wastes time, information, capability, and motivation.
For us, empowerment means creating the conditions in which people and teams can successfully use autonomy to own meaningful outcomes. It is not about maximizing freedom or simply "letting go". It is about matching autonomy with what people need in order to use it well, and then continuously developing those conditions as teams grow.
Autonomy without those conditions isn't empowerment. At its worst, it is abandonment.
From Giving Control to Creating the Conditions for Control
Our thinking about empowerment owes a lot to David Marquet and his work on Intent-Based Leadership. In Turn the Ship Around!, Marquet tells the story of taking command of the USS Santa Fe, then one of the poorest-performing submarines in the US Navy, and gradually replacing the traditional leader-follower model with a leader-leader model. Instead of trying to make better decisions for his crew, he worked to create an organization in which people throughout the submarine could make good decisions themselves.
A central idea in Marquet's work is to give control, moving decision-making authority to where the information is. But this does not mean simply stepping back and hoping for the best. Giving control safely depends on two other things: competence and clarity. People need the technical and professional capability to make good decisions, and they need sufficient understanding of the organization's purpose and direction, including their leader's intent, to make decisions that contribute to the whole without being told exactly what to do.
This distinction matters enormously for product organizations. A product team cannot meaningfully own an outcome simply because someone declares that it does. If the team doesn't understand the strategy, customer problem, desired outcomes, priorities, or important constraints, increased autonomy can lead to teams optimizing in different directions. If the team lacks product, design, technical, discovery, or business competence, giving it responsibility for complex decisions may produce poor results or make people reluctant to make those decisions at all. And if clarity and competence are strong but every meaningful decision still needs approval somewhere else, all that capability is wasted.
We have found Marquet's three dimensions of Clarity, Competence, and Control extremely useful in our work with product organizations. But there is another recurring pattern that the three dimensions alone don't make sufficiently visible.
Imagine a highly capable team. They understand their mission, their customers, and the outcomes they are trying to achieve. Their leaders genuinely trust them and want them to take ownership. Yet making even a small change requires coordination with five other teams. The architecture makes independent releases difficult. Funding is organized around temporary projects. Customer contact is mediated through several layers of the organization. Performance targets reward local output rather than shared outcomes. Calendars are filled with coordination meetings, and failure is something people learn to avoid rather than learn from.
Technically, the team may have Clarity, Competence, and even permission to exercise Control. In practice, exercising that control is slow, costly, or risky.
This is why we add a fourth C: Context. Context is the system around the team. It includes organizational design, team topology, architecture, dependencies, funding models, incentives, processes, tooling, access to customers and data, psychological safety, and the countless other environmental conditions that shape how people actually behave. Leaders can tell people to collaborate, experiment, take ownership, and move quickly, but if the surrounding system makes those behaviors difficult, the system usually wins.
That gives us the four dimensions we now use when thinking about empowered product work:
- Clarity: Do we understand what we are trying to achieve, why it matters, and the boundaries within which we can act?
- Competence: Do we have the capability and judgment to solve it well?
- Control: Do we have the authority and trust to act?
- Context: Does the environment make empowered behavior easier or harder?
We call this the 4C Model for Empowered Product Work. It is not intended as a replacement for Marquet's model. Rather, it is our adaptation of his thinking to the realities we repeatedly encounter in product organizations, with Context made explicit to bring organizational and system design into the empowerment conversation. Together, the four Cs help us look beyond autonomy and examine the conditions that make meaningful ownership possible.
The Four Cs of Empowered Product Work
The four Cs are simple enough to remember, but each represents more than its one-word label might suggest. Let's look more closely at what each means for empowered product work.
Clarity: Do we understand what we are trying to achieve, why it matters, and the boundaries within which we can act?
Clarity starts with understanding what we are trying to achieve and why it matters. A team needs a compelling direction, a current, evidence-informed understanding of the customer and business problems worth solving, meaningful outcomes to pursue, and a shared understanding of how it will know whether it is making progress and creating the intended value. Product vision, strategy, priorities, measures of success, and clarity about what evidence should inform decisions all contribute to this.
But clarity is also about boundaries. What decisions belong to the team? What constraints are real? What trade-offs are acceptable? What should be escalated? What is explicitly outside the team's scope? Clear guardrails can enable autonomy because teams don't need to ask for permission every time they approach an invisible boundary.
There is also clarity in how the organization expects product work to happen. If nobody can explain how opportunities are identified, how discovery and delivery fit together, how evidence informs decisions, how priorities are changed, or how decisions get made, people will invent their own interpretations or fall back on familiar ways of working. Clarity doesn't mean prescribing a detailed process. It means providing enough shared understanding that decentralized decisions can still add up to a coherent whole.
Competence: Do we have the capability and judgment to solve it well?
Empowerment asks more of people than following instructions does. When teams own problems and outcomes rather than tasks and features, they need to make judgments about customers, technology, business value, risk, evidence, and trade-offs. That requires craft skills, but competence in empowered product work is much broader than mastery of a particular discipline.
A competent product team needs the ability to discover and deliver value, learn from customers, data, and other evidence, collaborate across disciplines, run experiments, make sound product and technical decisions, and understand the business consequences of its choices. It also needs people who are willing to take ownership, hold themselves and each other accountable, and widen their perspective beyond "my part of the job".
This is why competence develops through more than training. Coaching, mentoring, pairing, deliberate practice, feedback, reflection, and exposure to increasingly difficult real problems all matter. As people grow, their impact can widen from being excellent individual contributors, to making their team better, to contributing across a product area, and eventually to shaping the wider organization.
Control: Do we have the authority and trust to act?
Control is perhaps the least intuitive word in a model about empowerment, but we use it deliberately, following Marquet. The question is not whether control exists. It always does. The question is where it sits.
A team can have excellent clarity and competence while still being little more than a delivery function if somebody else decides which problems matter, chooses the solutions, sets the priorities, controls customer access, or requires approval for every consequential decision. Accountability without corresponding control is particularly corrosive. Being told that you "own the outcome" means little if you don't control enough of the decisions that determine it.
Giving control means moving meaningful decision-making authority closer to the people with the relevant information. It means giving teams real problems rather than pre-solved solutions, allowing them to make trade-offs within clear boundaries, and trusting them to act without constantly seeking permission. It does not mean that every team decides everything. Good empowerment makes decision rights explicit and creates clear escalation paths for decisions that genuinely belong elsewhere.
Context: Does the environment make empowered behavior easier or harder?
Context is everything around the team that shapes what is realistically possible. This includes organizational design and team topology, architecture and technical debt, dependencies, funding and planning models, incentives and KPIs, processes and governance, tooling and access to data, meeting structures, psychological safety, and organizational culture.
Context matters because behavior that looks like a people problem is often a system problem. We can ask teams to take end-to-end ownership while designing an organization that requires six teams to deliver anything meaningful. We can encourage experimentation while making releases expensive and risky. We can ask people to optimize for customer outcomes while rewarding departments for hitting local output targets. We can tell teams to collaborate while dividing ownership in ways that turn collaboration into handoffs between internal customers and suppliers.
Good context doesn't remove every constraint. Constraints are inevitable, and some are useful. The goal is to shape an environment in which the behavior we want becomes easier rather than requiring heroic effort. Stable teams, coherent areas of ownership, fewer dependencies, useful feedback loops, aligned incentives, psychological safety, and technical environments that support fast learning all make empowerment more viable.
Diagnose the conditions, not the behavior
One reason we find the four Cs useful is that the same visible behavior can have very different underlying causes.
Imagine a team that has formally been given authority to make a decision, but keeps coming back to its leader for approval. It would be easy to conclude that the team doesn't want to be empowered. Perhaps they are simply too passive or afraid of accountability.
But consider what else might be happening.
They may lack Clarity about the strategy, boundaries, or criteria for making a good decision. They may lack Competence, or simply confidence in their still-developing judgment. They may nominally have Control, while experience has taught them that the leader will second-guess important decisions anyway. Or the Context may make taking responsibility personally risky because mistakes are remembered, blamed, and punished.
A team member might quite rationally think: If I propose an idea and it turns out to be wrong, that's my fault. If you tell me what to do, or even just approve my idea, then it's your fault.
The resulting behavior looks the same in every case: "Please approve this." But what needs to change may be very different.
This is why the four Cs are not primarily categories for sorting problems. They are lenses for understanding what might be causing them. Before diagnosing people as unwilling to take ownership, we should diagnose the conditions in which we're asking them to do so.
Don't Declare Empowerment
Empowered teams cannot simply be declared into existence. Changing reporting lines, introducing product teams, or telling leaders to "let go" may create more space for autonomy, but autonomy alone is not empowerment. Teams also need the Clarity, Competence, Control, and Context to use that autonomy successfully.
This changes the leadership question. Instead of asking whether a team is empowered, or why people won't take more ownership, we can ask: what would need to be true for this team to safely own more? The answer may involve greater clarity or competence, genuinely moving decision-making authority, changing the surrounding context, or some combination of all four.
Creating these conditions is not a one-time organizational design exercise. They need to develop as teams take on increasingly difficult problems and greater responsibility. In future articles, we'll explore what this means in practice, both for leaders helping teams develop greater ownership and for organizations creating the context in which they can thrive.
Great product work is rarely heroic. It is systemic.