Devops on Coffee or Blog

Why Doesn't Anyone Own That?

Mon, 23 Mar 2026 00:00:00 +0000

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.

The Lie That Taught Me About Blameless Culture

Fri, 09 Jan 2026 00:00:00 +0000

I was standing outside a conference room watching my team lie to another team about a database outage. It was day four.

Through the glass door, I could see the engineer on the call, explaining with impressive confidence that our cloud provider was having issues. Any minute now, they said, the vendor would resolve it and services would come back up.

I pulled up the provider’s status page. Green across the board. Checked their Twitter. Nothing. I caught the eye of the engineer leading the response and motioned them outside.

“What actually happened?”

The way they looked at the floor told me everything. Then: “Accidental deletion. We’re working on recovery.”

Here’s the thing about inheriting a team: You don’t just inherit their code and their systems. You inherit their patterns. Their fears. The lessons they learned from whoever led them before you.

My team had learned that mistakes meant consequences. That admitting fault meant exposure. That the safest play was to redirect blame to something faceless—a cloud provider, a vendor, a system “acting weird.” They’d learned this so well that lying to the team we supported felt safer than telling their new boss the truth.

I had about thirty seconds to decide what kind of leader I was going to be.

The Conversation

We found an empty office.

“I’m not mad about the database,” I said. “I’m concerned you felt you couldn’t tell me.”

They stared at their hands.

“I need you to understand something. I’m four days into this role. I don’t know your systems. I don’t know the history here. But I know this: I can’t help you fix problems I don’t know about. And the other team can’t tell us how severe this actually is if we’re feeding them fiction.”

“Previous leadership didn’t react well to mistakes.”

There it was. The inherited culture, delivered in one sentence.

“Okay. Here’s the new standard: You tell me the truth, always. I’ll handle the hard conversations. You focus on the fix. Deal?”

They looked up. “Deal.”

Falling on the Sword

I walked back into that conference room.

“I need to correct something,” I said. “This isn’t a cloud outage. One of our engineers accidentally deleted the pre-production database. We’re working on recovery now, but I need your help: How critical is this to your operations? What’s the actual impact?”

The silence lasted maybe three seconds. Felt like an hour.

Then: “Thank you for being straight with us. Here’s what we need…”

They walked us through their priorities. Which services mattered most. What data they could recreate versus what needed restoration. The conversation became a collaboration instead of a performance.

We got the database back. It took six hours and some creative recovery work, but we got it back.

The Post-Mortem

The next day, I gathered the team in the conference room for our first post-mortem. I’d never run one with them before, so I started by explaining how we were going to do them from now on.

“When we name people in post-mortems,” I said, “it’s only for successes. Who responded quickly. Who had the knowledge to guide recovery. Who communicated clearly under pressure.”

I looked at the engineer who’d led the recovery effort. “You did excellent work getting us back online.”

“For failures, the buck stops with me. I’m the lead. Anything that goes wrong happened on my watch. My job is to figure out what systemic failures allowed this to happen and fix them.”

I watched the team process this. Some looked skeptical. Some looked relieved. All of them looked like they were waiting for the other shoe to drop.

“Here’s what we’re changing. Permissions on production-like environments. Backup verification procedures. Documentation on recovery processes. And most importantly: the expectation that you can always tell me the truth, especially when things break.”

The Timing

Looking back, week one was actually the perfect time for this to happen.

I had no history with this team. No pattern of reactions for them to predict. No baggage about “how we’ve always done things.” When I said “this is the new standard,” there was no previous version of me to contradict it.

Being new meant I had nothing to lose and everything to prove. I couldn’t lean on established trust or authority. I had to show them, in real time, what kind of leader I was going to be.

Culture isn’t built during the smooth times. It’s built in how you respond when things break. And things always break.

What Stuck

That engineer never lied to me again. Neither did anyone else on the team. Not because I’d scared them straight, but because I’d shown them the alternative: honesty gets you help, not punishment.

The other team? They became one of our strongest advocates. Years later, they still reference that incident as the moment they knew they could trust us.

The post-mortem approach stuck too. Name people for successes, take responsibility for failures. It sounds simple, but it changes everything about how teams respond to pressure.

I couldn’t change what my team had learned before I arrived. I couldn’t undo whatever had taught them that self-preservation trumped transparency. But I could show them a different future, starting with one deleted database and one honest conversation.

The bad news: People will test your principles during crisis. The good news: Crisis is when principles matter most.

The job is to be ready anyway.

Everything I learned about Ops, I learned playing goal

Thu, 06 Nov 2025 00:00:00 +0000

Well, maybe not everything.

Look, being a goalie is objectively ridiculous. You strap on forty pounds of equipment designed to protect you from frozen rubber traveling at speeds that would make physicists frown. Then you stand in front of a net and dare people to shoot at you. It’s a strange job.

But here’s the thing: being a goalie is basically the same job as running ops, or security, or honestly, any part of software development where you’re the one who has to keep the thing from breaking.

Both jobs share the same core truth that nobody tells you in the job description: when everything’s working, no one notices you’re there. But the second something gets past you? Everyone knows exactly where you were and what you should have done differently.

You spend most of your time reading patterns, anticipating problems before they fully materialize, and communicating with people who may or may not be listening. You’re simultaneously trying to follow the systems that keep you consistent while also staying loose enough to react when something weird happens. Because something weird always happens.

And whether it’s a breakaway in overtime or a production incident at 2 AM, you learn pretty quickly that freezing up isn’t an option. You make the save or you don’t. You stop the breach or you don’t. Then you’ve got about eight seconds to shake it off and get ready for the next shot, because there’s always a next shot.

