Shipulski On Design

We 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”