It’s 5 PM on a Thursday. Something broke mid-morning and your team has been grinding on it for hours. Good engineers, working hard, coming up empty because the system is poorly documented and the people who built it have either moved on or moved teams. You’ve burned most of the day and you’re no closer to resolution.

So you escalate. You ping the leads. You ask in the channel where someone, surely, knows this service well enough to point you in the right direction.

Silence.

Not because nobody cares. Because nobody actually owns it. There’s a name in the CMDB, but that person will tell you they haven’t touched it since a reorg reshuffled their priorities. There’s a runbook, but it describes a version of the system that no longer exists. There’s a Slack channel with forty members and no clear authority.

This is where the real cost of diffuse ownership lives. Not in the architecture review, not in the postmortem writeup. Right here, in a live incident, with a team that has already spent most of a day spinning their wheels and a business that is losing patience.

The easy diagnosis is that engineers don’t want ownership. Nobody wants the accountability when something critical falls over. That read is intuitive, and it’s mostly wrong.

Most engineers I’ve worked with want to own something. They want the stakes, the identity, the sense that they know a system cold and it shows. Ownership is a fundamental motivator in this work. It’s one of the few things that makes the job feel like more than ticket throughput.

The problem isn’t appetite. It’s that we’ve built organizations that punish people for taking it.

We say we want owners. Then we punish them.⌗

Most performance systems weren’t designed to reward operational excellence. They were designed to measure visible output — features shipped, projects delivered, things a manager can point to in a calibration meeting and defend. Keeping a critical service healthy produces none of that. No launch. No demo. No ribbon cutting.

Here’s what it does produce: a rating of “meets expectations.” Which, in most four-point HR scales, means no raise. Sounds fair until you consider that the engineer just spent a quarter instrumented to the gills on a service that didn’t go down, pushed for refactors the team had been deferring for two years, and responded to every incident that came their way. They did their job flawlessly. The organization scored it as ordinary because ordinary is the only category it fits in.

That engineer is not doing that again next year. Neither is anyone who watched it happen.

The performance review is just the most visible mechanism. The same signal gets sent in sprint planning when operational work gets bumped for roadmap items, in reorgs when the “boring” platform work gets deprioritized, in how leaders talk about the team that keeps things running versus the team shipping the new thing. It accumulates. People are paying attention even when you think they aren’t.

Rational engineers respond rationally. Ownership becomes a liability, ambiguity becomes protection, and the next time someone asks who owns the broken thing, there genuinely isn’t an answer.

Accountability without authority is just blame.⌗

There’s a second trap that even well-intentioned leaders fall into, and it’s more insidious than the performance review problem because it often comes wrapped in the language of empowerment.

We assign ownership without giving people the actual power to act.

Think about what that looks like in practice. An engineer is named owner of a critical platform service. They identify that the deployment process is bypassing validation steps and creating instability. They flag it. They write it up. They ask for a two-week pause on releases to address it. The response from leadership: “We can’t stop the roadmap, let’s find another way.” There is no other way. The service degrades, falls over, and in the postmortem the question on the table is why the service owner didn’t catch this sooner. It plays out constantly, in slightly different costumes, and the person in the owner role learns the same lesson every time.

Ownership without the authority to say no to a risky deployment, to pull capacity from feature work when a system is genuinely at risk, to set a standard and enforce it — that isn’t ownership. It’s a title with no teeth. The person holding it gets the pager, gets the postmortem questions, gets the performance conversation, and had none of the leverage required to prevent any of it. Smart engineers recognize that setup fast. Word travels.

The organizations that do this aren’t malicious. Most of them genuinely believe they’ve created clear ownership. They put a name in a doc and called it done. What they actually created is a designated scapegoat with a service catalog entry.

The cost is higher than you think.⌗

Diffuse ownership doesn’t just create operational risk, though it absolutely does that. It degrades the institutional knowledge your organization depends on.

When nobody owns a system, nobody deeply understands it. Documentation becomes aspirational fiction. Runbooks describe what someone intended the system to do, not what it actually does. Incidents take longer, cost more, and teach less, because there’s no through-line of accountability that connects cause to effect to learning.

And the talent impact is brutal. The engineers who want to own things, the ones you most want to retain, will eventually get tired of operating in that vacuum. They’ll go somewhere that lets them. The engineers who remain will have self-selected for comfort with ambiguity and low accountability. That is a culture you cannot easily reverse.

What actually changes this.⌗

This isn’t a process problem. You can’t RACI-chart your way out of a culture that punishes ownership. You have to change what you reward.

Start with how you evaluate performance. If your engineering managers cannot point to explicit, visible credit given to engineers for operational ownership — in promotion cases, in calibration sessions, in public recognition — then you are implicitly telling your team that it doesn’t count. Fix that first.

Next, make ownership legible. A service with a named owner, a clear charter, and explicit authority boundaries is a service people will actually step up to own. Ambiguity is where accountability goes to die. Define the thing. Name the owner. Give them real power over their domain.

Toyota figured this out on the factory floor decades ago. Their Andon system gives any line worker the authority to stop production the moment they identify a problem — not escalate it, not flag it for later, stop it. The entire premise is that the person closest to the issue has both the standing and the backing to act. It works because leadership built a culture where pulling that cord is the right call, not a career risk. We’re supposedly more sophisticated in software, yet we routinely put engineers in positions where they can see the problem clearly, have no authority to stop anything, and get blamed when it blows up anyway.

Back your owners when it’s hard. When someone pulls the cord on a deployment, or pushes back on a timeline because the system genuinely can’t absorb it, support that call publicly. If you quietly override it three times, you’ve taught everyone watching that ownership is theater.

The question worth asking.⌗

The next time you find yourself in that room, the incident is running, the silence is thick, and nobody’s hand goes up, resist the urge to blame your people.

Ask instead what you, and the organization above you, built that made this feel like the right call.

Because I promise you: somewhere, at some point, someone tried to own that thing. And something happened that taught them not to.

Your job is to find out what that was, and fix it.

Good ownership isn’t found. It’s cultivated, or it’s extinguished. Pick one.