Shipulski On Design

Archive for the ‘Fear’ Category

Doing new things doesn’t take a long time. What takes a long time is seeing things as they are. Getting ready takes time, not doing new. Awareness of assumptions, your assumptions, others’ assumptions, the company’s – that’s critical path.

An existing design, product, service, or process looks as it does because of assumptions made during long ago for reasons no longer relevant (if they ever were). Design elements blindly carried forward, design approaches deemed gospel, scripted service policies that no longer make sense, awkward process steps proceduralized and rev controlled – all artifacts of old, unchallenged assumptions. And as they grow roots, assumptions blossom into constraints. Fertile design space blocked, new technologies squelched, new approaches laughed out of town – all in the name of constraints founded on wilted assumptions. And the most successful assumptions have the deepest roots and create the deepest grooves of behavior.

Cows do the same thing every day. They wake up at the same time (regardless of daylight savings), get milked at the same time, and walk the same path.  They walk in such a repeatable way, they make cowpaths – neat grooves walked into the landscape – curiously curved paths with pre-made decisions. No cow worth her salt walks outside the  cowpath. No need. Cows like to save their energy for making milk at the expense of making decisions. If it was the right path yesterday, it’s right today.

But how to tell when old assumptions limit more than they guide? How to tell when it’s time to step out of the groove? How to tell a perfectly good cowpath from one that leads to a dry watering hole? When is it time to step back and create new history? Long ago the first cow had to make a choice, and she did. She could have gone any which way, and she did. She made the path we follow today.

With blind acceptance of assumptions, we wither into bankruptcy, and with constant second-guessing we stall progress. We must strike a balance. We must hold healthy respect for what has worked and healthy disrespect for the status-quo. We must use forked-tongue thinking to pull from both ends. In a yin-yang way, we must acknowledge how we got here, and push for new thinking to create the future.

Although it’s more important than ever, trust is in short supply. With everyone doing three jobs, there’s really no time for anything but a trust-based approach. Yet we’re blocked by the fear that trust means loss of control.  But that’s backward.

Trust is a funny thing.  If you have it, you don’t need it.  If you don’t have it, you need it. If you have it, it’s clear what to do – just behave like you should be trusted. If you don’t have it, it’s less clear what to do. But you should do the same thing – behave like you should be trusted.  Either way, whether you have it or not, behave like you should be trusted.

Trust is only given after you’ve behaved like you should be trusted. It’s paid in arrears. And people that should be trusted make choices.  Whether it’s an approach, a methodology, a technology, or a design, they choose.  People that should be trusted make decisions with incomplete data and have a bias for action.  They figure out the right thing to do, then do it.  Then they present results – in arrears.

I can’t choose – I don’t have permission. To that I say you’ve chosen not to choose. Of course you don’t have permission.  Like trust, it’s paid in arrears.  You don’t get permission until you demonstrate you don’t need it.  If you had permission, the work would not be worth your time. You should do the work you should have permission to do.  No permission is the same as no trust.  Restating, I can’t choose – I don’t have trust. To that I say you’ve chosen not to choose.

There’s a misperception that minimizing trust minimizes risk. With our control mechanisms we try to design out reliance on trust – standardized templates, standardized process, consensus-based decision making. But it always comes down to trust.  In the end, the subject matter experts decide. They decide how to fill out the templates, decided how to follow the process, and decide how consensus decisions are made. The subject matter experts choose the technical approach, the topology, the materials and geometries, and the design details. Maybe not the what, but they certainly choose the how.

Instead of trying to control, it’s more effective to trust up front – to acknowledge and behave like trust is always part of the equation.  With trust there is less bureaucracy, less overhead, more productivity, better work, and even magic.  With trust there is a personal connection to the work.  With trust there is engagement.  And with trust there is more control.

But it’s not really control.  When subject matter experts are trusted, they seek input from project leaders.  They know their input has value so they ask for context and make decisions that fit.  Instead of a herd of cats, they’re a swarm of bees. Paradoxically, with a trust-based approach you amplify the good parts of control without the control parts.  It’s better than control. It’s where ideas, thoughts and feelings are shared openly and respectfully; it’s where there’s learning through disagreement; it’s where the best business decisions are made; it’s where trust is the foundation.  It’s a trust-based approach.

The No. 1 reason initiatives are successful is support from top management. Whether it’s lean, Six Sigma, Design for Six Sigma or any program, top management support is vital. No argument. It’s easy with full support, but there’s never enough to go around.

