Shipulski On Design

Everyone laughs at the person who says “We don’t have problems, we have opportunities.”  Why do we say that?  We know that’s crap.  We have problems; problems are real; and it’s okay to call them by name.  In fact, it’s healthy.  Problems are good.  Problems focus our thinking.  There is a serious and important nature to the word problem, and it sets the right tone.  Everyone knows if the situation has risen to the level of a problem it’s important and action must be taken.  People feel good about organizing themselves around a problem – problems help rally the troops.

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.

2 Responses to “Problems are good”