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.

However, there’s a class that must be avoided at all costs: the dumb-ass idea – an idea we should know will not work before we try it. It’s not a bad idea,  it’s beyond stupid, it’s deadly.

A dumb-ass idea violates fundamentals.

What’s so scary is today’s ready, fire, aim pace makes us more susceptible than ever. Our dumb-ass antibodies need strengthening. We need an immunization, a filter to discern if we’re respecting the fundamentals. We need a dumb-ass filter.

To immunize ourselves it’s helpful to understand how these ideas come to be. Here are some mutant strains:

Local optimization – We improve part of the system at the expense of the overall system. Chasing low cost labor is a good example where labor savings are dwarfed by increased costs of logistics, training, quality, and support.

A cloudy lens – We come up with an idea based on incomplete, biased, or inappropriate data. A good example is financial data which captures cost in a most artificial way. Overhead calculation is the poster child.

Cause and effect – We don’t know which is which; we confuse symptom with root cause and correlation with causation. Expect the unexpected with this mix up.

Scaling – We assume success in the lab is scalable to success across the globe. Everything does not scale, and less scales cost effectively.

Fear – We want to go fast because our competition is already there; we want to go slow because were afraid to fail.

What’s the best dumb-ass filter? It’s a formal and simple definition of the fundamentals. Use one page thinking – fundamentals one page, lots of pictures and few words. There’s no escape.

How to go about it? Settle yourself. Catch your breath. Let your pulse slow. Then, create a one pager (pictures, pictures, pictures) that defines the fundamentals and run it by someone you trust, someone without a vested interest, someone who has learned from their own dumb-ass thinking. (Those folks can spot it at twenty paces.) Defend it to them. Defend it to yourself. Run yourself through the gauntlet.

What are the fundamentals? Do they apply in this situation? How do you know? Answer these and you’re on your way to self-inoculation.

Innovation is largely a trust-based sport. We roll the dice on folks that have already put it on the table, and, conversely, we raise the bar on those that have not yet delivered – they have not yet earned our trust. Seems rational and reasonable – trust those who have earned it. But how did they earn your trust the first time, before they delivered? Trust.

There is no place for trust in the sport of innovation. It’s unhealthy. Ronald Reagan had it right:

Trust, but verify.

As we know, he really meant there was no place for trust in his kind of sport. Every action, every statement had to be verified. The consequences so cataclysmic, no risk could be tolerated. With innovation consequences are not as severe, but they are still substantial. A three year, multi-million (billion?) dollar innovation project that returns nothing is substantial. Why do we tolerate the risk that comes with our trust-based approach? I think it’s because we don’t think there’s a better way. But there is. What we need is some good, old-fashioned verification mixed in with our innovation.

When the engineer comes into your office and says she can reinvent your industry, what do you ask yourself? What do you want to verify? You want to know if the new idea is worth a damn, if it will work, if there are fundamental constraints in the way. But, unfortunately for you, verification requires  knowledge of the physics, and you’re no physicist. However, don’t lose hope. There are two simple tactics, non-technical tactics, to help with this verification business.

First – ask the engineers a simple question, “What conflict is eliminated with the new technology?” Good, innovative technologies eliminate fundamental, long standing conflicts. These long standing conflicts limit a technology in a way that is so fundamental engineers don’t even know they exist. When a fundamental conflict is eliminated, long held “design tradeoffs” no longer apply, and optimizing is replaced by maximizing. With optimizing, one aspect of the design is improved at the expense of another. With maximizing, both aspects of the design are improved without compromise. If the engineers cannot tell you about the conflict they’ve eliminated, your trust has not been sufficiently verified. Ask them to come back when they can answer your question.

Second – when they come back with their answer, it will be too complex to be understood, even by them. Tell them to come back when they can describe the conflict on a single page using a simple block diagram, where the blocks, labeled with everyday nouns, represent parts of the design intimately involved with the conflict, and the lines, labeled with everyday verbs, represent actions intimately involved with the conflict. If they can create a block diagram of the conflict, and it makes sense to you, your trust has been sufficiently verified. (For a post with a more detailed description of the block diagrams, click on “one page thinking” in the Category list.)

Though your engineers won’t like it at first, your two-pronged verification tactics will help them raise their game, which, in turn, will improve the risk/reward ratio of your innovation work.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change.

The relationship between innovation and technical risk must be changed. For every unit measure of innovation there must be less technical risk. Or, conversely, for every unit measure of technical risk there must be more innovation. Sounds great, but how? Well, deep questions like this deserve deep answers, answers that only the great philosophers can provide. As it turns out, the great American philosopher (and baseball player) Yogi Berra provides the answer:

If you don’t know where you are going, you will end up somewhere else.