But that’s the way it should be. Top management has a lot going on, much of it we don’t see: legal matters, business relationships, press conferences, the company’s future. If all programs had top management support, they would fail due to resource cannibalization. And we’d have real fodder for our favorite complaint—too many managers.

When there’s insufficient top management support, we have a choice. We can look outside and play the blame game. “This company doesn’t do anything right.” Or we can look inside and choose how we’ll do our work. It’s easy to look outside, then fabricate excuses to do nothing. It’s difficult to look inside, then create the future, especially when we’re drowning in the now. Layer on a new initiative, and frustration is natural. But it’s a choice.

We will always have more work than time….

Link to complete article

The new product development process creates more value than any other process. And because of this it’s a logical target for improvement.  But it’s also the most complicated business process.  No other process cuts across an organization like new product development. Improvement is difficult.

The CEO throws out the challenge – “Fix new product development.” Great idea, but not actionable. Can’t put a plan together.  Don’t know the problem.  Stepping back, who will lead the charge? Whose problem is it?

The goal of all projects is to solve problems.  And it’s no different when fixing product development – work is informed by problems. No problem, no fix. Sure you can put together one hell of a big improvement project, but there’s no value without the right problem. There’s nothing worse than spending lots of time on the wrong problem.  And it’s doubly bad with product development because while fixing the wrong problem engineers are not working on the new products.  Yikes.

Problems are informed by outcomes.  Make a short list of desired outcomes and show the CEO.  Your list won’t be right, but it will facilitate a meaningful discussion.  Listen to the input, go back and refine the list, and meet again with the CEO.  There will be immense pressure to start the improvement work, but resist.  Any improvement work done now will be wrong and will create momentum in the wrong direction.  Don’t move until outcomes are defined.

With outcomes in hand, get the band back together. You know who they are.  You’ve worked with them over the years. They’re influential and seasoned.  You trust them and so does the organization.  In an off-site location show them the outcomes and ask them for the problems. (To get their best thinking spend money on great food and a relaxing environment.)  If they’re the right folks, they’ll say they don’t know.  Then, they’ll craft the work to figure it out – to collect and analyze the data.  (The first part of problem definition is problem definition.) There will be immense pressure to start the improvement work, but resist.  Any work done now will be wrong.  Don’t move until problems are defined.

With outcomes and problems in hand, meet with the CEO.  Listen.  If outcomes change, get the band back together and repeat the previous paragraph. Then set up another meeting with the CEO.  Review outcomes and problems.  Listen.  If there’s agreement, it’s time to put a plan together.  If there’s disagreement, stop.  Don’t move until there’s agreement.  This is where it gets sticky.  It’s a battle to balance everyone’s thoughts and feelings, but that’s your challenge.  No words of wisdom on than – don’t move until outcomes and problems are defined.

There’s a lot of emotion around the product development process.  We argue about the right way to fix it – the right tools, training, and philosophies. But there’s no place for argument.  Analyze your process and define outcomes and problems.  The result will be a well informed improvement plan and alignment across the company.

We live in a strange time where activity equals progress and thinking does not. Thinking is considered inactivity – wasteful, non-productive, worse than sleeping. (At least napping at your desk recharges the battery.) In today’s world there is little tolerance for thinking.

For those that think regularly – or have thought once or twice over the last year – we know thinking is important. If we stop and think, everyone thinks thinking is important. It’s just that we’re too busy to stop and think.

It’s difficult to quantify how bad things are – especially if we’re to compare across industries and continents. Sure it’s easy (and demoralizing) to count the hours spent in meetings or the time spent wasting time with email. But they don’t fully capture a company’s intolerance to thinking. We need a tolerance metric and standardized protocol to measure it.

I’ve invented the Thinking Tolerance Metric, TTM, and a way to measure it. Here’s the protocol: On Monday morning – at your regular start time – find a quiet spot and think. (Your quiet spot can be home, work, a coffee shop, or outside.) No smart phone, no wireless, no meetings. Don’t talk to anyone. Start the clock and start thinking. Think all day.

The clock stops when you receive an email from your boss stating that someone complained about your lack of activity. At the end of the first day, turn on your email and look for the complaint. If it’s there, use the time stamp to calculate TTM using Formula 1:

a

TTM = Time stamp of first complaint – regular start time.  [1]

a

