Shipulski On Design

Posts Tagged ‘Engineering Mindset’

Things aren’t impossible on their own, our thinking makes them so.

Impossible is not about the thing itself, it’s a statement about our state of mind.

When we say impossible, we really say we lack confidence to try.

When we say impossible, we really say we are too afraid to try.

The mission of impossible is to shut down all possibility of possibility.

To soften it, we say almost impossible, but it’s the same thing.

When we say impossible, we make a big judgment – but not about the thing – about ourselves.

Whether it’s a top-down initiative or a bottom-up revolution, your choice will make or break it.

When you have the inspiration for a bottom-up revolution, you must be brave enough to engage your curiosity without self-dismissing. You’ll feel the automatic urge to self-reject – that will never work, too crazy, too silly, too loony – but you must resist. (Automatic self-rejection is the embodiment of your fear of failure.) At all costs you must preserve the possibility you’ll try the loony idea; you must preserve the opportunity to learn from failure; you must suspend judgment.

Now it’s time to tell someone your new thinking. Summon the next level of courage, and choose wisely. Choose someone knowledgeable and who will be comfortable when you slather them with the ambiguity. (No ambiguity, no new thinking.) But most importantly, choose someone who will suspend judgment.

You now have critical mass – you, your partner in crime, and your bias for action. Together you must prevent the new thinking from dying on the vine. Tell no one else, and try it. Try it at a small scale, try it in your garage. Fail-learn-fail until you have something with legs. Don’t ask. Suspend judgment, and do.

And what of top down initiatives? They start with bottom-up new thinking, so the message is the same: suspend judgment, engage your bias for action, and try it. This is the precursor to the thousand independent choices that self-coordinate into a top-down initiative.

New thinking is a choice, and turning it into action is another. But this is your mission, if you choose to accept it.

I will be holding a half-day Workshop on Systematic DFMA Deployment on June 13 in RI. (See bottom of linked page.)  I look forward to meeting you in person.

As an engineering leader you have the biggest profit lever in the company. You lead the engineering teams, and the engineering teams design the products. You can shape their work, you can help them raise their game, and you can help them change their thinking. But if you don’t win their hearts and minds, you have nothing.

Engineers must see your intentions are good, you must say what you do and do what you say, and you must be in it for the long haul. And over time, as they trust, the profit lever grows into effectiveness. But if you don’t earn their trust, you have nothing.

But even with trust, you must be light on the tiller. Engineers don’t like change (we’re risk reducing beings), but change is a must. But go too quickly, and you’ll go too slowly. You must balance praise of success with praise of new thinking and create a standing-on-the-shoulders-of-giants mindset. But this is a challenge because they are the giants – you’re asking them to stand on their own shoulders.

How do you know they’re ready for new thinking? They’re ready when they’re willing to obsolete their best work and to change their work to make it happen. Strangely, they don’t need to believe it’s possible – they only need to believe in you.

Now the tough part: There’s a lot of new thinking out there. Which to choose?

Whatever the new thinking, it must make sense at a visceral level, and it must be simple. (But not simplistic.) Don’t worry if you don’t yet have your new thinking; it will come. As a seed, here are my top three new thinkings:

Define the problem. This one cuts across everything we do, yet most underwhelm it. To get there, ask your engineers to define their problems on one page. (Not five, one.) Ask them to use sketches, cartoons, block diagram, arrows, and simple nouns and verbs.  When they explain the problem on one page, they understand the problem. When they need two, they don’t.

Test to failure. This one’s subtle but powerful. Test to define product limits, and don’t stop until it breaks. No failure, no learning. To get there, resurrect the venerable test-break-fix cycle and do it until you run out of time (product launch.) Break the old product, test-break-fix the new product until it’s better.

Simplify the product. This is where the money is. Product complexity drives organizational complexity – simplify the product and simply everything. To get there, set a goal for 50% part count reduction, train on Design for Assembly (DFA), and ask engineering for part count data at every design review.

I challenge you to challenge yourself: I challenge you to define new thinking; I challenge you to help them with it; I challenge you to win their hearts and minds.

