Trust Before Ownership

Talk to most managers or executives and they will likely talk about how they want to empower their teams to take ownership over their products and systems.

Ownership and trust go hand-in-hand, but it can sometimes seem like a chicken or egg problem when you don't have one or both.

How can you trust your team to do proactively move the ball forward if they're not taking ownership over their work and their product?

Similarly, how can your team take ownership over anything if you're not willing to hand over the decision-making reins to your team?

A Tale of Woe: Ownership before Trust

I was once asked to take over a team that was suffering from this conundrum.

To set the stage, the engineering manager in charge of the team was working 80+ hour weeks, the morale of the engineers was in the toilet, and the product the team oversaw had just suffered its most severe production incident yet, one that had significant business implications.

My first task was ostensibly to conduct a postmortem on the latest incident and provide suggestions for how to prevent a recurrence, but I knew from early on that the problems ran much deeper than identifying a few bureaucratic process tweaks. It would involve getting to the root of how the team operated and redefining how the team operated at a fundamental level.

When I conducted interviews with both the manager of the team as well as other members of the senior leadership team, the following two points were made in quick succession:

• The team needs to take more ownership over their work.
• The team needs stricter oversight.

You might think: Wait a second, those two points seem contradictory.

And you would be right.

But what I realized was that the management team was trying to solve the problem of trust and ownership in the wrong order.

The leadership team was operating under the premise that the onus was on the engineering team to prove that they were taking ownership of their work before the leadership could place their trust in the team to be owners.

And to prevent a recurrence, they had already implemented the following procedural changes:

1. All code changes would now be deployed exclusively by the engineering manager (the one working the 80+ hours per week).
2. All deployments would have to be signed off by the skip-level manager (which became me when I came on board).

What they didn't realize was that by adding new layers to a system of strict bureaucratic top-down oversight, they were further killing the team's sense of ownership.

The result of these two changes?

• Velocity plummeted as a 5-person engineering team became bottlenecked on a single individual's deployment privileges. (It didn't help that the manager also conducted all code reviews for the team, because the manager didn't trust the team to do it right.)
• The individual contributors on the team continued to have no motivation to take on ownership responsibilities, and also did not have the opportunities to develop any of the skills that would enable them to take on greater ownership (e.g. code reviews and deployments).
• The total number of production incidents declined, but only because we were deploying far fewer things due to the new clogged process. It's easy to not have bugs when you don't deploy any code.

Flipping the script: Trust before Ownership

In order to get out of this vicious cycle, I had to flip the model around. We had to start building trust in the team first, to allow them to develop the skills and the confidence to take ownership.

But the leadership team did have a good point in their defense: the team did not have the requisite skills to be able to take ownership of their product.

This is where pair programming came to the rescue.

Recognizing that the engineering manager was currently the only person trusted by all parties to safely release code, I asked the manager to begin pairing with at least one engineer any time they were doing any coding, code review, or deployment activity. Most importantly, the engineers' hands would be on the keyboard, not the manager's.

After overcoming some initial resistance to the idea of pair programming (a topic for another day), we started to see positive results, as the team drastically scaled up their pace of learning and their understanding of the product. Eventually velocity began to tick up, as different pairs of engineers could now release code independently of their manager.

The next major change was to eliminate the bureaucratic sign-off rule that required me to explicitly approve any deployments. Instead, we developed a new checklist with the team that would ensure that we testing and verified the most important things both before and after we deployed code. The team was responsible for documenting that they went through this checklist. (Note: The system at the time had zero automated testing. We did, eventually, automate much of this testing, which is yet another topic for another day.)

And rather than requiring upfront permission to do something (which slowed things down and reduced the sense of ownership), the team instead declared their intention to deploy that something in a dedicated Slack channel, and allowed others to chime in if they had any questions or concerns, flipping the ownership of release management from leadership to the team itself.

The team quickly embraced the clarity the new process brought, as well as the responsibilities that came with it, and morale steadily improved. (And I was thrilled that I didn't have to get involved with every single piece of code the team wanted to release.)

The ultimate test came when the engineering manager eventually left to pursue another opportunity. The training wheels were officially off. I was a little apprehensive at first, but the team performed admirably. There was no drop-off in team velocity and the team was able to take full ownership over their product.

Teams know when they're not trusted

So why did flipping the model work?

Imagine I tell you I'm giving you a new laptop. You're probably pretty happy about it.

But now I tell you that you I'm going to set the password on the machine so every time you want to use it, you have to bring it to me to unlock. And every time you want to install something or download the latest security patch, you have to bring the laptop over so I can fill in the password for you.

I don't tell you this, but I want to make sure that you can be trusted with owning this expensive new laptop.

You're probably not going to feel like you truly own that laptop, no matter what I declare. And you're probably not going to go out of your way to download that critical security patch.

Similarly, no matter what you say as a leader to your teams about trust, they will know when they're not trusted to get the job done. And teams will respond to that lack of trust by responding with a lack of ownership.

So if you find yourself in a situation where you truly want to have your teams embracing ownership of their domains but are struggling to make it happen, try flipping your script and start by trusting your teams to do the right thing.

Further Reading

I felt compelled to write about this particular experience after finishing David Marquet's amazing book on leadership, Turn the Ship Around!.

I realized that I was unknowingly implementing some of his ideas, by trying to go from a leader-follower model (ownership before trust) to a leader-leader model (trust before ownership).

In the book, Marquet describes how to push control (i.e. ownership) down to the lowest level where they belong by leveraging two key supporting pillars: competence and clarity.

I believe the pair programming I described above is an example of increasing the team's competence by encouraging the rapid learning necessary to take on the responsibilities I wanted the team to take on.

I highly recommend picking up a copy if you haven't read it.