Ownership as a Double-Edged Sword

📚 Human-Scale Engineering - Part 3 System Architecture #Ownership
Table of Contents

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.

Comments