You can own a service and still abdicate responsibility for the outcomes it produces.
This sounds like a contradiction. If you own the service, you own the outcomes, right?
No. Not really.
I've seen engineers who can recite every dependency of their service, who wrote every line of the critical path, who have the runbook memorized — and still treat their ownership as a boundary instead of a commitment. They own the file. They don't own the problem.
There is a difference. It shows up in every outage, every missed deadline, every customer complaint that bounces between teams until someone tired just fixes it and moves on.
Owning a file is easy. Owning a problem is not.
When people say "I own this service," what they usually mean is: I wrote the code. I know the architecture. I'm the person to page at 3am.
That is real ownership. It is also incomplete.
The file is the artifact. The problem is what the artifact exists to solve. If you only own the artifact, you will make decisions that optimize the artifact while degrading the problem. You'll ship a technically clean implementation of the wrong thing. You'll say "that's not my code" when a downstream team's bug traces back to a decision you made. You'll treat the boundary of your repo as the boundary of your responsibility.
That is not ownership. That is custodianship.
Owning a file means you know what the code does. Owning a problem means you care what the code produces.
The difference matters because the code is the easy part. Anyone can write code. Caring about the outcome — the customer experience, the business impact, the downstream teams that depend on you, the decisions you didn't make because "that's not my ticket" — that is the hard part. And it's the part that actually separates engineers who build leverage from engineers who build tickets.
The "not my code" problem
There is a sentence that costs organizations more than any single bug, and it is almost never said with malice:
"That's not my code."
It sounds reasonable. It sounds like a boundary. But in practice, it's a surrender. It's the moment an engineer decides that their responsibility ends at the edge of their repo, their service, their sprint, their title.
And then the bug ships. Or the feature lands with a silent failure in the integration. Or the customer gets a confusing error because two services disagreed about what "success" means and neither team noticed.
The fix is not to eliminate boundaries. Boundaries are necessary. You can't be responsible for everything. The fix is to make the boundary a seam instead of a wall.
A seam says: "This is where my responsibility ends and yours begins, and I've made sure the handoff is clean." A wall says: "This is where my responsibility ends and yours begins, and good luck."
The engineers who own their problems don't cross every boundary. They make sure the boundaries are honest. They document what they hand off. They check that the downstream team understands it. They follow up when something breaks on the other side, even if it's not their ticket.
That is what ownership looks like in practice. Not heroics. Not code ownership. Just the willingness to care about the outcome.
Ownership shows up in the things nobody measures
You can't put "cares about outcomes" on a performance review. It doesn't generate a diff. It doesn't show up in velocity metrics. It doesn't make anyone look busy.
But it shows up everywhere else.
It shows up in the engineer who notices a customer complaint that traces back to their service and fixes it before the ticket is filed. It shows up in the person who says "we should handle this edge case" even though nobody asked them to. It shows up in the decision to add a validation check that protects a downstream team, not because it's required by the spec but because the engineer understands what happens when the spec is wrong.
It shows up in the postmortem where someone names their own mistake instead of finding the nearest person who can take the blame. It shows up in the design review where someone pushes back on a technically clean implementation of the wrong decision — the same shape as the review moved up the stack, where the code is fine and the confidence is the bug.
None of that is measured. All of it compounds.
The connection to reliability
This is the same idea from a different angle as reliability being an organizational problem. You can have the best monitoring, the best runbooks, the best alerting — and still have unreliable systems if the people running them treat ownership as a file instead of a commitment.
The most reliable teams I've seen weren't the ones with the best tooling. They were the ones where engineers treated the boundary of their service as a seam, not a wall. Where "that's not my code" was replaced with "that's not my code, but I know who owns it and I'll help." Where the postmortem named the structural failure instead of the proximate cause.
Reliability is organizational. So is ownership. They're the same thing viewed from different directions.
The goal is not to be needed, but you have to be responsible
There's a tension here that took me a while to resolve. On one hand, the goal is not to be needed — you want to build systems that work without you, distribute understanding, make yourself redundant. On the other hand, ownership means being the person who cares when things go wrong.
These are not contradictory. They're two phases of the same thing.
Early in your career, ownership means being the person who fixes everything. That's valuable — it's how you learn. But the ceiling is low. You can't personally own every problem forever.
The next phase is owning the problems you can't personally fix. You own them by building the systems, the documentation, the ownership records, the runbooks, the boundaries that make sure the next person can solve them without you. You own them by making sure the problem doesn't come back.
That's the difference between being needed and being responsible. Being needed means the system depends on you. Being responsible means the system depends on the understanding you left behind.
What real ownership looks like
It's not a title. It's not a file path. It's a set of behaviors:
- You care about the outcome, not just the artifact. The code is the means. The result is the point.
- You treat boundaries as seams. You document what you hand off. You check that the handoff is clean. You follow up when something breaks on the other side.
- You speak up when something is wrong, even when it's not your ticket. You don't wait for permission to care.
- You own the problem, not just the fix. Fixing the symptom is easy. Preventing the next one is the job.
- You leave behind understanding, not dependency. The system should work better without you than with you.
None of that is glamorous. None of it generates a satisfying diff. All of it prevents more downtime than your next three infrastructure upgrades combined.
The reframe
Ownership is not a file. It's not a service. It's not a Jira ticket or a pager assignment.
Ownership is the willingness to care about the consequences of your work, not just the artifacts you produce. It's the difference between "I wrote this" and "I made sure this works." It's the difference between a boundary and a seam.
The engineers who build the most durable systems aren't the ones who own the most code. They're the ones who own the most problems. And the problems they own are rarely the ones in their repo.
They're the ones that show up when the code breaks. When the customer complains. When the downstream team is confused. When the postmortem needs to be honest.
That's where ownership lives. Not in the file. In the outcome.
The one-line version
Ownership is not a file path or a ticket assignment. It's the willingness to care about the consequences of your work, not just the artifacts you produce. "That's not my code" is the most expensive sentence in engineering — because the code is the easy part, and the outcome is the only thing that matters.