Ownership Culture

The Ultimatum

The conference room felt like an interrogation chamber. Wednesday afternoon, first week on the job, and Paul had summoned all of us — six seasoned engineering managers and me, the rookie who didn’t yet know the rules of this particular game.

Twenty-seven developers trapped in the merge queue. A repository choking on its own growth. Eighty engineers, all feeding PRs into the same bottleneck, while only four made it through each day. The numbers had a way of haunting you.

Paul dominated the room without trying. He was built like a bouncer who’d found his way into management — broad shoulders, thick neck, the kind of English accent that made everything sound like a threat. When he spoke, people stopped breathing.

“I’m going on leave for two days,” he said, eyes scanning each face at the table. “I’ll be back Monday morning. This queue problem ends then. One way or another.”

The door slammed behind him. The sound echoed longer than it should have.

Ben was the first to crack the silence, suggesting process tweaks that might squeeze out an extra merge or two. Oliver pitched in with scheduling optimizations. Safe plays. The kind of incremental fixes that would buy time but solve nothing.

I sat there knowing exactly what needed to happen. The previous year I’d gutted and rebuilt an entire CI infrastructure. TeamCity, full automation, the works. This wasn’t rocket science — it was surgery, and I knew where to cut.

But speaking up meant stepping into the spotlight. First week, no allies, no reputation to fall back on. In this room, that felt dangerous.

Three more suggestions came and went. Small-time solutions to a big-time problem. Each one more desperate than the last.

Finally, I stood up and grabbed the whiteboard marker. The click of the cap coming off was loud in the silent room.

“This is what’s really happening,” I said, and began sketching the process — every manual step, every bottleneck, every point of failure.

When I finished, the room had the stillness of a crime scene. Even the air conditioning seemed to hold its breath.

“So you’ll present this to Paul on Monday?” Oliver asked, his voice carefully neutral.

“Yeah,” I said. “I’ll present it.”

Monday arrived like a deadline. Paul moved through the open office like a predator, cutting between desks and meetings with purpose. I intercepted him near the kitchen, started laying out the plan. He checked his phone while I talked and we continued to move towards his next meeting, the dismissal obvious and calculated.

Then he stopped. Looked at me directly for the first time.

“Joel,” he said, his voice carrying that familiar edge. “You sound like you actually know what you’re talking about. So stop asking for my permission and just get it done.”

I hadn’t been asking for permission. I’d been explaining the solution. But in that moment, I understood the distinction — and what it meant to survive in this place.

The realization hit like a cold draft. This wasn’t a company that rewarded careful consultation or consensus-building. Those were the behaviours that got you stuck in endless meetings, buried under process, forgotten in the machinery. The people who thrived here were the ones who saw a problem and moved — consequences be damned.

Paul’s dismissal wasn’t personal. It was institutional. He’d spotted something in me: not just technical knowledge, but the willingness to step up when the room went quiet. That’s what he was testing with his abrupt departure — who would fold under pressure, and who would act.

The queue wasn’t just a technical bottleneck. It was a filter. The engineers trapped in it were the ones who followed protocol, waited for approval, played it safe. Meanwhile, the company was drowning in its own bureaucracy, hiring faster than it could integrate, expanding beyond its ability to execute.

They needed people who moved first and apologized later. People who treated company problems like personal emergencies. The kind who would spend their own political capital to fix something that wasn’t technically their responsibility.

Paul had given me more than permission. He’d given me a glimpse of the real game being played here — and invited me to join it.

Three weeks later, we were pushing fifteen PRs through daily. The queue was dead and buried.

The Real Game Nobody Tells You About

Here’s what they don’t teach you in engineering school: technical competence is table stakes. What separates good engineers from great ones isn’t their ability to write clean code or architect elegant systems — it’s their willingness to solve problems that aren’t officially theirs.

The merge queue wasn’t my responsibility. I was hired to work on a specific product, with specific deliverables, under a specific Director. But here’s the thing about bottlenecks — they don’t respect org charts. When twenty-seven developers are trapped behind a broken process, it doesn’t matter whose fault it is. What matters is that someone fixes it.

The “Treat It Like Your Own Money” Principle

Years ago, a boss gave me budget responsibility and then questioned my decisions — rightfully so, because I made some terrible ones. But his advice after the fact, stuck with me: ”Treat it like it’s your own money, Joel.”

