Shipulski On Design

Archive for the ‘Culture’ Category

There’s a lot of negativity around us. But it’s not upfront, unadulterated negativity; it’s behind-the-scenes, hunkering, almost translucent negativity. And it’s divisive.

This type of negativity is so pervasive it’s almost invisible. It’s everywhere; we have processes built around it; have organizations dedicated to it; and we use it daily to drive action.

Take continuous improvement for example. It has been a standard toolset and philosophy for making things better. Yet it’s founded on negativity. It’s not anti-people, anti-culture negativity. (In fact lean and Six Sigma go on their way to emphasize positive culture as a key foundation.) It’s subtle negativity that slowly grinds. Look at the language: reduce defects, eliminate waste, corrective action, tight feedback loops, and eliminate failure modes. There is a negative tint. It’s not in your face, but it’s there.

I’m an advocate of lean and I have advocated for Six Sigma, both of which have moved the needle. But there’s a minimization thread running through them. Both are about eliminating and reducing what is. Sure they have their place, but enough is enough. We need more of creating what isn’t, and bringing to life things that aren’t. We need more maximization.

Negativity has become natural, and positivity has become an endangered species. When there’s a crisis we all come together instinctively to eliminate the bad thing. Yet it’s fourth or fifth nature to come together spontaneously when things go well. Yes, sometimes we celebrate, but it’s the exception. And it’s certainly not our first instinct. (Actually, I don’t think we have a word for spontaneous amplification of positivity. Celebration is the closest word I know, but it’s not the right one.)

Negative feedback is good for processes and positive feedback is good for people. Processes like when their flaws are eliminated, and people like when their strengths are amplified. It’s negativity for processes, and positivity for people.

There should be a rebalancing of negativity and positivity. For every graph of defect reduction over time, there should be a sister plot of the number of good things that happened over time. For every failure mode and effects analysis there should be a fishbone of chart of strengths and the associated actions to amplify them.

It’s natural for us to count bad things and make them go away, and not so natural to count good things and multiply them. Take at the meeting agendas. My bet is there’s far more minimization than maximization.

I usually end my posts with some specific call to action or recommendation. But for this one I don’t have anything all that meaty. But I will tell you how I’m going to move forward. When I see good work, I’m going to publicly acknowledge it and send emails of praise to the manager of the folks who did the good stuff. I’m going to track the number of emails I send and each week increase the number by one. I’m going to schedule regular meetings where I can publicly praise people that display passion. And I’m going to create a control chart of the number of times I amplify positivity.

And most of all I will try to keep in front of me that everything we do is all about people, and with people positivity is powerful.

I used to believe in control, now I believe in trust.

I used to believe in process, now I believe in judgment.

I used to believe in WHAT and HOW, now I believe in WHO and WHY.

I used to believe in organizational structure, now I believe in personal relationships.

I used to believe in best practices, now I believe in the judgment to choose the right practices.

I used to believe in shoring up weaknesses, now I believe in building on strengths.

I used to believe in closing the gap, now I believe in the preferential cowpath.

I used to believe in innovation, now I believe in inspiration.

I used to believe in corrective action, now I believe in passionate action.

I used to believe in top down, now I believe in the people that do the work.

I used to believe in going fast, now I believe in doing it right as the means to go fast.

I used to believe in the product development process, now I believe in the people executing it.

I used to believe the final destination, now I believe in the current location.

I used to believe in machines, now I believe in the people that run them.

I used to believe in technology, now I believe in the people developing it.

I used to believe in hierarchy, now I believe in personal responsibility.

But if there’s one thing to believe in, I believe in people.

It’s easier to spot when it’s a rut of failure – product costs too high, product function is too low, and the feeding frenzy where your competitors eat your profits for lunch. Easy, yes, but still possible to miss, especially when everyone’s super busy cranking out heaps of the same old stuff in the same old way, and demonstrating massive amounts of activity without making any real progress. It’s like treading water – lots of activity to keep your head above water, but without the realization you’re just churning in the same place.

But far more difficult to see (and far more dangerous) is the invisible rut of success, where cranking out the same old stuff in the same old way is lauded.  Simply put – there’s no visible reason to change. More strongly put, when locked in this invisible rut newness is shunned and newness makers are ostracized. In short, there’s a huge disincentive to change and immense pressure to deepen the rut.

To see the invisible run requires the help of an outsider, an experienced field guide who can interpret the telltale signs of the rut and help you see it for what it is.  For engineering, the rut looks like cranking out derivative products that reuse the tired recipes from the previous generations;  it looks like using the same old materials in the same old ways; like running the same old analyses with the same old tools; all-the-while with increasing sales and praise for improved engineering productivity.

And once your trusted engineering outsider helps you see your rut for what it is, it’s time to figure out how to pull your engineering wagon out of the deep rut of success.  And with your new plan in hand, it’s finally time to point your engineering wagon in a new direction. The good news – you’re no longer in a rut and can choose a new course heading; the bad news – you’re no longer in a rut so you must choose one.

It’s difficult to see your current success as the limiting factor to your future success, and once recognized it’s difficult to pull yourself out of your rut and set a new direction.  One bit of advice – get help from a trusted outsider.  And who can you trust?  You can trust someone who has already pulled themselves out of their invisible rut of success.

Own your ideas, not the drama.

Own your words, not the gossip.

Own your vision, not the dogma.

Own your effort, not the heckling.

Own your vacation, not the email.

Own your behavior, not the strife.

Own your talent, not the cynicism.

Own your deeds, not the rhetoric.

Own your caring, not the criticism.

Own your sincerity, not the hot air.

Own your actions, not the response.

Own your insights, not the rejection.

Own your originality, not the critique.

Own your passion, not the nay saying.

Own your loneliness, not the back story.

Own your health, not the irrational workload.

Own your thinking, not the misunderstanding.

Own your stress level, not the arbitrary due date.

Own your happiness.

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.

All business processes are powered by people. Even with all our automation and standardization, nothing moves without people. And people are powered by language. Language is important.

“Fix that so we don’t make any more mistakes.” Snarl words. “Figure out what we do well, and let’s do more of that.” Purr words. Which are more powerful?

“Wonderful work.” Purr words. “Wonderful, more customer complaints.” Snarl words. The same word is both, but it’s clear to all which is which. One is empowering, the other demotivating. Which is better for business?

Subtle usage makes a difference, intonation makes a difference, and tone makes a difference. It’s not just words that matter, but how they’re delivered also matters. Words can build or words can dismantle, and so can delivery.

We know people drive everything. And we know words influence people. Yet we don’t use words in ways that respects their gravity.

It takes care to use the right words in the right ways, and it takes thoughtfulness. But with today’s race pace, it’s tough to be well rested which makes it tough to use care and forethought. Well rested shouldn’t be a luxury and shouldn’t be scoffed at. In an instant the wrong words at the wrong time can be catastrophic. Trouble is the value of being well rested cannot be quantified on the balance sheet.

People power processes and words power people, and the right words at the right time can make all the difference. But it takes thoughtful, enlightened people to deliver them. And for that, they should be well rested.

The technical stuff is the easy part. Technical systems respond predictably, but people don’t.

There’s nothing worse than solving the wrong problem, so before you start solving you’ve better done a whole lot of defining.

There is no exact answer; engineering is all about judgment.

Organizational structure is important.  Whatever the structure, see its strengths and make them work for you.  If you try to fight it, it will eat you.

Innovation isn’t about ideas, innovation is about commercializing ideas.

Engineering analysis can win minds, but not hearts. And hearts govern minds.

The engineer’s role is not to minimize risk; it’s to understand the commercial reward and take risk accordingly.

What people believe is far more powerful than what they think.

New technology threatens status quoers, and, in turn, they block it.

There is no problem unless someone important thinks there’s one.

All technical systems are really human systems masquerading as technical systems.

If you let it, fear dominates. Be afraid and do it anyway.  But along the way, keep in mind that others are too afraid to try.

Engineering is not sane and rational; engineering is about people.

The system is big and complex and its output is outside your control. Trying to control these outputs is a depressing proposition, yet we’re routinely judged (and judge ourselves) on outputs.  I think it’s better to focus on system inputs, specifically your inputs to the system.

When the system responds with outputs different than desired, don’t get upset. It’s nothing personal. The system is just doing its job. It digests a smorgasbord of inputs from many agents just like you and does what it does. Certainly it’s alive, but it doesn’t know you. And certainly it doesn’t respond differently because you’re the one providing input. The system doesn’t take its output personally, and neither should you.

When the system’s output is not helpful, instead of feeling badly about yourself, shift your focus from system output to the input you provide it. (Remember, that’s all you have control over.) Did you do what you said you’d do? Were you generous? We’re you thoughtful? We’re you insightful? Did you give it your all or did you hold back? If you’re happy with the answers you should feel happy with yourself. Your input, your behavior, was just as it was supposed to be.  Now is a good time to fall back on the insightful grade school mantra, “You get what you get, and you don’t get upset.”

If your input was not what you wanted, then it’s time to look inside and ask yourself why. At times like these it’s easy to blame others and outside factors for our behavior. But at times like these  we must own the input, we must own the behavior. Now, owning the behavior doesn’t mean we’ll behave the same way going forward, it just means we own it. In order to improve our future inputs we’ve got to understand why we behaved as we did, and the first step to better future inputs is owning our past behavior.

Now, replace “system” with “person”, and the argument is the same. You are responsible for your input to the person, and they are responsible for their output (their response). When someone’s output is nonlinear and offensive, you’re not responsible for it, they are. Were you kind? Thoughtful? Insightful? If yes, you get what you get, and you don’t get upset. But what if you weren’t? Shouldn’t you feel responsible for their response? In a word, no. You should feel badly about your input – your behavior – and you should apologize. But their output is about them. They, like the system, responded the way they chose. If you want to be critical, be critical of your behavior. Look deeply at why you behaved as you did, and decide how you want to change it. Taking responsibility for their response gets in the way of taking responsibility for your behavior.

With complex systems, by definition it’s impossible to predict their output. (That’s why they’re called complex.) And the only way to understand them is to perturb them with your input and look for patterns in their responses. What that means is your inputs are well intended and ill informed. This is an especially challenging situation for those of us that have been conditioned (or born with the condition) to mis-take responsibility for system outputs. Taking responsibility for unpredictable system outputs is guaranteed frustration and loss of self-esteem. And it’s guaranteed to reduce the quality of your input over time.

When working with new systems in new ways, it’s especially important to take responsibility for your inputs at the expense of taking responsibility for unknowable system outputs. With innovation, we must spend a little and learn a lot. We must figure out how to perturb the system with our inputs and intelligently sift its outputs for patterns of understanding. The only way to do it is to fearlessly take responsibility for our inputs and fearless let the system take responsibility for its output.

We must courageously engineer and own our behavioral plan of attack, and modify it as we learn. And we must learn to let the system be responsible for its own behavior.

Our productivity-by-the-minute culture is killing us.

In business speed is king, and with it comes our short-sighted drag racing behavior. As we pull to the starting light our big engines shake and rumble, our pipes shoot flames, and our tires smoke. We stomp the throttle, accelerate to mach 1, kill the engine, and throw the chute. A quarter mile covered in record time, and champagne celebration.

But, because the pace was beyond sustainable, we can’t race again until the damage is repaired. Because it ran too hot the pit crew must pull the engine, because the torque was so outrageous the transmission must be swapped, and because the vibrations were so severe the frame must be checked for metal fatigue. But this is just another opportunity for more racing.

We externalize the setup, design the process for quick changeover, reduce waste, and focus on the vital few. No matter the pit crew doesn’t get sleep, or their families miss them. Engine swapped in record time, and obligatory celebration.

Sure, going fast is good. But business can’t be a series of back-to-back sprints. Plain and simple – people cannot sprint every day, all day. Business should be thought of as a marathon. A marathon run at a respectable pace, but a pace we’ve trained for, a pace we can sustain. With a torn hamstring the fastest sprinter makes no forward progress, and even the slowest marathoner is faster.

Sprint, yes, but only when it makes sense. Sprint, yes, but provide recovery time. Sprint, yes, but not if it will do personal harm.

Increasing speed is directionally correct, but our time horizon is too short. Instead of optimizing over a six second quarter mile, we should optimize for a marathon.

In our chase for speed’s euphoric high, our drug of choice is efficiency. Like speed, efficiency is good. But, just as speed’s time horizon is too short, efficiency’s scale of optimization is too small. We optimize locally and the net result is global sub-optimization. This is clearly an artifact of what we measure. Clearly, we must measure differently.

Every day we chase the dopamine high of efficiency, but ignore the mind-blowing power of effectiveness. If you sprint day after day, you may be efficient, but you’re definitely ineffective. Sprint every day for a month, sleep four hours a night, and spend six weeks away from your family. Are you really in a good position to make a make-or-break decision? How can you possibly be effective? I wish Finance knew how to measure effectiveness as well as it does efficiency.

As a company leader, stop sprinting. As a company leader, stop optimizing locally. As a company leader, stop focusing on efficiency. As a company leader, demonstrate and reward effectiveness. As a company leader, go home and spend time with your family.

We all want more innovation, though sometimes we’re not sure why. Turns out, the why important.

We want to be more innovative. That’s a good vision statement, but it’s not actionable. There are lots of ways to be innovative, and it’s vitally important to figure out the best flavor. Why do you want to be more innovative?

We want to be more innovative to grow sales. Okay, that’s a step closer, but not actionable. There are many ways to grow sales. For example, the best and fastest way to sell more units is to reduce the price by half. Is that what you want? Why do you want to grow sales?

We want to be more innovative to grow sales so we can grow profits. Closer than ever, but we’ve got to dig in and create a plan.

First, let’s begin with the end in mind. We’ve got to decide how we’ll judge success. How much do we want to grow profits? Double, you say? Good – that’s clear and measurable. I like it. When will we double profits? In four years, you say? Another good answer – clear and measureable. How much money can we spend to hit the goal? $5 million over four years. And does that incremental spending count against the profit target? Yes, year five must double this year’s profits plus $5 million.

Now that we know the what, let’s put together the how. Let’s start with geography. Will we focus on increasing profits in our existing first world markets? Will we build out our fledgling developing markets? Will we create new third world markets? Each market has different tastes, cultures, languages, infrastructure requirements, and ability to pay. And because of this, each requires markedly different innovations, skill sets, and working relationships. This decision must be made now if we’re to put together the right innovation team and organizational structure.

Now that we’ve decided on geography, will we do product innovation or business model innovation? If we do product innovation, do we want to extend existing product lines, supplement them with new product lines, or replace them altogether with new ones? Based on our geography decision, do we want to improve existing functionality, create new functionality, or reduce cost by 80% of while retaining 80% of existing functionality?

If we want to do business model innovation, that’s big medicine. It will require we throw away some of the stuff that has made us successful. And it will touch almost everyone. If we’re going to take that on, the CEO must take a heavy hand.

For simplicity, I described a straightforward, linear process where the whys are clearly defined and measurable and there’s sequential flow into a step-wise process to define the how. But it practice, there’s nothing simple or linear about the process. At best there’s overwhelming ambiguity around why, what, and when, and at worst, there’s visceral disagreement. And worse, with 0% clarity and an absent definition of success, there are several passionate factions with fully built-out plans that they know will work.

In truth, figuring out what innovation means and making it happen is a clustered-jumbled path where whats inform whys, whys transfigure hows, which, in turn, boomerang back to morph the whats. It’s circular, recursive, and difficult.

Innovation creates things that are novel, useful, and successful.  Novel means different, different means change, and change is scary. Useful is contextual – useful to whom and how will they use it? – and requires judgment. (Innovations don’t yet exist, so innovation efforts must move forward on predicted usefulness.) And successful is toughest of all because on top of predicted usefulness sit many other facets of newness that must come together in a predicted way, all of which can be verified only after the fact.

Innovation is a different animal altogether, almost like it eats itself. Just think – the most successful innovations come at the expense of what’s been successful.

We’ve been sufficiently polluted by lean and Six Sigma, and it’s time for them to go.

Masquerading as maximizers, these minimizers-in-sheep’s-clothing have done deep harm. Though Six Sigma is almost dead (it’s been irrelevant for some time now), it has made a lasting mark. Billed as a profit maximizer, it categorically rejects maximization. In truth, it’s a variation minimizer and difference reducer.  If it deviates, Six Sigma cuts its head off. Certainly this has a place in process control, but not in thinking control. But that’s exactly what’s happened. Six Sigma minimization has slithered off the manufacturing floor and created a culture of convergence. If your thinking is different, Six Sigma will clip it for you.

Lean is worse. All the buzz around lean is about maximizing throughput, but it doesn’t do that. It minimizes waste. But far worse is lean’s standard work. Minimize the difference among peoples’ work; make them do it the same; make the factory the same, regardless of the continent. All good on the factory floor, but lean’s minimization mania has spread like the plague and created a culture of convergence in its wake. And that’s the problem – lean’s minimization-standardization mantra has created a culture of convergence. If your thinking doesn’t fit in, lean will stomp it into place.

We need maximization at the expense of minimization, and divergence before convergence. We need creativity and innovation. But with Six Sigmaphiles and lean zealots running the show, maximization is little understood and divergence is a swear.

First we must educate on maximization. Maximization creates something that had not existed, while minimization reduces what is. Where Six Sigma minimization converges on the known right answer, creativity and innovation diverge to define a new question. The acid test: if you’re improving something you’re minimizing; if you’re inventing something you’re maximizing.

Like with He Who Shall Not Be Named, it’s not safe to say “diverge” out loud, because if you do, the lean Dementors will be called to suck out your soul. But, don’t despair – the talisman of guided divergence can save you.

With guided divergence, a team is given a creatively constructed set of constraints and very little time (hours) to come up with divergent ideas. The constraints guide the creativity (on target), and the tight timeline limits the risk – a small resource commitment. (Though counterintuitive, the tight timeline also creates remarkable innovation productivity.) Done in sets, several guided divergence sessions can cover a lot of ground in little time.

And the focused/constrained nature of guided divergence appeals to our minimization bias, and makes it okay to try a little divergence. We feel safe because we’re deviating only a little and only for a short time.

Lean and Six Sigma have served us well, and they still have their place. (Except for Six Sigma.) But they must be barred from creativity sessions and front end innovation, because here, divergence carries the day.