Why Don’t They Trust Us?
Have you ever walked into your favorite restaurant, ignored the menu, and asked the chef to surprise you? What made you trust the chef? Consider how you “do business” with a carpenter, plumber, or car mechanic you’ve come to trust. I love my car mechanic. I give him carte blanche to do whatever he sees fit to maximize my return on investment in my vehicle, and keep me and my family safe. He trusts me to pay up.
Now, imagine you are planning a wedding. You meet a caterer (or photographer) vying for your business. You’ve never met them before (or eaten their food). Do you ask them to surprise you? Or a new mechanic…do you ask them to “fix anything while you’re at it?” I’m guessing the answer is both cases is No.
So, let’s just cut straight to the chase. Most product development teams are not (fully) trusted to deliver a high level outcome or solve a problem. I say this with no value-judgement attached. A synonym for distrust is lack of confidence, which feels a bit better to say out loud. Why do we sometimes lack confidence in a team’s ability to deliver a high level outcome?
Note: We all fall victim to fundamental attribution bias whereby we’re more likely to attribute system-level reasons to our own problems, and blame other people directly. And, we may be ourselves lacking in experience.
So why, in internal software product development, do we see the New Mechanic, or even worse the Mechanic We Distrust But Are Forced To Use dynamic take hold? Shouldn’t the working relationships more resemble Our Favorite Mechanic or Favorite Chef? The distrust goes both ways as well…all of our bullets above could be reversed to describe how “the teams” feel about the people managing/leading them.
Instead of a customer/service-provider analogy, let’s consider a healthy team of carpenters (a partnership situation). What does the lead-carpenter do when an apprentice “can’t be trusted” to do a particular job? The LC pairs, teaches, and coaches. The apprentice accepts help. Bingo!
Why does this work? Let’s take a look at Larry Maccherone’s Trust Algorithm:
Where…
In our carpentry example, the lead-apprentice has credibility, they show an interest in the apprentice’s success, and they reliably provide help when needed.
Now, let’s take a look at a common dynamic in software product development.
I could go on and on. You get the idea. See how easily distrust is sown? Part of the issue here is purely systemic. For example, in an environment optimized for high work-in-progress, you find all kinds of seemingly untrustworthy behavior:
Note local agendas, back-channeling, more cooks, distrust, opacity, loss of morale, and cutting corners….all can be easily mapped to lapses in Empathy, Reliability, Credibility, and Apparent Self-Interest.
It goes even deeper. Many of these issues boil down to what Amy Edmonson calls professional culture clash:
The culture clash can extend to members of the same “culture” (e.g. Engineers) who find themselves divided by generations, prior work environments, opinions on individualism vs. collectivism, etc. There’s also the influence of seniority…a senior engineering leader is experiencing a different dynamic (pressures, history, etc.) from, let’s say, a new engineering hire.
It is for all these reasons that we find many software product development organizations optimized for distrust: upfront planning, prescriptive missions, individual-level goals, etc. etc. It’s a wicked, self-perpetuating problem. Many processes are uniquely designed to “hold people to account” (instead of deliver outcomes) because there is an underlying sense of lack of accountability. The only (depressing) saving grace is that systems tend to find a mediocre equilibrium instead of completely imploding.
So what does this all mean? What can you do? Optimizing for distrust is a race to the bottom. My experience is that we’re afraid to talk openly about trust and confidence (especially when trust and confidence is lacking). So attacking this issue head on can be extremely difficult. Fundamental attribution bias also leaves us biased against a less personal, systems-level explanation.
The key, I think, is to create safe situations whereby cross-functional (culture spanning) teams can 1) build empathy, credibility, and establish a collective interest, and 2) reliably keep promises to each other (and the organization). The rest of the organization, in return, has to fulfill its side of the bargain, lest this be viewed as the stereotypical “the teams must prove they can deliver FIRST and then we’ll trust THEM” problem (which reduces credibility and empathy right off the batt).
Instead of creating hand-offs to silo cultures…take the plunge to integrate them. This will be hard in the short-term, as explained by Bob Putnam, Professor of Public Policy at Harvard University, in this fascinating Freakonomics episode on Trust:
Basically…working Larry’s trust algorithm. This is why I am so passionate about Starting Together…it puts people on equal footing when confronting a problem together. With that established, teams can progressively shift to being more outcome focused as the level of collective trust increases. You will need constraints, but with time they will become more implicit and less explicit.
And PS, you’ll always have someone talk about the “real world”
Why Don’t They Trust Us?
Research & References of Why Don’t They Trust Us?|A&C Accounting And Tax Services
Source
0 Comments
Trackbacks/Pingbacks