Rumor has it, manufacturing is back. Yes, manufacturing jobs are coming back, but they’re coming back in dribbles. (They left in a geyser, so we still have much to do.) What we need is a fire hose of new manufacturing jobs.

Manufacturing jobs are trickling back from low cost countries because companies now realize the promised labor savings are not there and neither is product quality. But a trickle isn’t good enough; we need to turn the tide; we need the Mississippi river.

For flow like that we need a fundamental change. We need labor costs so low our focus becomes good quality; labor costs so low our focus becomes speed to market; labor costs so low our focus becomes speed to customer. But the secret is not labor rate. In fact, the secret isn’t even in the factory.

The secret is a secret because we’ve mistakenly mapped manufacturing solely to making (to factories). We’ve forgotten manufacturing is about designing and making. And that’s the secret: designing – adding product thinking to the mix. Design out the labor.

There are many names for designing and making done together. Most commonly it’s called concurrent engineering. Though seemingly innocuous, taken together, those words have over a thousand meanings layered with even more nuances. (Ask someone for a simple description of concurrent engineering. You’ll see.) It’s time to take a step back and demystify designing and making done together. We can do this with two simple questions:

• What behavior do we want?
• How do we get it?

What’s the behavior we want? We want design engineers to understand what drives cost in the factory (and suppliers’ factories) and design out cost. In short, we want to connect the engineer to the factory.

Great idea. But what if the factory and engineer are separated by geography? How do we get the behavior we want? We need to create a stand-in for the factory, a factory surrogate, and connect the engineer to the surrogate. And that surrogate is cost. (Cost is realized in the factory.) We get the desired behavior when we connect the engineer to cost.

When we make engineering responsible for cost (connect them to cost), they must figure out where the cost is so they can design it out. And when they figure out where the cost is, they’re effectively connected to the factory.

But the engineers don’t need to understand the whole factory (or supply chain), they only need to understand places that create cost (where the cost is.) To understand where cost is, they must look to the baseline product – the one you’re making today. To help them understand supply chain costs, ask for a Pareto chart of cost by part number for purchased parts. (The engineers will use cost to connect to suppliers’ factories.) The new design will focus on the big bars on the left of the Pareto – where the supply chain cost is.

To help them understand your factory’s cost, they must make two more Paretos. The first one is a Pareto of part count by major subassembly. Factory costs are high where the parts are – time to put them together. The second is a Pareto chart of process times. Factory costs are high where the time is – machine capacity, machine operators, and floor space.

To make it stick, use design reviews. At the first design review – where their design approach is defined – ask engineering for the three Paretos for the baseline product. Use the Pareto data to set a cost reduction goal of 50% (It will be easily achieved, but not easily believed.) and part count reduction goal of 50%. (Easily achieved.) Here’s a hint for the design review – their design approach should be strongly shaped by the Paretos.

Going forward, at every design review, ask engineering to present the three Paretos (for the new design) and cost and part count data (for the new design.) Engineering must present the data themselves; otherwise they’ll disconnect themselves from the factory.

To seal the deal, just before full production, engineering should present the go-to-production Paretos, cost, and part count data.

What I’ve described may not be concurrent engineering, but it’s the most profitable activity you’ll ever do. And, as a nice side benefit, you’ll help turn around the economy one company at a time.

Design for Manufacturing (DFM) is all about reducing the cost of piece-parts. Design for Assembly is all about reducing the cost of putting things together (assembly).  What’s often forgotten is that function comes first.  Change the design to reduce part cost, but make sure the product functions well.  Change the parts (eliminate them) to reduce assembly cost, but make sure the product functions well.

Paradoxically, DFM and DFA are all about function.

Here’s a link to a short video that explains DFM and DFA: link to video. (and embedded below)

Our organizations are set up in silos, and we’re measured that way. (And we wonder why we get local optimization.) At the top of engineering is the VP of the Red Team, who is judged on what it does – product.  At the top of manufacturing is the VP of the Blue Team, who is judged on how to make it – process. Red is optimized within Red and same for Blue, sometimes with competing metrics.  What we need is Purple behavior.