“Where we are going”, our destination, is a solution to a technical problem which the innovation process winds us toward, and the probability we’ll “end up somewhere else”, getting lost, is technical risk. We’ve got to know where we’re going if we’re to have any hope of getting there.

The key to getting there is problem definition. Not the regular kind, but the physics-capturing kind; the kind that is expressed simply, with regular nouns and verbs, that can be explained to non-technical folks, and fits on one page. An example of this one-page problem definition can be found in a previous post. (Search the site for “one-page thinking”.) Problem definition of this type is powerful and difficult, and it’s the key to innovation. Once the real problem is defined, once the physics are understood and can be described plainly, the problem is solved, and the destination is close-at-hand.

Not many have seen or done this one-page, physics-capturing problem definition. And it’s power is severely underestimated and poorly understood. I’m sure many think I’m off my rocker when I say that one-page, physics-capturing problem definition is the key to innovation. But, I stick by my assertion. Once this hyper-rigorous problem solving helps you know where you are going, innovation can be as straightforward as entering a street address into your GPS.

In a previous post on innovation, I talked about the tight linkage between problems and innovation.  In the pre-innovation state there is a problem; in the post-innovation state there is no problem.  The work in the middle is a good description of the thing we call innovation.  It could also be called problem solving.

Behind every successful product launch is a collection of solved problems.  The engineering team defines the problems, understands the physics, changed the design, and makes problems go away.  Behind every unsuccessful product launch is at least one unsolved problem.  These unsolved problems disrupt product launches – limiting product function, delaying launches, and cancelling others altogether.  All this can be caused by a single unsolved problem.

The best engineering teams can solve the toughest problems, and the worst ones, well, you know about those.  So, what level of problems can your engineering teams solve?  That’s a difficult question to answer.  What truly matters in the trenches is how the problems of the day stack up against the engineering teams’ capabilities.  And you must not kid yourselves and overestimate your teams’ capabilities.  You have to solve problems with the engineering teams you have, not the engineering teams you want.  Don’t get them in over their heads.  They’ll drown and then so will you.

It takes a good eye to tell when engineering teams are in over their heads – when the problems are too big for their capabilities.  Here are some signs of trouble.

The project team cancels the review meeting.  There is nothing worse that cancelling a review meeting, except being called out at a review meeting for not knowing what the hell is going on.  This is the proverbial dog-at-my-homework scenario – the stranger the reason for cancellation, the bigger the problem.  It’s actually a good sign if the project manager sends out a message saying “We have a big %$#@! problem and we’re cancelling the @*&$#! meeting.”  A confident project manager will send out a message like that.  A scared one won’t.

The project team holds the review meeting, but it’s long, highly technical with complex arguments.  The length and technical content is intentional.  It’s a technique used to distract, to hide behind complexity.  If the review meeting is an endless barrage of formulas, complex graphs, and 3D plots, watch out.  They’re trying to hide something.

The project is behind schedule and the team holds a review meeting.  During the meeting no one uses the words “I don’t know”.  Remember, a confident team will say “I don’t know”.  Here are some phrases to watch out for: “After a review of the literature we believe it could be…”, “We’re running analyses on some new software….”, “I bet my career that it will work.”

At the review meeting a junior engineer is given an “opportunity” to present the key results (the problem).  All the senior engineers know better than to stand up and read slides like those.  And, the project team knows you’ll go easier on the junior engineer because you know she is not responsible for the problem.

Senior engineers slowly and quietly migrate to another project.  No one is quite sure why.

Engineers volunteer for sustaining engineering work (crap work) just to get off the project.

The project team refuses to accept help even when offered the best engineering talent.  This circling-the-wagons technique is intended to keep the real problem within the team.

There is hope.  There are things that can be done to improve the situation.  First, company leaders must recognize the importance of problems and decide they want to solve problems better.  That’s the hardest part.  Now, on to the easier stuff – creating a problem solving process. 

There are several aspects of a good problem solving process.  Most processes underwhelm the problem definition work.  Yours should not.  It’s easy for your doctor to make your problem go away once the diagnosis is made.   Nick Siler sent me this quote by Larry Burns, outgoing Chief of R&D at General Motors, who is credited with GM’s massive leap forward in the area of fuel cell hybrid powertrains and vehicle communications:

…focus as hard on defining the questions as you do on trying to answer them. I have found that once you really understand the question, you are 90 percent of the way home. In addition, you need to recognize that in the real world, the questions are often ill-defined, data are often messy and methods frequently do not apply exactly as they have been taught. You will need to learn to deal with this ambiguity. Finally, great opportunities lie at the interface between disciplines, so be sure to take a systems approach in your work.

To paraphrase the Mr. Burns – there is nothing worse than solving the wrong problem. 

