How do you keep shared ownership from turning into decision by committee?

Treat discussion rights and decision rights as separate operating rules. Invite broad input early, then name one person or function who will make the call, what tradeoffs they are weighing, and when the decision closes. A simple habit helps: in planning docs or meetings, label each issue with who should care, who should contribute, and who decides.

What should a team do when someone spots a real problem outside their formal area, but fixing it could disrupt priorities?

The article suggests a useful threshold: do not judge the work by implementation time alone, judge it by blast radius. If the change is contained and reversible, the person who found it can often act. If testing, release coordination, customer behavior, or roadmap tradeoffs are involved, raise it with a recommendation and let the decision owner weigh the broader cost.

How is this different from a strict DRI model where one person directly owns an area?

A DRI model is strongest when it preserves clear decision rights, but it gets brittle when people treat ownership as exclusive access to the problem. The article's three-rights framing keeps the speed benefits of a DRI while widening who can notice issues and improve the solution. In practice, that means one person can still be accountable for the call without discouraging engineers, designers, or product managers from stepping into the work earlier.

If AI expands what each discipline can do, what should managers protect so expertise does not get flattened?

Managers should protect judgment, not just output. Encourage people to prototype across boundaries, but keep review anchored in the discipline-specific questions that experience sharpens: customer impact, interaction quality, technical resilience, and business tradeoffs. Shared tools are most valuable when they increase overlap in exploration, not when they erase who is responsible for evaluating risk.

What would change in day-to-day team rituals if you took these three rights seriously?

You would design rituals to spread context before decisions are made. Engineers would sit in on support reviews, designers would look at analytics, product managers would review crash patterns, and planning conversations would make the final decider explicit. Over time, that changes ownership from 'stay in your lane' to 'bring your lens, then respect the call.'

Why Ownership is Shared

When ownership starts to matter

When you work at a startup with fewer than 20 employees, you're forced to wear many hats. The question, "Who owns this?" is usually less contentious because everyone is doing everything they can to ensure the company gets off the ground.

As the company grows, that question carries more weight. Who owns customer feedback? Reliability? Analytics? UX? Performance?

Clear ownership creates accountability. It gives people confidence that someone is responsible for moving work forward, and it reduces the chance that important problems fall through the cracks. So you need to establish a clear framework for how critical decisions get made, and who makes them. People can disagree with a decision they understand. It's much harder to work through uncertainty when nobody is sure who has the authority to make the call.

On the other hand, I've realized that when ownership gets tied too tightly to job titles, teams fragment. High-trust teams make more room for overlap, and that overlap creates less drag, not more.

I've started thinking about ownership as three separate rights because each one serves a different purpose.

The right to care helps organizations discover more customer problems.
The right to contribute leads to better solutions.
The right to decide allows teams to move quickly.

Healthy organizations exercise all three.

The right to care

Everyone should have the right to care about the quality of the product.

Imagine a new customer downloads your app, begins using it to complete an important task, and the app freezes in the middle of their workflow.

Engineering wants to understand why the application froze. Design wants to understand where the experience broke down. Product wants to know how often it happens and whether it changes the roadmap.

Everyone is looking at the same customer problem through a different lens.

The organizations I've enjoyed working in most encourage that curiosity. Engineers talk to customers. Product managers read crash reports. Designers spend time in analytics and support conversations. Nobody waits for permission to care because customer problems don't respect organizational boundaries.

The payoff is simple. Teams discover more problems earlier because more people are paying attention.

The right to contribute

Caring about a problem doesn't mean every discipline contributes in the same way.

Product contributes context around customer needs, business priorities, and tradeoffs. Design contributes an understanding of human behavior, interaction, and communication. Engineering contributes an understanding of systems, architecture, scalability, and technical constraints.

dc63121a-dbcc-4c05-9c66-2b603916c30b — Describing roles and responsibilities is never complete without a Venn diagram. 😆

The overlap is where many of the best ideas emerge.

An engineer may see a simpler workflow that changes the product approach. A designer may spot friction in a technical compromise. A product manager may build a prototype that makes an abstract idea concrete.

AI has widened that overlap. Engineers can explore different design concepts. Designers can create interactive experiences with much less technical overhead. Product managers can explore feasibility while prototyping.

I think that's a meaningful shift, but it doesn't eliminate expertise.

The value of each discipline has never been the mechanics of producing an artifact. It comes from years of developing judgment about different kinds of problems. AI expands everyone's toolbox, but it doesn't replace that judgment.

The payoff is better solutions because the team benefits from perspectives that no single discipline could provide on its own.

The right to decide

This is where shared ownership is most often misunderstood.

Broad participation only works when decision rights remain clear.

Imagine an engineer is working in an area of the codebase and finds a pre-existing bug. Sometimes the engineer should simply fix it. The change may be contained, reversible, and unlikely to displace meaningful work.

Sometimes the coding is only two hours while the testing, monitoring, release coordination, or customer impact is much larger.

A two-hour fix is not always a two-hour decision.

That's why I think it's important to separate the right to contribute from the right to decide.

The engineer absolutely has the right to care about the issue and contribute a recommendation. Product may have the broader context needed to decide whether the work changes priorities. Engineering may own the technical approach once the work is approved. Design may shape the experience if the solution changes customer behavior.

Seeing a problem creates a responsibility to raise it. It does not always create the authority to change the plan.

The payoff is speed. Clear decision rights prevent broad collaboration from turning into endless consensus.

Bringing the three rights together

I've found that the healthiest product organizations protect all three rights at the same time.

People feel empowered to care about problems outside their formal job descriptions. They contribute from the unique perspective their discipline brings, and they understand who ultimately makes the decision when meaningful tradeoffs arise.

This is where management matters. People need confidence that their manager has their back when they exercise good judgment. They also need to understand how decisions will be made when reasonable people disagree. Teams move quickly when both are true.

When I hear someone ask, "Who owns this?", I still think it's the right question. I just don't think it's the only one.

Who should care about this problem?

Who has something valuable to contribute?

Who ultimately decides?

Those questions have different answers, and that's exactly the point. Great organizations don't limit ownership to the boundaries of a role. When we do, our understanding of the business becomes fragmented. Engineering understands the systems. Product understands the customer. Design understands the experience. Everyone sees a different piece of the puzzle, but nobody sees the whole picture.

The goal is shared context.

Shared context creates better decisions because people understand not only their own discipline, but enough about the customer, the business, and the perspectives around them to make better judgments together. Clear decision rights then allow those decisions to happen quickly.

Everyone should feel responsible for improving the product. Not everyone should make every decision.

Teams with shared context know the difference between the right to care, the right to contribute, and the right to decide.