Here’s a link to a short video (1:14): Organizationally Challenged

And embedded below:

Let me know what you think.

Design is typically limited to function – what it does – and is done by engineering (red team).  Manufacturing is all about how to make it and is done by manufacturing (blue team).  Working separately there is local optimization.  We must broad to design to include both – red and blue. Working across red-blue boundaries creates magic.  This magic can only be done by the purple team.

Below is my first video post.  I hope to do more.  Let me know what you think.

I think we underestimate the power of now, and I think we waste too much emotional energy on the past and future.

We use the past to create self-inflicted paralysis, to rationalize inaction. We dissect our failures to avoid future missteps, and push progress into the future. We make no progress in the now. This is wrong on so many levels.

In all written history there has never been a mistake-free endeavor. Never. Failure is part of it. Always. And learning from past failures is limited because the situation is different now: the players are different, the technology is different, the market is different, and the problems are different. We will make new mistakes, unpredictable mistakes. Grounding ourselves in the past can only prepare us for the previous war, not the next one.

Like with the past, we use the future’s uncertainty to rationalize inaction, and push action into the future. The future has not happened yet so by definition it’s uncertain. Get used to it. Embrace it. I’m all for planning, but I’m a bigger fan of doing, even at the expense of being wrong. Our first course heading is wrong, but that doesn’t mean the ship doesn’t sail. The ship sales and we routinely checks the heading, regularly consults the maps, and constantly monitors the weather. Living in the now, it’s always the opportunity for a course change, a decision, or an action.

The past is built on old thinking, and it’s unchangeable – let it go. Spend more emotional energy on the now. The future is unpredictable an uncontrollable, and it’s a result of decisions made in the now – let it go. Spend more energy on the now.

It’s tough to appreciate the power of now, and maybe tougher to describe, but I’ll take a crack at it. When we appreciate the power of now we have a bias for action; we let go of the past; we speculate on the future and make decisions with less than perfect information; and we constantly evaluate our course heading.

Give it a try. Now.

When asked how to improve manufacturing, the recipe is clear: lean.  When asked how to improve engineering, the recipe: there isn’t one.  Each engineering improvement effort is unique; though there are common themes and building blocks, each has its own fingerprint.

Each company has its own strengths, weaknesses, opportunities and threats; each company has unique products and markets; each its own goals; each its own culture; each its own future state. Informed by uniqueness, the recipe is unique. To create your unique improvement recipe, I suggest WHY, WHAT, HOW.

WHY
Before your engineering improvement recipe can be formed, the fundamental shaping question must be answered.  Take a breath, fire up your laptop, put on your headphones, and queue up your best music. Type this question:

WHY does our business demand we improve engineering?

Now, type the answer. (Literally.) Use nouns and verbs to explain why engineering must improve. If you can’t, stop. Without a clear, concise, jargon-free answer nothing can be done to advance the cause.  (Though there can be plenty of activity, there can be no progress.) Without the WHY, you cannot pass GO.  You must create a clear, concise WHY.

Seek out help from trustworthy people to create the WHY. Don’t move forward until you understand it well enough to explain it to the engineering organization.  Now, with WHY in place, it’s time for WHAT.

WHAT
Informed by WHY, it’s time for WHAT. Secure a quiet spot, scare up a big piece of paper, and grab your favorite pen. On the top of the page, write this question:

WHAT does engineering improvement look like?

Now, draw the picture. (Literally.) Use sketches, scribbles, arrows, blocks, and people’s names to describe what improved engineering looks like.  Sit in the future and describe it in present tense.  Once drawn, review it with folks you trust, revise it, and repeat.  If you cannot draw the future, keep trying.  Once you have something, review it with folks you trust, revise it, and repeat. Don’t move forward until you draw it clearly enough to explain it to the engineering organization. And with WHAT in place, it’s time for HOW.

HOW
The first step of HOW is similar to WHAT. Pick up your favorite pen, come back to the now, and draw a picture of today’s engineering capabilities, engineering’s current state.  Again, use scribbles, blocks, arrows, and names.