The problem process should require the team to define the underlying physics, the fundamentals of the problem.  No kidding, the team should be able to make the problem come and go at will.  This is hard work and feels too slow, but it’s actually faster.

The process must drive out complexity, complexity created by technical language and long presentations.  The problem must be defined on one page.  Not two pages, one page.  Technical language is replaced by symbolic language of blocks and arrows.  Each block represents part of the system and is labeled with a simple noun.  Each arrow represents an action and is labeled with a simple verb.  Together, the blocks and arrows define the problem in an unambiguous way.

Lastly, the process should be reinforced at every opportunity, especially project review meetings.  The engineering teams must be held accountable for following the process.

To close this one  out, we all have problems; they are real.  But that’s okay.  We should learn to embrace them, rally around them, define them, and get rid of them.

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  It’s always a great idea to ask for products with radical improvements in functionality, but it’s another thing altogether to create products with radical improvements – to engineer them.  You must have good engineers if you are to create these types of products.  It’s good if you have been able to hold onto your engineers through the recession, that’s a good start.  If you were not, that’s bad — you must get some.

Designing products with radical improvements is difficult even for the best engineers.  Your engineers are bright but have not been taught how to design these products.  Usually they design them by instinct which is a root cause for the low hit rate and schedule misses.  Everyone is afraid of falling short of the specification and missing the schedule; going after radical improvements is a scary business.  It is scary because success rides on the instinctive skills of the engineer.  But there is a better way.  Engineers can be taught to do this work.

It is my experience that the toughest part of solving technical problems is defining the right problem to solve.  Yet, we don’t take the time to define the problem well enough.  It’s usually a ready-fire-aim approach to problem solving that is long on activity but short on progress.  Paradoxically, the engineers must slow down in order to make faster progress.  The engineers must be taught to painstakingly define the physics of technical problems using simple language (simple nouns and verbs) and simple block diagrams.  This is not easy.  It takes a lot of work to help (force) the engineers to shed the complexity to reveal the simple truth.  And, it takes a lot of energy to calm the managers who think nothing is going on during the problem definition phase.  Managers are more comfortable watching activity than watching thinking. 

In these difficult times it is especially important (and especially difficult) to give your engineers the tools, time, and training to achieve radical improvements.  But take comfort in an engineering paradox – sometimes slower is faster.

So why is this technology stuff so hard to shape and guide?  Well, here are a few reasons: technologies have their own set of arcane languages, each with many dialects (and no dictionary); they have their own technology-centric acronyms that technologists mix and match as they see fit; and they are full of long-forgotten formulae.  And these formulae are composed of strange math shapes and symbols.  And, as if to elevate confusion to stratospheric levels, the math symbols are Greek letters.  So, literally, this technology stuff is written in Greek.  So what’s an all-too-busy CEO to do? It seems a CEO has no other option than to take a TRUST-based approach.  The CEO must trust the technologists — trust the VPs of technology; trust the fellows; and trust the chief scientists.  The hope is that technologists who have delivered before will deliver again.  However, this trust-based approach is not a good one, as it puts a CEO at the mercy of the technologists.

Some CEOs will say they don’t take a trust-base approach, that they do it better.  They will say something like “I hold regular reviews of the technical work, so I know the real problems and I know how we’re going to solve them”.  To that I say:  The VP presenting to you doesn’t know the problems or how to solve them, so they can’t tell you what’s really going on.  That long and beautiful PowerPoint presentation does not capture the essence of the problems; it only dilutes the problems.

There is a better way – a way to distill problems rather than dilute them; to clearly, simply, and unambiguously define problems using words we can all understand; to trust, but verify.  I call it One Page Thinking.

One Page Thinking is a method to define a problem at its most basic level so that everyone can understand it.  There are a couple simple rules for One Page Thinking:

1.  Each problem must be defined on one page.

2.  There can be only one problem on a page.

Here is an example of One Page Thinking for the problem of being overweight.

The physical elements of the system are represented as blocks labeled with nouns (PERSON, FOOD, CALORIES); the actions are represented as arrows labeled with verbs (EATS, PROVIDES, POWER).  The undesirable action is represented by a red arrow and an X in front of the verb (X MAKE).

All technical problems – even complicated ones – can be distilled into this type of simple diagram, but it can only be done if your technical staff truely understands the problem.  True understanding is required to translate complex physics and math into simple nouns and verbs and to translate complex interactions into straightforward block diagrams.  And, likely most importantly, true understanding is required to stand up in front of a CEO with only a single slide consisting of a block diagram and simple nouns and verbs.

So, if you want to find out if your technical staff understands the problem at hand, ask them for a one page block diagram using simple nouns and verbs.