Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Limits of Too Much Trust

Managing Expectations
Feelings Aside
Performance

30 September, 2020

Brian Guthrie

Brian Guthrie

VP of Engineering at Meetup

Brian Guthrie, VP of Engineering at Meetup, explains where are the limits of too much trust and why verifiable trust is the only trust befitting the workplace.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Build Rapport With an Introverted Manager

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.

Managing Expectations
Internal Communication
Collaboration
Coaching / Training / Mentorship
Juniors
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

Managing Team Collaboration After an Acquisition

10 November

Han Wang, Director of Engineering at Sonder Inc., shares the ins and outs of working successfully with the other half of the team after a merger.

Acquisition / Integration
Large Number Of Reports
Company Culture
Performance
Han Wang

Han Wang

Director of Engineering at Sonder Inc

How Data-Driven Products Help Customers and Increase Sales

11 November

Richard Maraschi, VP of Data Products & Insights at WarnerMedia, shares his insight on incorporating data science, AI, and product management to overcome slowing growth of the company.

Product
Conflict Solving
Users
Data Team
Performance
Richard Maraschi

Richard Maraschi

VP Data Product Management at WarnerMedia

How Technical is Your Conversation?

3 November

Sambit Kumar Dash, Founding Director at Lenatics, shares an analogy-based technical conversation.

Managing Expectations
Product
Convincing
Users
Sambit Kumar Dash

Sambit Kumar Dash

Founding Director at Lenatics

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.