The second step is to define the difference between future and current states.  With future and current state pictures side-by-side, perform a mathematical subtraction: future state – current state.  The difference is HOW. A block in future state that’s not part of the current state is a new thing that must be created; a new arrow in the future state is an activity, interaction, or relationship that must be created; a new person, named or unnamed, represents new thinking. Things that appear in both states are strengths to build on.

The third step, prioritization.  Start here:

What engineering strengths will we build on?

It’s important start with strengths. It sends the right message to the engineering organization: we must build on build on what works, build on what got us here. Engineers need to know that, fundamentally, their work is good, and major building blocks are in place, the foundation is solid.

What development areas will we improve?

Take care with this one.  To avoid a demoralized engineering team, there should be fewer development areas than strengths.  Though there may be many development areas, call out only the most important.

What’s the right first bite?

The most important improvements are those that strongly support the WHY; there’s a natural sequence of things (socks before shoes) that must be respected;  and there’s a finite amount of work that can be done.  Use these three lenses as the start of a prioritization framework.

Building blocks for engineering improvement are the same for all companies: people, tools, and processes, but there are many types of people, countless engineering tools, and all processes can be improved. WHY, WHAT, HOW can help define your unique improvement fingerprint: the right people, the right tools, the right processes, shaped by your unique company goals, and improved in right sequence.

Creating new products that provide a useful function is hard, and insuring they function day-in and day-out is harder.  Plain and simple, engineering is hard.

Planes must fly, cars must steer, and Velcro must stick. But, at every turn, there are risks, reasons why a new design won’t work, and it’s the engineer’s job to make the design insensitive to these risks. (Called reducing signal to noise ratio in some circles.) At a fundamental level engineering is about safety, and at a higher level it’s about sales – no function, no sales.

That’s why at every opportunity engineers reduce risk . (And thank goodness we do.) It makes sense that we’re the ones that think things through to the smallest detail, that can’t move on until we have the answer, that ask odd questions that seem irrelevant. It all makes sense since we’re the ones responsible if the risks become reality. We’re the ones that bear ultimate responsibility for product function and safety, and, thankfully, it shapes us.

But there’s a dark side to this risk reduction mindset – where we block our thinking, where we don’t try something new because  of problems we think we may have, problems we don’t have yet. The cause of this innovation-limiting behavior: problem broadening, where we apply a thick layer of problem over the entirety of a new concept, and declare it unworkable. Truth is, we don’t understand things well enough to make that declaration, but, in a knee-jerk way, we misapply our natural risk reduction mindset. Clearly, problems exist when doing new, but real problems are not broad, real problems are not like peanut butter and jelly spread evenly across the whole sandwich. Real problems are narrow; real problems are localized, like getting a drip of jelly on your new shirt.

How to get the best of both worlds? How to embrace the risk reduction mindset so products are safe and help engineering folks to try something radically new? To innovate?

We’ve got the risk reduction world covered, so it’s all about enhancing the try-something-new side. To do this we need to combat problem broadening; we need a process for problem narrowing. With problem narrowing, engineers drill down until the problem is defined as the interaction of two elements (the jelly and your shirt), defined in space (the front of your shirt) and time (when the knife drops a dollop on your shirt). Where problem broadening tells us to avoid making peanut butter and jelly sandwiches altogether (those sandwiches will always dirty our shirts), problem narrowing tells use to put something between the knife and the front of your shirt, or to put on your new shirt after you make your sandwich, or to do something creative to keep the jelly away from our shirt.

Problems narrow as knowledge deepens. Work through your fears, try something new, and advance your knowledge. Then define your problems narrowly, and solve them.

Innovate.

We all want to increase profits, but sometimes we get caught in the details and miss the big picture:

Profit = (Price – Cost) x Volume.

It’s a simple formula, but it provides a framework to focus on fundamentals. While all parts of the organization contribute to profit in their own way, engineering’s work has a surprisingly broad impact on the equation.

The market sets price, but engineering creates function, and improved function increases the price the market will pay. Design the product to do more, and do it better, and customers will pay more. What’s missing for engineering is an objective measure of what is good to the customer.

To read the complete article, click this link.