Yamamotosan was clearly none too happy as he stood up to approach the podium that day.  That much was painfully obvious to me and anyone who was paying attention.  But during his brief talk, he did something that was downright shocking.

​

For those not acquainted with Japanese culture and business practices, I strongly recommend T. R. Reed's excellent book "Confucius Lives Next Door."  Reed spent five years living with his family in Tokyo while heading up the Washington Post's office there, and providing a weekly commentary on NPR's "All Things Considered."  As Reed explained in his book, when it comes time to complain or object to something, Japanese etiquette requires almost avoiding the topic while other pleasantries are exchanged.  And even when they finally get around "to the matter at hand" as Reed's neighbor Matsuda, explained when calling to lodge a complaint about the noise his son was making, he barely mentioned it, and yet the message was delivered.  Here is a link to an interesting review of the book that also talks about the same episode.

​

Thus, when Mr. Yamamoto stopped in the middle of his prepared remarks, turned and faced the Boeing execs on the stage, and said in a stern voice with a glowering glowering expression "and ANA looks forward to receiving our first 787 next May," and then paused for several seconds to continue his clearly angry gaze at them.  In effect he was calling them all liars right to their faces, which was the bald truth of the situation of course.  This was done on stage, with a monster of a video projection behind him so all of the thousands of people present clearly see his features.  The mic was open so everyone could clearly hear his comment and see his face as he delivered it, all with over 300 reporters present.  In addition to that, there were live video hookups to the key supplier locations in Italy, South Carolina, Kansas, and Japan.  The ANA press release did not mention the incident, but it did repeat the delivery expectation, which I'm sure was another way of repeating the complaint.

​

To say the least, I was quite stunned, but of course, the facts of the matter were very clear.  ANA had a team on-site in the engineering building on the Everett Campus as did the other early customers of the 787 program.  It was just on the other end of the floor where my desk had been several years earlier.  I'm sure that ANA's internal status charts on the progress of the program were quite accurate, while those circulating inside Boeing were all watermelon charts.  The Boeing execs should have expected something like this.  And yet, as I stood there in shocked disbelief at what Mr. Yamamoto had just done (and quite thankful for him having done it), I got the distinct impression that our execs didn't have so much as a clue as to what had just happened.  They certainly had no insight into just how thoroughly incompetent their own program management skills and attitudes were.

 

I start with this story to make a point about the tanker program.  As bad as things were on the 787 program, things would get much worse on the KC-46 tanker program over on the defense side of the company.  At least the 787 concept was rock solid, and once we got it done and after we started assembling them properly most of the time (at least at the Everett site), the 787s would go on to become the finest airplanes in the sky.  Even though the program would never make a dime, and in fact would still be hundreds of millions of dollars in the red fifteen years after that fateful day (re. time value of money applied to the development costs which still need to be properly expensed on Boeing's books), it was a great airplane with a bunch of breakthrough concepts in its design.  The tanker?  Not so much.  Oh how far we had fallen, and how little time it had taken to happen.

​

To the Greeks, hubris was a gift which the gods would bestow upon those whom they are about to destroy.  There is a passage in the play Antigone by Sophocles which goes to this point (lines 604-625), and equates the gods messing with a person's mind to an implantation of evil.  In the creation of his list of evil thoughts that would evolve to become the medieval concept of the seven deadly sins, Evagrius Ponticus noted that the last item on his list, hyperephania (i.e. pride. Here is a link to a surprisingly excellent discussion on tumblr), tended to factor into each of the others.  Engineers have a problem in this space, especially when it comes to concept development.

​

Perhaps the most dangerous thing that someone can ask an engineer is "can you do x?"  To an engineer, a question like this is like red meat to a dog.  It is instantly a challenge to see if there might be some way to pull it off. 

 

Wanting to solve problems or challenges is an admirable trait.  But, it must be tempered with caution.  One of the most important job requirements for any engineering manager is to know when not to ask that question, or when to say 'no' to someone from sales or upper management when they come knocking. 

 

There are two immediate issues or questions that accompany any engineering or technical challenge.  One is whether or not the initial idea or approach is reasonable or even feasible.  Another is whether or not the problem should be tackled at all.  This second one is the Jurassic Park problem, and we'll get to that below.  But first, let's look at the concept development process.

​

How much testing should be done before a concept development team should report that an idea or concept is sufficiently sound to be used as the basis for launching a full scale engineering development program that is likely to cost hundreds of millions of dollars and put the company's future, its reputation, and perhaps its solvency on the line?  Sadly, these questions have not always been subjected to the kind of objective rigor that is appropriate and necessary.

 

Manufacturing engineers (MEs) tend to make fewer and less costly mistakes in this space than design engineers (DEs).  Maybe that's because DEs are more of the dreamer type, as opposed to the down to earth practicality that one tends to associate with MEs.  But, there is an interesting overlap in thought processes here.  It is common for MEs to go forward with a production plan which at first will have excessive unit costs.  There is a lot of confidence in the ME community in their ability to apply the discipline of continuous improvement (sometimes called "the learning curve" in the literature) to eventually get their production costs down to levels that are not only profitable, but which also quickly recoup the cost overruns for the early units.  In Boeing's system of program accounting, the number of units that have to be produced and delivered to get overall program costs to the breakeven point is called the accounting block.  This is perfectly acceptable in the ME community because they have a good track record of making it so, or at least they did before Harry Stonecipher and Jim McNerney blew up the process.  But, the DE community has no such track record for converting nonperforming concepts into winners.  That is a fool's errand.  Non-performing concepts need to be identified as such early, long before they are committed to production, and some other solution needs to be pursued.  This was not done on the tanker program.  In fact, to this day, they are still chasing a total program concept that should have been evaluated and discarded before the first plane was built.  Or, the program should have been converted into a one plane concept feasibility or demonstrator program so the idea could be tested before committing the billions of dollars wasted on it thus far.

​

Admitting that an idea isn't going to work out as initially thought can be a very hard thing to do.  It requires a lot of humility, which is one of foundations of our requisite cultural elements of integrity and transparency that are so critical to the discipline of the schedule during the execution of a full scale engineering development program.  

 

In science, one of the requirements for a proposed model or theory is that it must be falsifiable.  There has to be some notion of what sort of data or evidence will demonstrate that it is false.  Then, if the model or theory is to be put to the test, one has to go and actively look for that sort of data.  The experimentation process will then tend to either validate or refute the concept.  Good engineers must do the same, and the sooner the better.  In developing concepts for satisfying the customer mission requirements for an air vehicle, the kinds of tests that are required are usually pretty obvious.  Test the concept against critical mission performance assumptions.  Can a fully loaded 777 take off on a hot day in Denver and have enough range to safely make it all the way to Honolulu?  Can a tanker with a remote visioning system's (RVS) boom operator's console mounted above the center wing box, be operated by even a well trained human and reliably refuel another plane?  Can it do this task better than an aging (or should we say "antique") KC-135, and can it do it in the most challenging mission profiles that the KC-135 routinely performs, which is at night, lights out, near hostile air space, with the plane desperately needing refueling being one of our stealth fighters?  Can we deliver a system that is at least as good as one that is fifty years old?  If a hint of sarcasm has crept through that, then the point I'm making here about the problem of pride and hubris has been made. 

 

There is an integrity element to this concept validation process as well.  Never ever blame the customer for a validation test failure.  If the idea can't support the customer's mission, that is not the fault of the customer.  Everyone who has ever had anything to do with the KC-46 should take that one to heart.

​

Now let's look at the other issue.