Access Isn’t Ownership
Shared admin access is easy. Owning the outcome is not.
Backend engineer focused on real-world software. I care about clarity, architecture, and decisions grounded in reality. Strong on Java, AWS, automation and AI workflows. I write about engineering without dogma.
We have four senior engineers.
All of them have admin access to Jira.
None of them considers themselves the owner.
And when something breaks, the default assumption is always the same: someone else will deal with it.
Access is not ownership. Ownership means you can’t look away. If it breaks, you’re the one who gets called. Jira is just the example. This pattern shows up in every internal service where multiple people have admin access but nobody owns the outcome.
Ownership is not a title: it’s a constraint. It means you can’t look away. If it breaks, you’re the one who gets called and you’re expected to respond.
Ownership also isn’t a single thing. There’s the person who holds the admin keys, there’s the person who owns the functional behavior and policies and there can even be local owners who decide how their team applies those policies. And all of that can be shared. What you can’t spread thin is accountability: when something is on fire, someone has to be clearly in charge of that one thing.
How internal services decay when nobody owns them
We’ve all seen that scene, it looks harmless at first: “We’re seniors, we can all help, we’ll figure it out.” But “we all can” quickly turns into “nobody must”. And once an internal service has “shared admin access” and “no owner”, it starts decaying quietly.
Nobody documents the setup because “it’s temporary”.
Nobody rotates credentials because “I’d break John’s admin access”.
Nobody tests backups because “we’ve never needed them”.
Nobody tracks cost or risk because “it’s just an internal tool”.
The scary part is that it works… until it doesn’t. And you should know big outages rarely come from one big mistake but they’re usually the compounded effect of a few small, avoidable misses.
The inevitable disaster
Then one day someone tries to “clean things up”. They reinstall the service, or migrate it, or rotate something that was never meant to be rotated without a plan. And something important disappears… a dashboard, history, config files… The one person who knew how it was wired left months ago and nobody asked for a handover because nobody thought there was an owner to hand over from.
And now it’s urgent. Not because the tool is critical by design but because the organization made it critical by neglect.
This isn’t a tooling problem
Let’s be clear about something: this isn’t a Jira problem or a Sonar problem or a pick-a-tool problem. It’s an ownership problem. A governance problem.
Tools don’t fail like this. Organizations do.
How “owner” splits in practice
In real teams, “owner” rarely maps to a single person doing everything. For something like Sonar, you might have:
The key holder: the person or team that manages the admin credentials, tokens, and integrations. They’re responsible for secure access and rotations, not for deciding what “good code” looks like.
The functional owner: often the head of QA or whoever owns quality across the organization. They decide the global rules: which quality gates exist, what’s mandatory, what’s experimental, and what “red” actually means.
The local owners: tech leads who decide how those rules apply to their repositories. They own the configuration for their area, as long as they stay within the global constraints.
All of these are forms of ownership. That’s fine. What breaks systems is when nobody can answer simple questions like:
“Who decides the global policy?”, “Who can change it?”, or “When this specific project is blocked, who do we talk to?”
If those answers aren’t crystal clear, you don’t have shared ownership. You have shared confusion.
A simple test for ownership
Here’s a simple test you can do. For every internal service, you should be able to answer three questions:
Who owns it?
What happens if it breaks at 3AM?
What happens if that person gets hit by a bus tomorrow?
If you can’t answer those three, the system is already broken. It just hasn’t failed yet.
Close: name an owner
The most dangerous systems aren’t the ones with bad architecture. They’re the ones with no owner. And if you disagree, think again.
Admin access is easy to hand out. Ownership isn’t. If a service matters, make it explicit: name an owner for the outcome. Not because they control everything, but because they can’t look away.