Recently, I’ve been reading Leadership Strategy and Tactics: Field Manual by Jocko Willink, which builds on the bestselling book Extreme Ownership. What it has me thinking about is a common misinterpretation of ownership, and what to do about it.

Consider the following scenario that I’ve found to be somewhat common in a number of distributed team settings: You own a service or tool that just had a major failure, and in the course of the root cause analysis, you’ve found a clear, direct cause. That cause is one of your dependencies owned by another team. They (legitimately) introduced the bug or failure scenario, and you were a downstream impact of that mistake.

Job done? Well, that’s the anti-pattern. You might call it job done, pass the root cause analysis on to that team, and write it off as an unreliable dependency. You’re even technically correct! But it’s the completely wrong approach if you want to build reliable services, tools, or operational processes.

Let’s go to the definition of the titular principle of “Extreme Ownership” in the book of the same name - emphasis in this passage is mine:

“On any team, in any organization, all responsibility for success and failure rests with the leader. The leader must own everything in his or her world. There is no one else to blame. The leader must acknowledge mistakes and admit failures, take ownership of them, and develop a plan to win.”

In other words, when your dependency failed and you therefore experienced a failure? That’s your own fault. Your dependency owns their failure too, and should improve their own product and processes. But if you’re demonstrating ownership, you’re responsible for keeping failures from impacting your users and customers. There is no one else to blame.

When you do this wrong, you’ll avoid some extra bugfixing work maybe and spend more time on features rather than rooting out failure points in your system, but read that sentence again. You’re not spending time rooting out failure points in your system. In the long run, you’ll be making your own luck, as you seem to find your dependencies breaking your product more often than your peers seem to suffer that same fate. You have a brittle system. You’re failing your users and customers.

So what can happen when there’s no one else to blame? From “Leadership Strategy and Tactics” (emphasis from the book):

“When a leader knows they cannot blame anyone or anything else, they will implement what I call preemptive ownership - they will take ownership of things to prevent problems from unfolding in the first place.”

If there is no one else to blame, you take preemptive ownership. You ensure that even in the face of sometimes unreliable dependencies, that you can continue to function as much as possible. You’ll work to mitigate problems before they can even happen, or look around corners to harden your system to prevent “what could have been” when what happened was only a small failure on the surface. You’ll make every conceivable effort to harden your systems, and then the inevitable failures from dependencies and partners is downgraded to an inconvenience, and often, something your end users or customers don’t even notice.

I’ve seen teams that behave this way, and I can vouch for it - in the fullness of time, you end up with remarkably resilient systems and processes, and just find yourself having fewer problems. It’s an investment, and it requires checking your ego at the door, but it’s nice when your bug count is a lot lower than your peers. It’s achievable too with just a little bit of preemptive ownership.

(Thanks to Andrea Palmiter for reading drafts of this post.)