Ownership as a Double-Edged Sword
Ownership as a Double-Edged Sword
Ownership is considered a cornerstone of stable engineering. “Making it clear who’s responsible” is almost always seen as a solution.
But in complex systems, Ownership doesn’t just protect - it also creates dangerous boundaries.
The Illusion: More Ownership = More Responsibility
When something breaks, the first question is: “who owns this?”
And when there’s a clear answer - there’s a feeling of security.
But that security is misleading. Because Ownership defines not just responsibility - it also defines what’s not someone’s responsibility.
When Ownership Prevents Improvement
Ownership starts to hurt when:
- A problem crosses the boundaries of more than one team
- No one owns the full picture
- Every team “optimizes” its own part
In this situation, no one is acting maliciously. Everyone is doing their job well.
And the whole system deteriorates.
”Not Mine” Zones as Sources of Risk
Many severe failures are born not in places without owners - but exactly where there are too many boundaries.
That’s where you hear sentences like:
- “That’s not on us”
- “We’re just consumers”
- “Our SLA is fine”
Everyone is right locally. But no one sees the accumulated risk.
A Simple Example
Service A is responsible for authentication. Service B is responsible for data. Service C is responsible for user experience.
When there’s abnormal latency:
- A says: “authentication is fast”
- B says: “the DB is meeting its targets”
- C says: “we’re just displaying”
There’s no clear bug. There’s perfect Ownership.
And the user suffers.
Why More Ownership Doesn’t Always Mean More Responsibility
Good Ownership works when there are:
- Sharp boundaries
- Local problems
- And one-directional impact
But in live systems:
- Effects are mutual
- Failures accumulate
- And damage doesn’t stop at a service boundary
At this stage, Ownership needs to shift from “who’s responsible for the code” to “who’s responsible for the behavior.”
The Bottom Line
Ownership is a powerful tool. But like any powerful tool - you need to know when it blocks more than it protects.
Mature systems don’t eliminate Ownership. They add a layer of systemic responsibility on top of it.
Looking Ahead
If Ownership alone isn’t enough, maybe the problem isn’t the people - but the processes they’re required to work within.
In the next post we’ll cover processes born for scale - but that strangle responsiveness.
📚 More in this Series: Human-Scale Engineering
- Part 1 The Organization Is Part of the System (Even If You Never Wrote a Line About It)
- Part 2 Incentives Are Stronger Than Architecture
- Part 4 Processes Born for Scale, But That Kill Responsiveness
- Part 5 Why "Alignment" Is a Dangerous Concept
- Part 6 Leadership That Allows Mistakes, Rather Than Preventing Them
- Part 7 Why Organizations Struggle to Learn
- Part 8 When an Organization Has No More Capacity to Improve
- Part 9 When You Need to Break an Organizational Structure
- Part 10 Engineering Is a Social System
- Part 11 What We Actually Learned About Human-Scale Engineering