Pushing on Engineering

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.

6 Responses to “Pushing on Engineering”

  • Mick Maguire:

    Good advice Mike… as Einstein once put it “If you can’t explain it simply, you don’t understand it well enough”

  • Gajanan Nigade:

    Very Nice advice on teaching/training in an engineering organization. I will give it a try with my team and post with my perception of the results.

  • Mike:

    I’m glad you found my post valuable, and I look forward to learning from your experience with the methods.

  • Bill Devenish:

    Mike, this goes along nicely with leadership providing a clear, concise vision for the organization. If the leaders can easily explain where they want the company to go they can effectively push on engineering.

  • Huh? You mean we don’t need to bang our heads against the wall any more? 🙂

  • Chinmoy Banerjee:

    It is very possible to apply Lean in Engineering function as well. Typically when we refer to Engineering we are referring to an Engineer’s role in the Product Development process. Lean doesnt necessarily mean reduce Engineers. Lean tools can be applied to speed up processes that an Engineer deals with as they go through the Product development process. The biggest barrier to an Engineer delivering the outcome is “Wait time”. Understand what causes “wait time” in your organization and you have freed up the Engineer to move quicker and therefore deliver quicker. Imagine doubling your Product Development output, by enabling your Engineers to move faster through the Product Development process. Now thats Leaning the Organization.

Leave a Reply

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives