Trust, but verify

I’ve always disliked this phrase, and it felt like a pure contradiction - you wouldn’t need to verify if you truly trust. It has come up recently in my life and work, so I decided to dig in and crystallize my thoughts.

The phrase originated as a Russian proverb (doveryai, no proveryai) and is attributed to Vladimir Lenin and Joseph Stalin. Inauspicious beginnings, to say the least. Ronald Reagan then co-opted it in 1986 to refer to nuclear disarmament, and from there, it entered the American lexicon. People often consider it a leadership principle or some fundamental truth, which needs more nuance. 

As a leader, one must decide how to operate in different contexts. A good initial posture is to distrust and verify often until you have built up the appropriate level of trust over a long enough period. I’ve had so many occasions in my career when I heard some variant of:

• The code is terrible

• The code we’re writing is excellent!

• That’s impossible

• That will take months

• We’re in a good state now

• We fixed it

• I’ll get back to you on that

• This is only impacting a few users

In many cases, I’ve trusted what I’ve been told, only to be proven wrong in a painful manner weeks or months later. As I have grown and taken on larger organizations, I have been inclined to “get out of the weeds” and let the teams do their jobs. Looking over their shoulder is micromanagement, which is evil and should be avoided at all costs, right? I began my career as a manager viewing micromanagement as problematic, and I prided myself on giving teams lots of space to execute independently. In hindsight, I went too far, and I now believe this intuition to step back is incomplete. A better posture is to find ways to empower the team while getting incredibly close to the details.

Hands-on Empowerment 

In my role, being hands-on means reading and writing code, looking at alerts, pulling reports, querying databases, and commenting on JIRA tickets. For a long time, I felt like this work was a poor use of time for a CTO leading a team of ~120 people. I’ve realized that I got into this seat by being good at all of the above, and neglecting to leverage those strengths is a mistake. Here is how I have tried to do this in an empowering way vs. a micromanaging way:

• First, you have to build trust with your team. The First 90 Days has a great playbook that is worth following in any new role. 

• You’ll know you’ve built trust when people are “bringing you the bad news,” demonstrating vulnerability in front of you, and asking you for help. 

• At this point, it’s appropriate to become more hands-on

• The most important quality to build as you lean in is curiosity. Whenever I find something that looks off, I start with a question:

• Hey, I noticed these error logs spike at 5 pm every day. Do we have any idea what that could be?

• I was reading this code last night, and we might not handle an edge case properly. Am I interpreting this correctly? 

• I looked in the database and noticed that 500 users appear to be in a bad state. Here’s the query I used. Does this look right?

These questions need to be genuine and caring, with the right tone. There’s a massive difference between “How the f*ck did this happen?!” and “I understand the team has limited capacity, and I want to support you. Help me understand how we got here and what we can do to prevent another incident like this one.” There are many resources on Blameless Postmortems, and that’s the attitude you should bring to any issue you find, even if it’s minor. 

Being this close to the details requires fairly deep technical knowledge and the ability to navigate your team's systems daily (source control, monitoring/alerting systems, infrastructure systems, project tracking tools, etc.). This has the side benefit of exposing you to your team's workflows, which is its own form of verification. If it’s tough to correlate logs, that’s a smell! Put a project on the backlog to fix it. If it’s hard to deploy changes, that’s a smell! Make sure the team invests in CI/CD. If something breaks and there’s no automated test to catch because it’s too hard to write a test, that’s a… you get the idea. 

The last piece is fixing things yourself when you find broken things. If all you do is point out the trash on the ground and ask people to pick it up, you will lose the team's respect. Pick the trash up yourself. The garbage can is right there. 

Practically speaking, this looks like writing minor bug fixes, writing terraform to change production infrastructure, deleting unused infra, running Incident Command, and occasionally waking up at 4 AM to conduct maintenance windows. Sometimes this even takes the form of larger projects that are non-blocking. I spent a few months pair programming with someone on my team to rewrite a service that has long been a buggy, poorly performing thorn in our side. We got the work 80% of the way and then handed it off to an internal team once they could take on the job. 

I don’t always get the balance right, although I’m trying to raise my awareness and solicit feedback on this regularly. I still have times when a mistake happens, and I wish I had been closer to the work. I also have times when I know I need to back off and educate the team instead of doing the work myself. My focus now is staying close enough to set the tone for the team and make the bar for quality clear.