You build it, you own it

Why don't the high performing teams stop at the "run" level?

Back in 2006, Amazon CTO, Werner Vogels said:

You build it, you run it

It is easy to understand why a company that has built a strong empire around running software would focus on the “run” part. 💰

But allow me to elaborate why the real magic happens with full ownership:

You build it, you own it.

But why?

Does any of these problems sound familiar?

• Knowledgeable people feel frustrated by poor leadership decisions. They know better and would rather be in control of their destiny. The most knowledgeable employees leave the company because they have better options. The rest act as if they are in a coma: the brain is not connected to the muscles! “Knowledge is power” only when there is a mandate to act upon that knowledge.

• The developers throw the code over a metaphorical wall for the IT operations to run and deal with incidents. The operations team is responsible for keeping the software running without actually understanding or having a say in how its architecture, implementation, tests, and the scope of the problem it solves. They may feel like they are babysitting the developers cleaning up their sh**t and they may actually be right! 🍼

• Top level managers abuse their mandate to dictate how the teams should solve the problems without truly understanding the nuances of the problem or having to wake up in the middle of the night when things break. Workarounds and tech debt are rampant, and the focus is on the deadlines and cost instead of quality. That is a monkey with a gun situation! 🐒🔫The monkey can shoot without knowing the consequences or having to worry about going to prison!

• Managers block or postpone decisions because they don’t understand the consequences and rather play it safe not to get into trouble. They demand all decisions to go through them and turn themselves into bottlenecks. Every decision feels like a gamble which justifies their conservatism.

• Engineers call all the shots but accept no responsibility like teenagers. They push for the empowered product teams but only the parts that benefit them. If there’s an incident, it is somebody else’s problem. They’re not the ones on-call after all. As a consequence, they miss learnings from incidents and the product fails to improve in meaningful ways that prevents reliability issues from being addressed in a proper way. The consumers either have to put up with a buggy product or worse: leave for competition.

• Developers acting as foot soldiers doing what the management tells them to do and paying for the consequences. They feel they’re being micromanaged and there’s no trust in them making the important decisions. Again, everyone who can get a better job leaves the door leaving the room to passive employees who put up with whatever the “management” throws at them. They’re practically treated as code monkeys. ⌨️

Depending on where you work, you may find some of those problems exaggerated but I guarantee you that I’ve experienced all of the above in my own professional career.

Ownership Trio

Let’s recap:

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 knowledge only if you are fully responsible for the consequences of your mandate.

You can see how knowledge, mandate and responsibility feed each other and are inseparable.

These are the key aspects of the ownership trio:

And there’s a good reason for that:

Only through full ownership the team can reach autonomy, mastery and purpose. There’s no shortcut to quality and reliability other than putting smart people fully in charge of implementing the vision.

That sounds a bit fluffy and high level even though I borrowed 3 words from Daniel Pink’s Drive.

In the upcoming articles I will break down the elements of the ownership in multiple levels:

• Individual: how do knowledge, mandate and responsibility empower a developer or tech lead to do a better job? I’ll share examples from my own career as Sr Staff Engineer.

• Team: how does team ownership work and what are the pitfalls to watch out for? I have a great example from my time at Discovery.

• Organization: how can these autonomous teams align on a common vision and deliver without stepping on each other's toes? This is where I finally do a follow up to the Strategy basics and Strategy glossary posts.

We also talk about what is the catch because if it was that easy, all monkeys would be in prison!

Recap

Full ownership requires all three elements:

• Knowledge

• Mandate

• Responsibility

Ownership has multiple layers and many pitfalls which we’ll get to in future articles.

If you find this article interesting, please share it within your circles and social media to raise awareness and lift the happiness and collaboration of teams across the world. 🙌

Follow up

This article has three “bugs” that will be addressed in follow up posts:

1. Full ownership promotes extreme autonomy. How do you align these autonomous teams? See strategy

2. How do you implement responsibility in practice? Service levels and Lagom SLO.

3. You’re expecting a lot from the teams to own their DevOps. How can they handle the cognitive load of full ownership? Using better tools, education, and SRE.

Check out the witty article about broken ownerships here: