Democratizing Ownership: The Secret to Scalable Teams
Building a culture where ownership is shared, not assigned.
In the early days at our org, the same few people were always the ones looking into alerts or performance issues. They understood the system well, knew where to look, and cared a lot about keeping things reliable.
But after some time, we noticed a few problems:
These people were getting tired and burned out. They were always on call and always needed.
The rest of the team was slower, not because they didn’t care, but because they waited for these few to take the lead.
Everyone said reliability was important, but only a few were actually working on it. It looked like a shared responsibility, but in reality, it wasn’t.
No one did this on purpose—it just happened over time. People assumed, “They’ll handle it.”
But what if one of them was on leave? Or decided to leave the company?
We realized that for our team to grow in a healthy way, ownership couldn’t stay with just a few people. It needed to be shared, clear, and part of how we worked every day.
Looking back, the problem wasn’t just that a few people were handling all the alerts. The real question was:
Why did everyone else stay away?
It wasn’t because people didn’t care. It was more about things like:
“I don’t know if this concerns me“
“I don’t know enough to help.”
“It’s not my area—someone else owns it.”
“This is how it’s always worked here.”
No one was told to stay out, but the way things were set up made them feel that way. Even if they wanted to help, they didn’t feel confident or responsible.
Problem 1: “I don’t know if this concerns me”
This was the most common reason people stayed away from alerts. When something broke or an alert fired, many didn’t step in—not because they didn’t care, but because they weren’t sure if it was their responsibility.
A big part of the issue was how our alerting was set up:
Alerts were too generic and not tied to specific services or teams.
Many alerts were triggered on shared infrastructure, so it was unclear what part of the system was actually affected.
Most alerts landed in a shared Slack channel, without context or clear ownership.
So even when someone saw an alert, their first thought was usually:
“Is this mine? Should I look into it? Or is someone else already on it?”
That hesitation added delay. And more often than not, the same people who always responded… responded again.
We learned that without clear signals, most people will assume it’s someone else’s job. Especially in high-stakes situations, people avoid stepping in if they’re unsure.
This was the first thing we had to fix—make ownership visible and obvious.
Problem 2: “I don’t know enough to help”
Even when people knew the alert was related to their area, many still didn’t take action. The reason? They didn’t feel confident enough.
We heard things like:
“I don’t know where to start.”
“What if I try something and make it worse?”
“Someone else will probably fix it faster than me.”
In many cases, the required knowledge lived only in a few people’s heads. There were no clear runbooks, no shared dashboards, and no easy way to understand what was going on unless you had been around long enough or had seen it before.
This made reliability feel like a “specialist’s job,” not something everyone could contribute to.
We realized that without easy access to context or tooling, even willing team members won’t step up. Not because they don’t want to—but because they feel stuck.
To fix this, we had to invest in documentation, observability, and simple debugging tools—so anyone on the team could at least start investigating, even if they weren’t the expert.
Problem 3: “It’s not my area—someone else owns it.”
Even when someone understood the alert and knew how to help, they often stayed away because they believed it wasn’t their job.
We’d hear things like:
“This isn’t my service.”
“That team usually handles this.”
“I don’t want to step on anyone’s toes.”
This mindset became more common as we started splitting our systems and teams. Silos started to form—each team had their own services, their own dashboards, their own processes. While separation helped with focus, it also created invisible walls. People became hesitant to step outside their boundaries, even when they had something useful to add.
The end result? A narrow view of ownership. Teams only focused on their piece, even if issues were affecting others too.
We realised that clear ownership is important, but collaboration across teams is just as critical. Especially in complex systems, problems rarely sit neatly within one team’s boundaries.
A simple step that helped break silos was starting a rotating on-call program, which gave more people system-wide context and shared responsibility.
Problem 4: “This is how it’s always worked”
Sometimes the biggest blocker is not technical—it’s habit.
Many people stayed away from alerts or reliability work simply because that’s how things had always been. A few people had always handled it, so the rest of the team assumed that’s how it’s supposed to be.
There was no discussion, no decision—it just became the norm over time.
This mindset is hard to spot, and even harder to change. It leads to passive behaviour, where people wait instead of act. Even when ownership shifts or teams grow, these old patterns often stay in place.
To break this pattern, we realized that change doesn’t always start with a policy. It starts with conversations.
In 1-1s, we talked openly about reliability work and whether people felt confident owning it.
In career conversations, we highlighted how taking initiative on such problems is a sign of growth.
During RCAs and postmortems, we made space for people to ask questions and understand areas outside their team.
Over time, these regular conversations helped shift mindsets. People started seeing ownership not as extra work, but as part of being a strong engineer.
Closing Thoughts
We didn’t fix ownership gaps overnight. It took a mix of changes—some technical, like routing alerts better, and some cultural, like encouraging open conversations during 1-1s and RCAs.
But the biggest shift came when we stopped relying on a few “go-to” people and made reliability a shared goal.
We’re still evolving, but one thing is clear: ownership doesn’t have to come from authority. It grows when people feel safe, supported, and informed enough to step up.
And that’s what we’ve been working toward—a culture where ownership is not assigned, it’s shared.
Seen similar patterns in your team? I’d love to hear how you’ve approached this.
If this resonated with you, subscribe to get future posts—straight from the production floor.