Shipulski On Design

Archive for January, 2013

Short term is getting shorter, and long term is a thing of the past.

We want it now; no time for new; it’s instant gratification for us, but only if it doesn’t take too long.

A short time horizon drives minimization. Minimize waste; reduce labor hours; eliminate features and functions; drop the labor rate; cut headcount; skim off the top. Short term minimizes what is.

Short term works in the short term, but in the long term it’s asymptotic. Short term hits the wall when the effort to minimize overwhelms the benefit. And at this cusp, all that’s left is an emaciated shadow of what was. Then what? The natural extrapolation of minimization is scary – plain and simple, it’s a race to the bottom.

Where short term creates minimization, long term creates maximization. But, today, long term has mostly negative connotations – expensive, lots of resources, high risk, and low probability of success. At the personal level long term, is defined as a timeframe longer than we’re measured or longer than we’ll be in the role.

But, thankfully, there comes a time in our lives when it’s important for personal reasons to inject long term antibodies into the short term disease. But what to inject?

Before what, you must figure out why you want to swim against the current of minimization. If it’s money, don’t bother. Your why must have staying power, and money’s is too short. Some examples of whys that can endure: you want a personal challenge; you want to help society; your ego; you want to teach; or you want to help the universe hold off entropy for a while. But the best why is the work itself – where the work is inherently important to you.

With your why freshly tattooed on your shoulder, choose your what. It will be difficult to choose, but that’s the way it is with yet-to-be whats. (Here’s a rule: with whats that don’t yet exist, you don’t know they’re the right one until after you build them.) So just choose, and build.

Here are some words to describe worthwhile yet-to-be whats: barely believable, almost heretical, borderline silly, and on-the-edge, but not over it. These are the ones worth building.

Building (prototyping) can be expensive, but that’s not the type of building I’m talking about. Building is expensive when we try to get the most out of a prototype. Instead, to quickly and efficiently investigate, the mantra is: minimize the cost of the build. (The irony is not lost on me.) You’ll get less from the prototype, but not much. And most importantly, resource consumption will be ultra small – think under the radar. Take small, inexpensive bites; cover lots of ground; and build yourself toward the right what.

Working prototypes, even crude ones, are priceless because they make it real. And it’s the series of low cost, zig-zagging, leap-frogging prototypes that make up the valuable war chest needed to finance the long campaign against minimization.

Short term versus long term is a balancing act. Your prototype must pull well forward into the long term so, when the ether of minimization pulls back, it all slides back to the middle term, where it belongs.

When engineers see a big opportunity, we want desperately to move the company in the direction of our thinking, but find it difficult to change the behavior of others. Our method of choice is usually a full frontal assault, explaining to anyone that will listen the opportunity as we understand it. Our approach is straightforward and ineffective. Our descriptions are long, convoluted, complicated, we use confusing technical language all our own, and omit much needed context that we expect others should know. The result – no one understands what we’re talking about and we don’t get the behavior we’re looking for (immediate company realignment with what we know to be true).  Then, we get frustrated and shut down – opportunity lost.

To change the behavior of others, we must first change our own. As engineers we see problems which, when solved, result in opportunity. And if we’re to be successful, we must go back to the problem domain and set things straight. Here’s a sequence of new behaviors we as engineers can take to improve our chances of changing the behavior of others:

Step 1. Create a block diagram of the physical system using simple nouns (blocks) and verbs (arrows). Blue arrows are good (useful actions) and red arrows are bad (harmful actions). Here’s a link to a PowerPoint file with a live template to create your own.

Step 2. Reduce the system block diagram down to its essence to create a distilled block diagram of the problem, showing only the system elements (blocks) with the problem (red arrow).For a live template, see the second page of the linked file. [Note – if there are two red arrows in the system block diagram, there are two problems which must be solved separately. Break them into two and solve the first one first. For an example, see page three of the linked file.]

Step 3. Create a hand sketch, or cartoon, showing the two system elements (blocks) of the distilled block diagram from step 2. Zoom in so only the two elements are visible, and denote where they touch (where the problem is), in red. For an example, see page four of the linked file.

Step 4. Now that you understand the real problem, use Google to learn how others have solved it.

Step 5. Choose one of Google’s most promising solutions and prototype it. (Don’t ask anyone, just build it.)

Step 6. Show the results to your engineering friends. If the problem is solved, it’s now clear how the opportunity can be realized. (There’s a big difference between a crazy engineer with a radically new market opportunity and a crazy engineer with test results demonstrating a new technology that will create a whole new market.)

Step 7. If the problem is not solved, or you solved the wrong problem, go back to step 1 and refine the problem

With step 1 you’ll find you really don’t understand the physical system, you don’t know which elements of the system have the problem, and you can’t figure out what the problem is. (I’ve created complicated system block diagrams only to realize there was no problem.)

With step 2, you’ll continue to struggle to zoom in on the problem. And, likely, as you try to define the problem, you’ll go back to step 1 and refine the system block diagram. Then, you’ll struggle to distill the problem down to two blocks (system elements). You’ll want to retain the complexity (many blocks) because you still don’t understand the real problem.

If you’ve done step 2 correctly, step 3 is easy, though you’ll still want to complicate the cartoon (too many system elements) and you won’t zoom in close enough.

Step 4 is powerful. Google can quickly and inexpensively help you see how the world has already solved your problem.

Step 5 is more powerful still.

Step 6 shows Marketing what the future product will do so they can figure out how to create the new market.

Step 7 is how problems are really solved and opportunities actually realized.

When you solve the real problem, you create real opportunities.

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.

If you don’t feel lonely, you’ve succumbed to group-think. No, it’s worse – you’ve stopped thinking altogether. If you don’t feel lonely you’re doing it wrong.

Mainstream follows mainstream – they don’t know why, they just do. In truth, mainstream likes to be lead by the nose because it’s easy, because they can get through the week without caring. But not caring is not right.

But when you care, when you really care, when you care so much it hurts, you’ve got it right. Loneliness hurts because you see habitual mistakes on the horizon; it hurts because you see bureaucracy trump thinking; it hurts because you see hierarchy squelch creativity. Put simply – it hurts because you care enough to look and you’re smart enough to see.

But take comfort in your loneliness. Though sometimes it feels they want to poke your eyes out, deep down companies want you to see. Sure, they’re afraid of the ruckus, but they want you to wrestle with the familiar. Yes, they won’t sanction your detectiveness, but they want you to investigate the crime scene. Absolutely – though with plausible deniability – they want your inner Nostradamus to conger the future.

Every-day-all-day loneliness is too much, but a low dose is good. 100% loneliness festers into anger, but now-and-again loneliness is healthy.

Take stock in your loneliness – it’s a sign your brain is turned on. And it’s a sign you care.

Know what’s new in the new design. To do that, ask for a reuse analysis and divvy up newness into three buckets – new to your company, new to your industry, new to world. If the buckets are too big, jettison some newness, and if there’s something in the new-to-world bucket, be careful.

Create test protocols (how you’ll test) and minimum acceptance criteria (specification limits) before doing design work. It’s a great way to create clarity.

Build first – build the crudest possible prototype to expose the unfamiliar, and use the learning to shape the next prototypes and to focus analyses. Do this until you run out of time.

Cost and function are joined at the hip, so measure engineering on both.

Have a healthy dissatisfaction for success. Recognize success, yes, but also recognize it’s fleeting. Someone will obsolete your success, and it should be you.

To get an engineering team to believe in themselves, you must believe in them. To believe in them, you must believe in yourself.