If TTM is measured in seconds or minutes, that’s bad. If it’s an hour or two, that’s normal.

If there is no complaint for the entire day, repeat the protocol on day two. Go back to your quiet spot and think. At the end of day two, check for the complaint. Repeat until you get one. Calculate TTM using Formula 1.

Once calculated, send me your data by including it in a comment to this post. I will compile the data and publish it in a follow-on post. (Please remember to include your industry and continent.)

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.

Situation A

• The economy has picked up, but your sales have dropped off.
• Competitors’ products work better than yours.
• Competitors’ product launches are more frequent than yours.
• The number of competitors is increasing.
• The sales team is angry – they cannot sell against competitors.
• The product roadmap is more of the same.

The situation is clear – you’re behind your competitors, and they are accelerating. The action plan is clear – leapfrog your competitors.

Declare failure with the more-of-the-same product roadmap, and imagine a new one. The new one must leapfrog your competitors (though they’re accelerating). Imagine a new product roadmap that’s so radical it’s borderline ridiculous, that’s so outrageous you’re afraid to present it. (A sign it’s right on-the-mark.) Imagine one you have little to no idea how to do. Now, take the best of the ridiculous product roadmap and replace the oldest parts of the old one. Create a nice hybrid, and make it happen.

Situation A is tough because there is stress around the company’s future, and it’s easy because there’s a clear reason to innovate – company survival.

a

Situation B

• The economy has dropped off, but your sales have picked up.
• Your products work better than your competitors’.
• Your product launches are more frequent than your competitors’.
• There the number of competitors is decreasing.
• The sales team is happy – they can sell against competitors.
• The product roadmap is more of the same.

The situation is clear – you’re ahead of your competitors, and they are accelerating. The action plan is clear – leapfrog yourself.

Declare failure with the more-of-the-same product roadmap, and imagine a new one. The new one must leapfrog yourself (though you’re accelerating). Imagine a new product roadmap that’s so radical it’s borderline ridiculous, that’s so outrageous you’re afraid to present it. (A sign it’s right on-the-mark.) Imagine one you have little to no idea how to do. Now, take the best of the ridiculous product roadmap and replace the oldest parts of the old one.  Create a nice hybrid, and make it happen.

Situation B is easy because there is no stress around the company’s future, and it’s difficult because there is no clear reason to innovate.

There’s no reason to argue which situation you’re in, no need to argue which is more difficult. Either way, leapfrog something.

You are you, and work is work, but work must fit you, not the other way around. Yet we hose it up most of the time. Most of the time it’s: “improve your weaknesses” or “close your gaps”.  Make no mistake, this is code for “change yourself so you fit our work.”

I say we flip it on its head; I say change your work to fit you;  I say do your work differently; do it in a way that takes advantage of your strengths; do it the way you think it should be done. It’s your work; you’re the expert; you know it best.  You choose.  Change your work.

With an uncertain economy and high unemployment, this change-the-work stuff sounds scary, but it’s scarier not to do it. Your company’s global competitiveness is weakened when you’re asked to change to fit the work; but when work changes to fit you, your company is more competitive.  Think about it – you’re more engaged, you’re happier, you’re more productive, and you do better work.

What could be better for your company?

What could be better for you?

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.

With manufacturing change is easy – lean this, six sigma that, more with less year-on-year. With engineering, not so much. Why?

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page.  But when they can, you understand.

We are responsible for our actions, for what we do, for our work, and others are responsible for their response to it. (That’s why they call it responsibility.) Though we know we can’t control others, we still snare ourselves in worry trap: What will they think? Will they like it? What will they say?

Worse than the worry trap, however, is when we actually change our work based on what others will think. A big no-no. We’re asked to do the work because we’re talented, we’re uniquely qualified, we’re the experts. Why do we let opinions of others wield so much power? Who cares what they say. We will let our work speak for itself.

There’s not much in life we have control over, but work is one of them. We control most everything about it: the what and how, the caliber, the tenor. We choose to do marginal work, average work, great work, or magical work.  It’s our choice.  We choose. When we chose to do magical work, its voice powerful enough to drown out the less capable, the politically motivated, and the CEO.

So go do magical work. Do work so good you don’t remember how you did it, so good you don’t think you could do it again, so good it scares you. But be ready – magical work, by definition, is misunderstood.

What will they say about your magic?  It doesn’t matter, magic’s voice will drown them out.