Trust Isn't An Option... It's The Only Option!

I was reading an article on the woes of "The Detroit Three" (automakers) this afternoon, and came across this fascinating bit about the New United Motor Manufacturing Inc (NUMMI) plant that was a joint venture between GM and Toyota, starting in 1984:

"The plant had [previously] been one of GM's worst; the Toyota system made it one of GM's best.

Detroiters made the pilgrimage... en masse to see the miracle of NUMMI. Some dismissed what should have become a model for the entire industry. True, the technology wasn't that innovative. But Toyota made the workforce integral to improving the system. Workers were not mere labor inputs. GM had no problem understanding the just-in-time inventory system Toyota used, but executing it required a buy-in from the shop floor so that everyone was dedicated to improvement. The Toyota system, says John MacDuffie, a manufacturing expert at Pennsylvania's Wharton School of Business, 'relies on contributions from employees. It feels vulnerable, but your willingness to be open to that vulnerability is what helps you make it work.' In the 1980s and part of the 90s, the top-down culture of the Big Three could not absorb that kind of deep trust."
- Bill Saporito, "Is This Detroit's Last Winter?", Time magazine, Dec 15/08

Those who've read the 2nd AgileMan book, especially Issue # 46, Who Do You Trust?, will perhaps recognize that the preceding description bears at least some similarity to what I observed in my role as Agile Manager. Lean manufacturing (as Toyota created and mastered), like Agile software development, requires that a greater degree of trust be extended to the "rank and file" than many traditional management types are ready, willing or able to accomplish. It sounds like the Big Three suffered from that, and I certainly saw lots of evidence of the same issue in the workplace over the last several years.

So just how can you place trust in the employee base and be comfortable in doing so? Well, we didn't pull it off all that successfully, but I still believe I learned a thing or two along the way. Here's what I think it takes on the part of those in charge:

1. Clearly communicate what's expected of those you're entrusting. In our software environment, that means telling everyone "the what" and empowering them to come up with "the how". I personally think it's unreasonable (and doomed to failure) to dictate both "the what" and the "by when", but others may disagree with that.
   
2. Establish how the results will be measured, make them well known, and then follow through on what you established. Metrics are tricky business (as I wrote about in the 1st AgileMan book), but just because they're hard to do right doesn't mean that you get off the hook for producing them! The temptation to shift around the measurements as time goes by is often very strong, but also completely unfair to the people whose hard work is being evaluated. The onus is ultimately on management to set the yardsticks and then to live by them. Failure to do so causes the staff to believe that you're changing the rules as you go... because you are!
   
3. Treat the inevitable failures that will occur as opportunities for learning. This is another tough pill to swallow, because those who live by the Blame Game rules (and who have long since mastered "Cover Your Ass" as an integral skillset) will find it difficult to re-wire their brains to this new way of thinking. Finger-pointing and general CYA attitudes, however, do more to erode trust than just about anything else you can throw into the mix.
4. Celebrate successes, large and small. This was perhaps the biggest disappointment for me in my previous job: the focus always seemed to be on what had gone wrong, rather than on what had gone right. If one Feature Team did really well, management would only want to talk about the ones who were still struggling. If a team got their bug count significantly reduced, the focus would go on to how "late" their new features were. Despite providing hundreds of features in our first 2 years of Agile, I repeatedly heard executives say, "We haven't delivered a single thing since we started Agile!" That sort of skewed perspective is certainly not a good way to build trust between the layers of the company!

If you can pull those four areas off, you'll probably do very well in creating an empowered, high-performing environment in which everyone will succeed. If, on the other hand, you regard trust as an optional add-on, like power windows or leather seats, then you'll probably be sorely disappointed in the results you get each time you "cheap-out" in that regard.