The bad news? You can’t stop everything. The good news? Neither can anyone else. The job is to be ready anyway.

Decoupling Deployment from Release: An Architectural Imperative

Tue, 30 Sep 2025 00:00:00 +0000

Photo by Patrick Konior on Unsplash

We need to talk about how we ship software. Not because we’re doing it wrong, but because we can do it so much better, for our customers, for our colleagues, and for ourselves.

The Core Problem: Deployment Isn’t Release

Here’s the shift we need to make: deploying code and releasing features are not the same thing, and they shouldn’t happen at the same moment.

When we conflate deployment with release, we create unnecessary risk and friction. We deploy code to production, and suddenly a feature is live, ready or not. If something goes wrong, we scramble. We hotfix. We roll back entire deployments, potentially affecting unrelated changes. We make our product and support teams reactive instead of strategic.

There is a better way.

Why This Matters: Safety First

Our customers trust us with their business. Our colleagues across product, support, and operations depend on stable, predictable releases. When we tie deployment directly to feature availability, we put both at risk.

Safe software releases mean:

Our customers experience fewer disruptions
Our support team can prepare for changes before they go live
Our product team can control the narrative and timing of new features
Our engineers can deploy confidently, knowing they have safety nets in place
We can see the impact of our changes

This isn’t about adding bureaucracy. It’s about adding control.

The Mindset Shift for Engineers

I know what some of you are thinking: “This sounds like more process. More overhead. More barriers between my code and production.”

Let me reframe it: What if deployment was easier because it was safer? What if you could push code to production multiple times a day without the anxiety of “did we just break something for customers?”

This requires us to think differently:

Code goes to production dark, deployed but not activated
Features are controlled by flags, not by deployment timing
Your code can live in production for days or weeks before anyone uses it
When issues arise, you flip a switch instead of rolling back a deployment

This is actually more engineering control, not less. You own the technical deployment. Product and support teams own the feature release timing. Everyone wins.

Empowering Product and Support

Our product managers understand customer needs, market timing, and strategic rollout. Our support team knows when they’re ready to handle inquiries about new features. Our documentation should be created in production.

When we give them control over feature flags, we put release decisions in the hands of the people best positioned to make them. Engineering provides the capability; product and support control the activation.

This isn’t about taking power away from engineering, it’s about giving everyone the right kind of power.

Stop Removing What People Still Use

We’ve all been there: a feature is marked for deprecation, so we rip it out. Then we discover customers were still using it, or they needed more transition time.

With feature flags and dual code paths, we can:

Run old and new implementations side by side
Give customers time to migrate naturally
Gather actual usage data before removal
Roll back feature changes without rolling back deployments

We keep both paths alive until we know the old one isn’t needed. Data drives decisions, not assumptions.

Creating Dual Code Paths

The technical pattern is straightforward:

if (featureFlag.isEnabled('new-checkout-flow')) {
  // New implementation
  return enhancedCheckout();
} else {
  // Current implementation
  return traditionalCheckout();
}

This enables:

Rapid feature releases, toggle a flag, feature goes live
Instant rollbacks, toggle it back if issues arise
Gradual rollouts, enable for 10% of users, then 50%, then 100%
A/B testing, compare new vs. old with real data
Safe deprecation, maintain the old path until usage drops to zero

Yes, you maintain two paths temporarily. But the flexibility and safety are worth it.

We Already Test in Production, Let’s Do It Right

Here’s an uncomfortable truth: we all test in production. Even with the best staging environments, production has data patterns, load characteristics, and edge cases we can’t fully replicate.

Feature flags let us test in production safely:

Enable new features for internal users first
Roll out to beta customers who opt in
Gradually expand to broader audiences
Monitor in real time and react instantly

Instead of pretending we don’t test in production, let’s acknowledge it and build systems that make it safe and controlled.

Making Monitoring and Observability Easier

When features are flag-controlled, monitoring becomes clearer:

Dashboard metrics tagged by feature flag status
Alerts that distinguish between feature issues and infrastructure issues
A/B comparison of performance between flag states
Clear correlation between flag changes and system behaviour

You’ll spend less time debugging “what changed?” because you’ll know exactly what changed and when.

This Is About Your Value

Every engineer brings immense value. You solve complex problems. You build systems that serve customers. You keep the platform running.

This approach amplifies your impact:

Deploy more frequently without stress
Spend less time on hotfixes and emergency rollbacks
Focus on building new capabilities instead of managing release logistics
See your features succeed because they’re released at the right time, to the right users

Your technical expertise deserves better tools. Feature-flagged releases are those better tools.

Getting Started

We don’t need to transform everything overnight. Here’s how we can begin:

Start with your next major feature, wrap it in a feature flag
Integrate flags into your monitoring, make flag status visible in dashboards
Coordinate with product and support, let them control release timing
Gather data before deprecation, keep old code paths until usage proves they’re unnecessary
Share what works, as teams succeed with this approach, spread the practices

This is a journey, not a destination. Each team can adopt at their own pace.

The Bottom Line

Separating deployment from release isn’t just a technical practice, it is a philosophy of safety, control, and collaboration. It acknowledges that great software delivery involves engineering excellence and thoughtful release management.

We have the talent. We have the technical capability. Now let’s build the practices that let us ship with confidence.

Let’s deploy fearlessly and release deliberately. Our customers, our colleagues, and our code deserve nothing less.