A riff on an interesting and thought provoking article by Will Larson: Inspection and the limits of trust..
Larson begins by identifying a well-known, if poorly understood, issue encapsulated by the Peter Principle: In large organizations, people are promoted to one level past their level of competency. My experience differs from Larson's in that large organizations do not recognize the need to decouple specialized skills (such as software coding) from the leadership and people skills required to succeed in management positions. The newly promoted are frequently left to figure it out on their own. Granted, my experience is limited to software companies or software divisions within large legacy corporations. Speaking from first hand experience, a senior software developer who is promoted to management and applies a software development mindset to managing people is painful. But perhaps there are other industries that are united around diligently working out long-term solutions related to decoupling the skills in specialized roles from management roles.
I am confused a bit by Larson's use of the word "leader" in this article. He talks about the leader as if they were the CTO or a SVP (even links to an article discussing this type of role) but then makes reference to the "leader's manager." Would that be the CEO or perhaps an SVP? The article doesn't align with either relationship. For the most part, the article seems to take the perspective of a manager who hires someone to lead one of their teams in some capacity. Taken as a whole, Larson's use of "leader" in the article seems to align with the latter so that's the perspective I'll assume in my comments.
Leading effective and collaborative teams requires a nuanced approach to trust.
Can't argue with that. The devil's behind the "nuanced approach," however. Lots to unpack there. Many techies-turned-manager slip and fall on this hidden bit of insight. Maybe it's just because there are more technical people in the world today and the younger generation seems a bit more savvy about things social in a fast moving world, but I'm seeing this as less an issue than it was, say, 20 years ago. Still an issue, though. Even successful nuanced approaches are largely unconscious and practitioners are unable to articulate what they're doing that's so successful.
When a leader joins a company, they join with a large reservoir of trust based on navigating the hiring process.
Not so sure that's a large reservoir. There is a tacit trust, a fragile trust. New leaders are an unknown quantity to the employees they are expected to lead. They represent a jungle of cognitive biases the new leader will have to find a way to navigate. Fortunately, most new leaders walk into unknown territory with a 3-6 month supply of tacit trust and whatever cache of new ideas they bring with them. In that 3-6 month window they have to figure out the lay of the land and what ideas can grow there. What is the character of the people they are leading - as individuals and as groups or teams? What needs to change, what can change, and what should stay the same? Collectively, this is known as the company culture. Almost immediately the intrepid new leader needs to start working the corporate soil, plant the ideas they need to grow and support an improved culture that helps employees thrive.
Why would you hire someone who isn’t worthy of your trust?
Well, of course you wouldn't. At least not intentionally. The trick is to figure out how to assess trustworthiness. That's a topic for a different post.
Trust on its own isn’t much of a management technique.
Trust isn't a technique at all. At best, it's a lagging indicator of sorts among many indicators for how a leader is doing. I say "of sorts" because trust isn't directly observable or measurable. But it certainly lags. Like a lot of resources, trust changes incrementally and is the result of bidirectional transactions between managers and employees. But here's the rub. It takes effort to build and maintain trust, but it erodes on its own. As if following the Second Law of Thermodynamics (with distrust playing the role of entropy), trust will erode or fade over time and requires constant effort to build and maintain. Absent that effort, trust erodes slowly until it collapses all of the sudden. It's disappearance usually comes as a surprise. A single event can build a significant amount of trust (e.g. some crisis where people come together to solve an existential threat) or blow it all to bits in a way that is irreparable. All trust is fragile in this way.
Inspection is a gift
Maybe. If it is, it's a gift that few people willingly unwrap when it has anything to do with evaluating any aspect of their performance. "Thank you" isn't likely to be the common response to such a gift. So maybe it's best not to frame it as a gift. Platitudes almost always backfire in surprising ways and due little to build trust. And "inspection" is one of those words that carries a lot of baggage. Larson doesn't write anything that suggests a manager should say the words "inspected trust" out loud in front of employees so I'll take the term to mean something that managers keep to themselves as part of their management lattice of mental models. If that's the case, then I can work with the idea of "inspected trust." The inspection tools listed in the article seem to be workable enough if they aren't obvious to the people that report to the manager. If they become obvious, then "inspection" will be inferred by the manager's employees.
Leveraging a different metaphor for new leaders, I find it's much more effective to think of the trust needed to have effective professional relationships as an explicit bridge that needs to be built in cooperation with individuals and teams. New leaders are given temporary trust bridges with each of their employees and teams. Before these temporary bridges erode, leaders need to establish their own permanent trust bridges or be left with a trust gap that results in an employee that drifts "out of the company with some quiet angst against their manager." Building trust in this manner means I have to find answers to a number of questions.
What does "trust" mean to a particular employee or team?
What makes someone trustworthy or untrustworthy?
Who do they trust now? Who do they distrust now?
How do they know when they can trust someone?
And, of course, it's never just about trust. Knowing where their loyalties are, their career aspiration, their work histories, and a whole host of other aspects can affect a leader's ability to establish trust.
Some thoughts on the "inspection tools"...
Inspection forums - This sounds like a good way to expose by behavior the mental model of "inspected trust." It probably won't end well. Although I can see a way such a forum could be facilitated, it would be fraught and at some point it's going to come down to something that someONE did that had an adverse affect. People don't like this, especially if it's visible to peers. Agile methodologies have much more effective ways of satisfying the intent (as I perceive it) behind inspection forums. Rather than just weekly or monthly goal or metric reviews, these reviews happen daily and weekly. More importantly, the daily "scrums" or "stand-ups" and the post-sprint retrospectives are at the team level, outside the view of management types. Without a doubt, team members are much more honest among themselves about underlying performance issues, particularly if they don't feel they're being evaluated or inspected by management. The quality of these daily and weekly interactions is very much dependent on the capabilities of the team's Scrum Master.
Engage directly with the data - The message here seems to be it's important to establish meaningful metrics - that is, no vanity metrics - and that they should be derived from objective sources. It's important to know what the metrics are and are not telling you about individual and team performance. Not an easy task, but critical to building trust bridges. If people feel they are being measured arbitrarily or they don't understand exactly how they can influence the metrics, they will not trust the numbers and, by extension, not trust anyone who puts too much stock-in-trade in questionable metrics.
Learning spike - I have no idea what this means. It's not in Larson's book and a search of the intertubes fails to enlighten.
Fundamental intolerance for misalignment - The caution added by Larson with this item is well advised. Chasing every single bit of confusion and misalignment would be a good way to piss off a lot of people, even those who trust you. In fact, a better approach would be to accept the confusion and acknowledge that the person or team is legitimately struggling to find an answer. Confusion and uncertainty are not inherently bad. They are fundamental to how people learn. You just don't want them stuck in confusion or uncertainty about their work. If they are confused but are moving in a direction, then let them struggle a bit and work it out. The techniques in many of the Agile methodologies are designed to work with confusion and misalignment in useful and productive ways. Intolerance toward confusion and misalignment is, in my opinion, misdirected. Better to be intolerant toward individuals and teams that insist on staying stuck by actually working to maintain and excuse their stagnation.
So there's my riff. All-in-all, I enjoyed the ideas presented in Larson's article and the ideas they challenged me to think through.
Photo by Johannes Andersson on Unsplash