6 Archetypes of Broken Ownership

What if 1-2 elements of the ownership trio are missing? And how to fix that?

In “you build it, you own it” we discussed the ownership trio with these elements: knowledge, mandate, and responsibility.

The rationale was:

1. You cannot be responsible for something you don’t control. You need the mandate.

2. You cannot use that mandate effectively over something you don’t understand. You need knowledge.

3. You gain experience from running something and learn from the mistakes when things go wrong. You don’t use that knowledge to optimize it if it’s not your problem. You need to be held responsible.

Unfortunately, broken ownership is much more common than true ownership which leads to frustration, demoralization, and poor operational performance.

This article discusses the 6 archetypes of broken ownership.

Only Mandate

This is a monkey with a gun scenario where one (usually the manager) calls the shots without a good level of understanding the system or being held responsible for the consequences: on-call, alerting, debugging, rearchitecting, etc.

Top-down hierarchical organizational cultures are especially vulnerable to this type of broken ownership.

Some managers who were formerly developers know enough to be dangerous but dumb enough to push their opinions when the team doesn’t put a good fight. Instead of creating a safe space for the team to experiment with, they want to take control and run things. But they don’t really run things. That’s the whole point of this series!

When there is low trust, large ego, and fixed mindset, it is easy to fall into this trap. People with knowledge and responsibility feel micromanaged and demoralized.

Source: Milani

Responsibility + Knowledge - Mandate

The complement of the monkey with a gun scenario is the foot soldier: the ones with the knowledge have the responsibility but no mandate.

They can’t drive any meaningful and impactful change as long as they have to go through someone else who lacks both. As a result, they get frustrated and demoralized.

Those who can find a better job will leave. The company will be left with those who can’t see a step ahead of themselves because honestly, they either don’t care, don’t know what they’re missing, or don’t have a better choice.

If you listen to people with mandate, they often cry about “running a kindergarten” without acknowledging their role in creating it in the first place.

This is my biggest objection to the phrase:

You build it, you run it.

Because it misses the full spectrum of duties that is required to fully own the product or service. It is not about running things. It’s about fully owning it:

You build it, you own it.

This situation can only change when those in mandate know what they don’t know and start growing their org to take the lead. David Marquet’s Turn the Ship Around is a best-seller in this topic.

Turn the Ship Around: A True Story of Turning Followers into Leaders

Only Responsibility

This is a baby parent scenario where you have no knowledge or mandate over why and when the sh*t happens but you gotta clean it up anywhere.

Being responsible for something without having a good understanding or any control over it, at best leads to a passive attitude and at worst leads to burnout.

This is common with IT infrastructure, DevOps, or NOC (network operations center) teams. Some of these teams call themselves SRE (site reliability engineers) but have little to no interest in understanding the thing they are responsible for.

[SRE is] what happens when you ask a software engineer to design an operations function (src)

A friend of mine put it well:

To know the difference between SRE and DevOps ask them what they do when an incident happens:

• DevOps rolls back (reverts the changes, treating the system as a black box that should go to the last known good state)

• SRE fixes forward (fixes the problem and commits a new change)

😁I don’t think it’s a universal rule but there’s some truth to it.

Mandate + Knowledge - Responsibility

This scenario resembles the experience of being a teenager! One has enough knowledge about how the world works to make decisions but when it comes to consequences, the responsibility is often missing!

Teams that are in this situation often think they have full autonomy and take bolder risks, but they often end up hurting the business and losing the mandate.

Typical symptoms include finger pointing (not my fault), broken DevOps (throwing the code over metaphorical “wall” for the infrastructure to run), and a disconnect with business and product folks.

I’d argue that the knowledge element is severely limited to the technical aspects because being responsible for running a product is a great source of learning.

Only Knowledge

This feels like coma! Those with knowledge are isolated from any control or responsibility. It’s like having a dream without any control over the body. And who is responsible for a dream? 😁

Ideally demonstrating the knowledge leads to earning trust and accepting responsibilities which may grow to having the mandate. But there is a catch 22: without having any mandate, it’s hard to demonstrate the knowledge.

Mandate + Responsibility - Knowledge

Oh, my favorite; The gambler! Those with mandate and responsibility don’t have enough knowledge to make the right decisions or even understand their full responsibility.

They don’t know what they don’t know! Many decisions are made with gut feelings and impartial data, and they’ll pay for consequences.

Unfortunately, this is more common for operations or infrastructure teams where a lot of decisions are made without the developers in the room. It hurts trust, growth, and productivity. The developers are kept in the dark and don’t even have access to the systems that run their code in production.

This situation is usually created due to lack of trust between operations and developers spiced with a bit of ignorance and old-school thinking.

The Phoenix Project is an interesting read if you find yourself in this situation and want a way out.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Recap

Putting it altogether, we get this image:

Check out the previous article to see why these three elements go hand-in-hand to shape the ownership trio.

This article took about 3 hours to draft, edit and illustrate. If you enjoy it, you could support my work by sparing a few bucks on a paid subscription. You get 20% off via this link. My monetization strategy is to primarily keep the content free and only rely on donation to support the hours I pull from my private time to share insights. Thanks in advance for your support. You can also share this article within your circles to increase its impact. 🙌