Have you been in any of these situations?
-
Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it.
-
Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room.
-
Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run.
In “you build it, you own it” we discussed these symptoms along with many others to establish the three components of true ownership: knowledge, mandate, and responsibility.
The rationale is:
You cannot be responsible for something you don’t control. You need the mandate.
You cannot use that mandate effectively over something you don’t understand. You need knowledge.
You gain knowledge only if you are fully responsible for the consequences of your mandate.
Unfortunately, broken ownership is much more common than true ownership which leads to frustration, demoralization, waste, and poor operations.
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.
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.
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.
This article is part of a series about ownership at the team, organizational and personal level. If you want to get the latest post delivered to your mailbox, here’s how:
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.
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.
But is ownership the answer to all problems? Actually no! What I proposed here has two “bugs” that I’ll address in follow ups:
-
How to align extremely autonomous teams?
-
How to deal with the cognitive load of owning everything in a team?
We will also talk about how this same framework can empower personal ownership and organizational ownership as well as why generalist roles should be the default and how to minimize the damage of specialist, ceremonial, and ivory tower roles.
This article took about 4 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. 🙌
Read the comments on Hackernews.