Build A Legacy Of Trust

circle of trustWe set visions, define idealized future states, define metrics, and create tools and processes to realize them. It’s all knit together, the puzzle pieces fight tightly, and it leaves out the most important part – people and their behavior.

Metrics represent the all-important output of our tools and processes, and we’re so fascinated by metrics because customers pay for outputs they stand for. The output of the product development process is the recipe for the product, and the output of the manufacturing process is product itself. We’re muscle bound with metrics because these outputs are vitally important to profitability. Here’s a rule: the processes and tools we deem most important have the most metrics.

Metrics measure outputs, and managing with output metrics is like driving a car while looking in the rear view mirror. But that’s what we do. But what about managing the inputs?

The inputs to tools are people and their behaviors. People use tools, and how they use them – their behavior – governs the goodness of the output. Sometimes we behave otherwise, but how people use the tools (the inputs) is more important than the tools. But don’t confuse the sequence of steps with behaviors.

All the steps can be intricately defined without capturing the desired behavior. 1.) Load the solid model – see Appendix C. 2.) Set up the boundary conditions using the complicated flow chart in Appendix D. 3.) Run the analysis. 4.) Interpret the results. (Which is far too complicated to capture even in the most complicated appendix.) But the steps don’t define the desired behavior. What’s the desired behavior if the flowchart doesn’t come up with boundary conditions that are appropriate? What’s the behavior to decide if they’re inappropriate? What’s the behavior if you’re not sure the results are valid? What’s the behavior to decide if an analysis is needed at all?

The desired behaviors could go something like this: If the boundary conditions don’t make sense, trust your judgment and figure out why it doesn’t make sense. Don’t spend all day, but use good judgment on how long to spend. If you’re still not sure, go ask someone you trust. Oh, and if you think an analysis isn’t needed, trust your judgment and don’t do one.

And it’s the same for processes – a sequence of steps, even the most complete definition, doesn’t capture the desired behavior when judgment is required.

To foster the desired behavior, people must feel they can be trusted – trusted to use their best judgment. But for people to feel trusted, they have to be trusted. And not trusted once, or once in a while, consistently trusted over time.

Computers and their software tools quickly predictably crank through millions of ultra-defined process steps. But when their processes require judgment, even their hyper-speed can’t save them. When things don’t fit, when it hasn’t been done before, when previous success no longer applies, it’s people and their judgment that must carry the day.

Everyone has the same computers and the same software tools – there’s little differentiation there. People are the big differentiators. And there’s a huge competitive advantage for those companies that create the culture where their people error on the side of exercising their judgment. And for that, you have to build a legacy of trust.

3 Responses to “Build A Legacy Of Trust”

  • Mike
    Incredibly on point. Thank you for the clear message that so many managers are missing.
    I have been managing my engineering teams with this culture for years and some people wonder why they are a high performance, tightly knit group. It is so simple to understand.

  • Mike,
    Love the post!!!! Nailed it. We are the vital link to make tools and processes work and we’re also our worst enemy.

  • Mike,

    Very meaningful post! We constantly hear to verify and validate the design results. Does the data make sense? Do the results make sense? Were these the right requirements? Did we actually solve the problem from the customer’s perspective? Engineers will not provide breakthrough insights rather than stick with safe accepted dogma unless they are truly trusted. Execution my seem to be all about tools, processes, and metrics, but it is really driven by the behavior of all participants. It was a really great design, all the analysis and test results were right on target. But delivery costs far exceeded expectations, it never became profitable, and customers became disillusioned and lost trust in the brand. Did an engineer see this in the design results, but was afraid of the consequences of presenting why there will be problems building this product??? If there was a culture of trust, would there consistently be a better bottom line.

Leave a Reply

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner