Who Owns This? Sharing Responsibility When You Are Used to Owning Everything
For a long time, the answer to “who owns this?” at my company was always the same person. Me. Every roadmap call, every architectural decision, every release that went out, every bug that came back. If a plugin shipped something wrong, it was my fault, because in a real sense I had touched or approved almost all of it. That felt responsible. It also quietly became the ceiling the whole company kept hitting.
We run several products now. BuddyNext, WPMediaVerse, Jetonomy, and more, with free and pro editions across most of them. You cannot run that many products the way you run one, where the founder is the final quality check on everything. The math does not work. There are only so many hours, and the more products you add, the thinner that single point of judgment spreads until it stops being judgment and becomes a rubber stamp with a queue behind it.
So the real question stopped being “who owns this?” and became “how do I let other people own this without the quality falling apart?” That is the dilemma this post is about. Not the emotional side of letting go, which I wrote about separately in why the founder has to stop coding and start leading, and not the mechanics of getting people to your bar, which is its own piece on training a team that ships without you. This one is about structure: how responsibility is actually shared across people and products, and how you keep consistency while giving away control.
Delegating tasks is not delegating ownership
The first mistake I made, and I think most technical founders make, is confusing task delegation with ownership. They are not the same thing, and the gap between them is where most “I tried to delegate and it did not work” stories come from.
Delegating a task is handing someone a defined unit of work with the decision already made. Build this screen. Fix this bug. Add this endpoint. The person does the work, you review it, and the judgment stays with you. This scales your hands. It does not scale your head. You are still the bottleneck for every decision, and the person doing the work never develops the judgment to make those decisions, because you never let them.
Delegating ownership is handing someone the decision itself, along with the outcome. You own the moderation experience in this product. You decide what good looks like there, you decide the roadmap for it within our standards, and when it breaks at 2am it is your name on it. That is a different thing entirely. It is uncomfortable, because the person will make calls you would not have made. Some of those calls will be worse than yours. A few will be better. And the only way to find out which is to actually let them make the call and live with the result.
I resisted this for years without admitting that is what I was doing. I told myself I was delegating, but what I was really doing was handing out tasks and keeping every decision. The tell was simple: nothing shipped without me looking at it, and nobody on the team could finish a sentence about the product roadmap without checking what I thought first. That is not a team. That is a set of very capable hands attached to one person’s head.
What “owning a plugin” should actually mean
When I say someone owns a plugin or a surface, I mean something specific, not a vague sense of caring about it. Ownership is a bundle of real responsibilities, and if you hand over the title without the bundle, you have given someone a label instead of a job.
Owning a product or a major surface means:
- Roadmap input that carries weight. The owner proposes what gets built next and why, based on what they see in support, usage, and competitors. They do not get to ignore company direction, but their proposal is the starting point, not an afterthought.
- Quality of that surface. If the feature demos beautifully and breaks at scale, that is on the owner. They run it against the large-database bar before it ships, not after a customer finds the problem.
- The on-call for its bugs. When something in their area breaks, they are the first responder. Not the person who escalates it to me and waits. The person who reproduces it, finds the root cause, and decides the fix.
- The customer reality of that surface. They read the tickets for their area. They know what real site owners struggle with, because you cannot own quality you never see used.
That last point matters more than it looks. An owner who never reads support for their own feature is not really an owner, because they are making decisions blind. Ownership without exposure to consequences is just a title.
Decision rights: the part nobody writes down
The thing that made shared ownership actually work, after a lot of friction, was writing down decision rights. Not in a heavy process document, but in a plain understanding of what each role decides alone, what they consult on, and what they escalate. Most delegation fails because this is never made explicit. The owner assumes they can decide something, the founder assumes they will be asked, and both are surprised.
Here is roughly how decision rights sit across the roles in a small product company like mine. The exact lines will differ for you, but the shape is the point.
| Decision | Product owner | Founder / lead | Whole team |
|---|---|---|---|
| Feature priority within a product | Decides | Consults on strategy | Informed |
| UX and copy for a surface | Decides | Rarely overrides | Informed |
| Public API shape and naming | Consults | Decides | Consults |
| Architecture pattern (tables, models, seams) | Consults | Decides (standard) | Informed |
| Pricing and free-vs-pro split | Consults | Decides | Informed |
| Security-sensitive change | Escalates | Decides | Informed |
| Release go or no-go for their product | Decides | Sets the gate | Informed |
| Anything that changes a shared standard | Escalates | Decides | Consults |
The value of a table like this is not the specific rows. It is that the owner can look at it and know, without asking, whether a given decision is theirs. “Decides” means they make the call and do not need permission. “Consults” means they must talk to the named person first, but the decision is still shared. “Escalates” means it is not their call, and pretending it is will cause a problem.
Once this was clear, the number of decisions that came to me dropped hard, and the ones that still came to me were the ones that genuinely should. That is the goal. You are not trying to remove yourself from every decision. You are trying to remove yourself from the decisions other people can make as well as you, so you have room for the ones only you can.
Autonomy versus consistency, and how to get both
The fear that keeps founders from sharing ownership is consistency. If ten people own ten surfaces and each decides for themselves, does the product turn into ten different products bolted together? It can. I have seen it happen, in our own work and in others. One screen uses one pattern, the next screen re-invents it, and six months later you have a codebase that argues with itself.
The answer is not to take ownership back. The answer is to be very clear about the small set of things that are never owned locally, and very generous about everything else. Autonomy and consistency are not opposites if you draw the line in the right place.
What stays centralized, forever, no exceptions:
- Architecture standards. How data access works, where business logic lives, what a model is allowed to do. An owner does not get to invent a new way to talk to the database because it was faster for their feature. This is the rule that keeps the codebase one codebase.
- The big-site readiness bar. Every list, grid, and query works at real scale on day one. Pagination, indexes, no per-row queries in a loop. This is not negotiable per product, because a slow query in one plugin is a slow site for the customer regardless of who owns it.
- Security. Input handling, capability checks, the boundaries where trust changes hands. Nobody owns the right to weaken these.
- Release quality gates. What has to pass before anything ships. The gate is the same for every product, because customers do not grade our products on a curve based on who built them.
Everything above is the spine. It does not move, and it does not get a local exception. Everything else, the actual features, the UX, the roadmap, the copy, the day-to-day judgment, can and should be owned locally. When the spine is genuinely fixed and genuinely small, autonomy stops threatening consistency, because the parts that must match are enforced by the standard, not by me watching.
The mistake is drawing the centralized set too wide. If everything is a standard, nothing is owned, and you are back to being the bottleneck with extra paperwork. Keep the spine small enough that people can hold all of it in their head, and let them own the rest.
Making accountability real without a blame culture
Ownership without accountability is just permission. If an owner can make a call, watch it go wrong, and face nothing, then they have authority without responsibility, and that is worse than no delegation at all, because now bad decisions have a fast path to production.
But accountability curdles into blame very easily, and blame kills ownership faster than anything. If the message people hear is “you own this so it is your fault,” they will quietly stop making decisions, because the safest decision is always to escalate it to you and let it be your fault instead. You will have destroyed the thing you were trying to build.
The way I try to hold both is to separate the decision from the outcome. An owner is accountable for making a considered decision, exposing it to the standards, and owning the cleanup when it goes wrong. They are not blamed for the fact that a reasonable decision sometimes has a bad outcome. Those are different things. A good decision with a bad result is a normal part of building. A careless decision, or one that skipped the standards, is the actual failure, and that is the one that gets a hard conversation.
In practice, accountability looks like this: when something breaks in an owned area, the owner runs the response and then tells the rest of us what happened, what the root cause was, and what changed so it does not happen again. Not to be judged. To close the loop and so everyone learns. The tone is “what did this teach us,” not “whose fault was this.” Do that consistently and people take more ownership over time, because they learn that owning a mistake is survivable and even respected. Get the tone wrong once or twice and everyone retreats to task-taking.
The multi-actor problem: when everyone thinks someone else has it
There is a specific failure that shows up the moment more than one person can act on the same thing, and it is worth naming because it catches teams off guard. Two people both think the other one handled it, and nobody did. The bug sits unassigned because it touches two areas. The customer waits because the ticket looks like it belongs to the other team. The release slips because each side assumed the other owned the final check.
This is the shadow side of shared ownership. When only I owned everything, this never happened, because there was never any ambiguity about who was responsible. The instant you share ownership, the seams between owners become the dangerous places, exactly the spots where responsibility is unclear.
The fix is not more meetings. It is making sure every important thing has exactly one owner, even when it spans areas. Shared ownership of a surface is fine. Shared ownership of a specific outcome is a trap, because shared responsibility for one thing usually means nobody’s responsibility. When something crosses two areas, we name a single owner for that thing, and the other person is explicitly the consult, not a co-owner. One name on it. Always one name.
The same discipline applies inside the software. When two people, or two automated processes, can both act on the same record, the interface has to handle the case where it was already handled. The person acting on stale information should be told it already changed, not allowed to quietly overwrite someone else’s work. The organizational version and the code version of this problem are the same problem, and both are solved by removing the ambiguity about who acts.
Ownership across free and pro, and across product lines
Our products are not islands. Most have a free edition and a pro edition, and they share standards, sometimes code, across the whole line. That complicates ownership, because a decision in one place can ripple into several.
The rule that keeps this sane is that shared things have a single owner, and product owners consume the shared thing rather than each re-inventing it. If there is a standard for how free and pro split responsibilities, one person owns that standard, and every product follows it. A product owner does not get to quietly re-author the shared resolver, the shared design token, or the shared capability because it was convenient for their case. If the shared thing does not fit, they raise it with the owner of the shared thing, and it either changes for everyone or there is a documented reason it does not.
This is the same principle as the architecture spine, applied to code that crosses products. The tell that it is being violated is duplication: the same logic, the same list, the same value, re-authored in a second place because someone could not or did not want to change it at the source. When you see that, you do not have shared ownership, you have parallel ownership drifting apart, and it will cost you later when the two copies disagree.
So ownership across product lines has two layers. Each product has an owner for its own surfaces. The shared foundation has its own owner. And the deal is that product owners get full autonomy on top of the shared foundation, but they do not get to fork the foundation quietly. Change it at the source or live with it, and never grow a second copy.
How I would start if I were doing this again
If I were starting the transition from owning everything to sharing ownership today, knowing what I know now, I would do it in this order.
First, write down the spine. The small set of standards that are never owned locally. Keep it short enough to hold in your head.
Second, pick one product or one surface and give it a real owner, with the decision rights written down. Not a task-taker. A decider. Resist the urge to review every call they make.
Third, let them make a decision you disagree with, and let it play out, as long as it does not cross the spine. This is the hardest step and the one that actually builds ownership. If you override the first decision they make, you have taught them that ownership is fake.
Fourth, when something goes wrong in their area, run the loop: they respond, they explain the root cause, everyone learns, nobody is blamed for a reasonable call. Do this consistently.
Fifth, expand. Add owners for more surfaces once the pattern holds. Keep the spine fixed and small as you go.
None of this is fast, and none of it is comfortable. But the alternative is a company that can never be larger than one person’s attention, and that is not a company, it is a very busy job with employees.
Frequently asked questions
What is the difference between delegating a task and delegating ownership? A task is a defined unit of work with the decision already made; you keep the judgment. Ownership is handing over the decision and the outcome. Task delegation scales your hands. Ownership scales your judgment, because the owner develops it by actually deciding.
How do I keep quality consistent if lots of people own different parts? Fix a small spine of standards that are never owned locally: architecture patterns, the large-database bar, security, and the release gates. Enforce those centrally, and let everything else be owned locally. Autonomy only threatens consistency when the centralized set is drawn too wide or left vague.
What if an owner makes a decision I disagree with? As long as it does not cross the spine, let it play out. Overriding the first real decision someone makes teaches them that their ownership is decoration. You are accountable for the standards; they are accountable for the calls within those standards, including the ones you would have made differently.
How do I hold people accountable without creating a blame culture? Separate the decision from the outcome. Hold people accountable for making considered decisions and owning the cleanup, not for the fact that a reasonable call sometimes goes wrong. Run the post-incident loop as “what did this teach us,” not “whose fault was this.”
Two people keep assuming the other one handled something. How do I fix that? Give every important outcome exactly one owner, even when it spans two areas. Shared ownership of a surface is fine; shared ownership of a specific outcome means nobody owns it. Name one person, and make the other an explicit consult.
How does ownership work when products share code and standards? Shared things get a single owner, and product owners consume the shared thing rather than re-authoring it. Product owners have full autonomy on top of the shared foundation, but they cannot quietly fork it. If it does not fit, they raise it with the owner of the shared thing, and it changes for everyone or there is a stated reason it does not.