Distrust Breeds More Distrust
When You Don't Trust Your People, That's THE Problem You Must Fix
I was called into a meeting room by my manager, together with all six Product Managers who reported to him, where he announced the following:
“I’d like all of you to be on-call for production issues. You’ll be the first line of contact and be woken up to investigate the issue. Your job is to wake the developer, who will fix the issue and stay awake until it’s fixed. Then you must check that they’ve fixed the problem.”
I was shocked and didn’t see this coming. The prospect of being woken up at night, potentially even during the weekend, didn’t excite me.
In my head, the proposal didn’t make sense for the following reasons:
I literally can’t do anything to fix the issue itself.
My only job would be to be the person in between who checks the developer's work. Basically, my job would be to inspect quality in their work.
I would have to stay awake twiddling my fingers until the issue was fixed, which sometimes could take many hours.
So, I immediately asked my manager:
“Why do we have to be on call? Because there’s nothing we can do to fix the issue?”
Their response:
“I don’t trust our developers to fix the issue adequately. Someone needs to check whether they did a good job.”
That answer wasn’t good enough for me, so I immediately said that I refused to be on-call. If we can’t trust our developers to fix a problem, then that’s the problem we must fix.
My refusal to participate meant I was the only Product Manager who didn’t have to be on call. I felt bad about it, as the rest of the team did have to wake up and wait till production issues were resolved, but I still firmly believe I made the right decision.
I did not want to support a way of working based on distrust, because inspection of problems is too late.
Inspection is Too Late
As Deming expressed much better in his book Out of the Crisis:
“Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product.”
Having product managers on-call was a duct tape solution to the actual problem. By applying the duct tape solution, the problem would be deprioritized and made worse because distrust breeds more distrust.
The Cycle of Distrust perfectly illustrates what happens when you don’t trust your teams.
The Cycle of Distrust
Leaders don’t trust their teams. As a result, we create rules, processes, and hierarchy to prevent having to trust our teams. We end up with many accountability sinks, where following the rules and policy we’ve agreed upon is the crucial thing we care about.
Due to all the rules, processes, and layers, teams struggle to make decisions and deliver. Because the teams don’t deliver the results we want, leaders don’t trust their teams even more.
And then, we fall back to our trusty old friend of adding more rules, processes and hierarchy to resolve our distrust. Then, the Cycle of Distrust kicks off again.
As a result of looping through the Cycle of Distrust, we end up with an organization where we can’t trust our people. They are too busy feeding the system and complying with accountability sinks.
The teams will accomplish less and less until we add more rules and policies that make them perform even worse.
How do we prevent the Cycle of Distrust from creating an organization where we can’t trust our people?
Start with Trust
The solution is simple: start with trust. Whenever you’re in a situation where you can’t trust your people, that’s the problem you must fix.
Just like you can’t inspect quality in, you can’t build trust by removing accountability. You might temporarily fix your situation but end up with something far worse: an organizational system that removes ownership and accountability.
If you want teams to take ownership over results, the starting point should be trust. And if you can’t trust them, that’s what you should be actively working on.
Distrust breeds distrust. You don’t want to end up with an organization where you can’t trust your people.
Starting with trust is hard, and you may encounter far more problems in the short term. But in the long-term, it’s the only way to go if you want teams that can take ownership and accountability over results.
I would love considering hard to believe that so many managers don't understand why you need to "walk the floor", but after many years, it's now for me common experience to find managers that follows the ceremonies but don't believe in the process.
As engineer, I was often on call. Even junior, barely fresh out of graduation, I was having a pager and had to take a taxi (no buses after midnight) and be on the floor. At first, I was like you: what I'm doing there? But once there, I started listening: people were panicking, stress by the issue, literally saying the money going off when the assembly line was stopped, and the account managers stressing because the orders were going to be late, etc. So, I started doing what I can do. I wasn't able to help directly, I wasn't a technician to understand all the details, but I was able to be a rubber duck, staying calm, taking care of the account managers and the clients, giving them explanation they can understand, and also simple gestures, like offering to get some coffee for everyone. I kept this habits both as engineers, being there for my colleagues, but also as manager and now CTO. When there is an incident, I joined my team, asked to be in the warroom, asked gently what's going on, help them focus and organize things a little. If I see someone too tired, I ask him to go sleep and manage to find someone else. Or if I found out the problem is too difficult, I help the team figure out a quick bandaid (even something like a technical problem warning), so they can go rest to come back afresh. Both most of the time, I'm just there, even remotely, and my EM and directors that reports to me always came back that the team really appreciates I was there. They feel supported, not under surveillance.
And sure, I also inspect the work, both what it's done and what is done. That's central to any empirical approach. And feedback is not a guarded field (contrary to adaptation): anyone can contribute, even passive observers (it's all about how to do it however).
And all those things work together: you can't adapt without inspection, you can't inspect without transparency, and... you can't have transparency without trust. But seeing a team being transparent when things go wrong, taking feedback without being defensive, and learn and adapt actually build trust.
As I told my teams, trust is not something you ask for, it's something you earn. I earn their trust by being fair and honest, recognizing their good play, the efforts they put in their less good play, and having their back when things go wrong. They earn my trust by being transparent, honest, open to feedback, and taking it seriously and working to learn and improve on it.
But what the result of all this? How a team shows they have learned and adapt? Generally, through a new or improved practice. And that practice put on paper becomes a new process. A process the team has learned to trust because is the result of all the errors, inspection and adaptation of people before them. A process born from trust rather than distrust. A result of the ownership and accountability of the team rather than an unaccountability sink. Something the team can rely upon when they aren't sure or under duress because it was built and refined all the time by themselves or their peers.
If people could understand that, could understand where processes came from, to see them as lessons learned rather than shackles for distrusted employees, maybe we would have better process in the end. But as long as we are seeing processes as a product of distrust, I'm afraid we are doomed to reinvent the wheel again and again.
Simple but entirely on target. I think when I work with my teams, I try to get them to confront what processes seem to undermine their responsibility/accountability but also, have they proven themselves true to that accountability?