This principle extends far beyond financial decisions. When you’re deciding how to spend your time, your political capital, your team’s focus — ask yourself what you’d do if this were your company. Not in some theoretical sense, but if you genuinely had to live with the long-term consequences of every decision.

Warren Buffett captured this beautifully: ”Someone’s sitting in the shade today because someone planted a tree a long time ago.” Every time you choose the safe path over the right path, you’re choosing short-term comfort over long-term value — both for yourself and your organization.

The Dangerous Dance of Ownership

But here’s where it gets tricky. A year later, I continued a lot of this work on the side helping out with CI, a Product Owner pulled me aside and asked, quite bluntly, “Do you think you’re too distracted and not focused enough on the team?”

It was a fair question. There’s a fine line between taking ownership and becoming a chaos monkey, bouncing between problems without finishing what you started. The key is developing the ability to distinguish between problems that genuinely need your intervention and problems that someone else should handle.

You need to constantly calibrate this internal compass. Ask yourself: If it were my company, would I want someone in my position working on this problem? Am I the right person to solve it? Can I balance this with my other responsibilities without dropping balls? Should I drop some balls because this is more important?

Beyond Your Job Description

Too many engineers in our industry treat their role like a factory job — complete assigned tasks, hit metrics, wait for the next assignment. But software development isn’t manufacturing. We’re not assembling widgets on a conveyor belt.

We’re problem solvers in a complex, interconnected system where a bottleneck in one area can paralyze dozens of people. When you see inefficiency, broken processes, or technical debt slowing down your colleagues, you have a choice: document it in a ticket and move on, or take ownership and fix it.

As Edmund Burke wrote, ”The only thing necessary for the triumph of evil is for good men to do nothing.” Replace “evil” with “inefficiency” and you’ve got the engineer’s dilemma in a nutshell.

The Courage to Act Without Permission

The hardest part isn’t identifying problems — it’s acting on them when you don’t have explicit authority. Paul’s response taught me something crucial: sometimes asking for permission is actually asking for an excuse not to act.

When you say “Should I fix this broken CI pipeline?” you’re often really asking “Will you take responsibility if this goes wrong?” But ownership means accepting that responsibility yourself, not because someone assigned it to you, but because you saw a problem and knew you could solve it, and you thought it was the right thing to do at the time.

This doesn’t mean being reckless. It means being thoughtful about risk, communicating your intentions, and accepting that sometimes you’ll need to apologize rather than ask permission.

The Multiplier Effect

Here’s what happened after we fixed that merge queue: not only did we go from four PRs per day to thirty, but we also built the infrastructure to handle doubling our engineering team the following year. One person taking ownership of a bottleneck created value that compounded for years.

That’s the real return on ownership thinking. When you solve systemic problems rather than just your assigned tasks, you create leverage that benefits everyone. You become what engineers call a “force multiplier” — someone whose impact extends far beyond their individual contributions.

Finding Your Ownership Moments

So how do you know when to step up? Look for these signals:

The room goes quiet when someone asks “Who’s going to fix this?” That silence is an opportunity, not a warning.

Multiple people are complaining about the same problem, but nobody’s doing anything about it. Complaints without action are just entropy.

You find yourself working around a broken process repeatedly. If you’re building personal scripts to compensate for organizational dysfunction, maybe it’s time to fix the dysfunction instead.

You have a solution that goes beyond incremental improvements. Sometimes good enough really isn’t good enough.

The Bottom Line

Taking ownership isn’t about being a hero or collecting credit. It’s about recognizing that in a complex system, everybody’s problem is eventually your problem. The merge queue that’s slowing down the mobile team will eventually impact the web team. The broken deployment process that frustrates Engineers will eventually slow down feature development and Product will feel it.

You can wait for someone else to fix these things, or you can treat them like what they are: opportunities to create value, build credibility, and make your entire organization more effective.

Just remember to balance this instinct with good judgment. Take ownership of problems you can actually solve, communicate what you’re doing, and don’t let it derail your primary responsibilities, unless there’s value that is.

Because at the end of the day, the engineers who advance their careers — and their companies — aren’t the ones who stick rigidly to their job descriptions. They’re the ones who see problems and fix them, even when nobody asked them to.

Especially when nobody asked them to.

What’s the most significant problem you’ve solved outside your official responsibilities? I’d love to hear your ownership stories — the good, the bad, and the politically complicated.