Inspection and the limits of trust.

For a long time, the path to engineering manager began with a prolonged stint of technical leadership. Then you’d transition into an initial management role that balanced people and technical responsibilities. Some companies call this a tech lead manager role. Folks entering those sorts of managerial roles were often the senior-most technical contributor on their team. If they struggled with the transition, many of them would fall back into the familiar habit of technical leadership instead of developing the new skills of people management.

The industry’s long-term solution to this challenge has been the ongoing decoupling of technical and people leadership into distinct roles. Today it’s common for first-time managers to get the advice that they should immediately stop writing code at work.

The shorter term solution is a piece of advice that echo across the halls of the industry, and that you probably received early in your management career: trust your team.
Trust your team.
Trust your team.

This advice is sufficiently correct that it’s easy to misapply. Among the senior leaders I’ve worked with, I’ve seen folks cause far more harm applying this advice too literally than by ignoring it. Leading effective and collaborative teams requires a nuanced approach to trust.

Limitations of trust

When a leader joins a company, they join with a large reservoir of trust based on navigating the hiring process. Why would you hire someone who isn’t worthy of your trust? The most effective leaders start by understanding their new environment, but a surprising number of new leaders jump into the new environment somewhat recklessly. That initial stockpile of trust doesn’t go particularly far when you start burning it immediately. It would be comforting to believe that their manager would step in to set expectations or course correct the new leader before they damage their own credibility, but often that doesn’t happen.

When you go to chat with the new leader’s manager, they’ll talk about their leadership style of “managing through trust.” If you play this scenario out a bit longer, the new leader keeps thrashing around in the organization’s water, their manager keeps trusting them, and a year later the new leader isn’t so new anymore. Now they’re a known quantity, in particular a quantity known for the quality of their execution: not so good.

Shortly afterwards they drift out of the company with some quiet angst against their manager. Their manager marks them down as unregretted attrition, sighs about missing the obvious signs in the interview process, and restarts the process from the beginning.

This scenario should be a hyperbolic example, but it took me about five minutes to list ten cases of this happening in my personal experience. Some of them, I’ll admit, were scenarios where I was the trust-embracing manager who inadvertently undermined the new hire they intended to support.

Trust isn’t a management technique

Trust on its own isn’t much of a management technique. Trust cannot distinguish good errors (good process, good decision, bad outcome) from bad errors (bad process, bad decision, bad outcome), nor can it detect bad successes (bad process, bad decision, good outcome). If you rely too heavily on trust, randomness will have an outsized influence on who you consider to be an effective leader.

However, trust is a powerful component of effective management. In particular, it’s the foundation of an approach that I call inspected trust. When someone brings a problem or a concern to you, trust them that there is a problem, but give yourself space to independently verify their interpretation of the problem:

• If a member of your team mentions that another team is causing problems, trust that there is a problem. Then find a way to verify the problem independently and explore alternative explanations to consider. How do other teams involved feel? Is there missing context from a third party that might be preventing the other team from engaging?
• If a manager mentions someone on their team is causing problems, trust that there is a problem. Then, once again, find a way to independently verify the problem. Have a skip-level meeting with the individual. Have lunch with that person and their team. Review the latest project reports for the team’s projects.

Occasionally, I’ve had folks push back on me inspecting their work, arguing that I should just trust them. This is a short-term perspective, and in my case has always been a reflection of a deeper relationship challenge between me and the individual I was working with. Your goal in working together is to help each other succeed, and that includes catching each others’ mistakes. Inspection is a gift: it’s taking the problem seriously enough to ensure we’re getting to the bottom of the actual problem at hand. (As an aside, inspected trust isn’t strictly something that managers do for their team, many of the best folks I’ve gotten to manage have diligently inspected everything I told them, refining my rough proposals into something much better, and catching me when I’ve gotten too attached to my own interpretations.)

I’ve also found that some leaders push back on the idea that they should inspect their team’s work. Their concern is that inspection signals a lack of trust in their team. This is a comfortable belief, but it’s ultimately a belief that undermines you and the folks you manage. Even the best folks you’ll ever work with are occasionally wrong despite following good process and making good decisions. Blind trust misinterprets good errors as being untrustworthy. It’s hard to build relationships for the long run when you routinely mistake good behavior as untrustworthy.

Inspection tools

There are many effective styles of inspection. The ones that work best for you depend a bit on your personal leadership style, understanding what energizes you, and the specific problem at hand.

Some inspection approaches that I’ve seen used to good effect:

• Inspection forums. The default inspection strategy for established companies is setting and tracking goals, typically in a weekly or monthly metric review forum. Quarterly review forums are too slow to serve as a principle inspection too (things can go very wrong in a quarter, especially in a new area or with a new leader).
• Engage directly with data. Many senior leaders rely exclusively on highly prepared data to understand challenges, but prepared data includes the bias of its preparers. Accumulate a small set of data sources whose preparation you understand in detail (what is omitted? what is included? what kinds of bias does that preparation potentially introduce?) and cross-reference those against new information to cross-check what’s presented to you.
• Learning spike. After getting a sense of a problem, drill deeply into the problem by talking to as many folks involved as possible. Focus on talking to folks across functions and to whoever is directly doing the work. Avoid spiking with folks whose job it is to summarize other people’s work, although these folks are often the best place to get a list of folks to talk with. Spikes work because they bypass the existing information hierarchy. Hierarchy is great at condensing too much information into a narrative, but narratives are crafted by selecting information. Selection implies omission, and sometimes a well-meaning narrative omits essential data. Avoid all this by going straight to the source.
• Fundamental intolerance for misalignment. Some leaders have a deep fundamental intolerance for confusion and misalignment. They’ll hear a slight bit of confusion in a meeting and keep digging on it until they understand what caused it. This ongoing intolerance surfaces and resolves the sorts of problems that left unchecked would undermine trust. Before getting too excited about this approach, my observation is that folks who rely on this approach often get weeded out as “immature” middle managers within larger organizations, failing before they reach a level where the behavior is rewarded.

The most effective leaders that I’ve worked with are particularly comfortable with one or two of these but are capable of using the full toolkit depending on the problem at hand. If you’re working in, or aspiring towards, a senior leadership role, I’d encourage actively practicing all of them until you get comfortable. After you’re comfortable with all of them, it’s fine to lean more heavily on those that feel more natural as long as they fit with the problem at hand.

Don’t come away from this deciding that you shouldn’t trust your team. You absolutely must trust your team to scale as a leader. Even more importantly, though, I hope you appreciate that merely trusting your team is abdicating from one of the most important parts of your role: helping your team succeed. Errors are a natural part of work, and inspection allows you to maintain trust through errors. Inspected trust is work and it takes time, but it culminates in an organization that polishes leaders for the better. The alternative appears to work in the short run, but leaves you with a rotating cast of short-term leaders.