Limits of Too Much Trust

Problem

Several years ago, one of my reports had been approved for a transfer to Berlin. What I learned later was that between the time they have been approved for transferring and the time they went for Berlin, they simply stopped working. I learned of that too late and was not successful in getting a transfer stopped.

For me as a leader who invests heavily in a notion of extending trust to people and who believes in a high trust concept within an organization, I felt for the first time that that trust was violated and it taught me the value of verifiable trust, the only trust befitting the workplace.

Actions taken

As I was running a couple of cross-platform product teams that worked across several different codebases I didn’t make it a practice to read all pull requests running through the team. I had to trust that the team was taking care of itself and that someone working the iOS base, for example, was doing the work that was expected of them. Also, it was a slightly larger team of 13 or 14 people and I wasn’t able to pay very close attention to what every individual on the team was doing.

Gradually, I realized that stories were getting stuck and weren’t quite moving through and the person responsible for that was not showing up at a couple of meetings where this was discussed. What I finally did was something I hadn’t done before -- I dug into that source code repository and scraped it looking for commits with their name on it.

I felt very uncomfortable and I didn’t like running that kind of audit, but what I found was that there weren’t any commits with their name on it. They had submitted nothing to the main code branch of that repository for a month and a half. They told me that the team in Berlin wanted them to do a bit of work and I hopped on to a call with them sharing my concerns about this person’s productivity. Needless to say, they were surprised to learn that this person was allegedly helping them. Then I started looking back at past meetings -- at that time we ran sprint planning meetings every couple of weeks -- and they have been absent for the last three of them. Though that seemed like an isolated incident at the time, they added up to a picture of someone who knew they would be leaving and therefore stopped working.

I understood that some drastic action was needed, but I nevertheless went to this person and shared with them what I found out. I extended them the benefit of a doubt and waited for two more weeks for them to merge the code as promised. That had never happened. They were in the midst of the transfer process and I wasn’t clear that I had the right to terminate them out.

I spoke to our VP of Engineering and laid it all out. I assembled a spreadsheet showcasing it all, not because I relished it but because I felt it was necessary. They ultimately made the decision to transfer that person to Berlin and from what I’ve heard they became a disciplinary problem later.

Lessons learned

• At that time I felt like a failure as a leader who didn’t manage this person adequately. Having discovered the issue I could have managed it in a way that was either better for them or better for the company or more generally navigate through those waters more effectively.
• Back then, I was encouraging people on the team to practice pair programming. He was stubbornly opposing that. In retrospect that also revealed a pattern of behavior that could alarm me, but I chose to trust them.
• I try to hold in my heart this conviction that at the end of the day people want to be at their job doing productive and meaningful work. That was not true in their case and I resisted accepting that.
• I re-evaluated what trust could and should mean for a leader. Not only that trust should have its own limits but that verifiable trust is the only trust befitting the workplace.