Two days before starting a new job, Dave, the VP who hired me, asked that I stop by his office.  He told me that his A10 Program Manager had just resigned.  Would I be willing to take over, on a temporary basis, until they could find a permanent manager? By this time in my career I was smart enough to know the correct answer was yes.  So after saying, "Yes," I asked, "What's an A10?" The answer is, “an Air Force combat jet fighter, also known as the Wart Hog.”  Dave and I were up front with the Air Force Project Manager, Don.  We told him about my background and the lack not only of A10 experience, but also that I had no prior experience with any Air Force project.  Don said, "That's okay, I know enough about the A10 and Air Force for both of us.  You appear to have some skills we need.  So let's give it a try." The temporary position lasted 2 1/2 years.  After about 3 months on the job, Don made a presentation.  He gave me a model of an A10, carefully explaining such things as which end was the front.  It was his way of saying that I passed his acceptance tests.  Later in the project he commented I could fly wing for him anytime.  That is the highest compliment a jet jockey can give.  But the project had troubles. 

In fact there were more personnel and people communication problems than I had ever seen in 10 other projects combined.  First, I need to tell you what we were doing.  Combat aircraft like everything else have become extremely complex.  Keeping them combat ready was becoming more and more difficult.  When a craft was believed to have a fault, various components were removed for bench testing until something failed a test.  Sometimes nothing failed.  Sometimes the fault only appeared with the system operating as a whole.  Sometimes when the plane was put back together new failures appeared.  And then there were the pilot complaints.  My favorite is, "The plane feels mushy, fix it!" Incredibly, the mechanics knew what that meant.  One of about 30 actuators was responding slower than the pilot expected.  All they had to do was to find the right one and replace it.  The problem was, it could be any one of them.  Each typically took 2 days to remove and bench test at a cost of about $30,000 each.  Don's idea was to connect a computer to the plane's data and control circuits and test the components without removing them.  If it could be done it would significantly reduce costs and increase combat readiness (the percent of time a plane is ready for combat).  But, could it be done? That was the technical challenge.  There were also people challenges.  Here is a partial list of those problems.

1) I was new to the company, new to the A10, new to the Air Force, and new to the project.  The project had just successfully completed a feasibility demonstration.  Many of the old timers were not pleased with my appointment and that I would be making the hiring decisions to quadruple the staffing.

2) Don was the recognized worldwide Air Force expert on the A10.  He also had a worldwide reputation as the "wild man."  He wore his reputation as a badge of honor.  One day he burst into my office and slammed the door and screamed, "I want you to immediately fire, Ben."  Since we were contractors Don had no direct authority over the staff.  His opinion of us was, of course, very significant.  Don and Ben never got along well.  They were a typical example of personalities that just were not going to think well of each other.  (In MBTI language, Don was an INTJ and Ben was an ESFP)  I asked Don what Ben had done.  Don explained that Ben had a photograph of Mars from a recent NASA mission on his government provided PC as a screen saver.  Don claimed this was a misuse of government equipment.  We discussed the matter for awhile and I told Don I would get back to him about what I could do in no more than 2 days.  Don's position was groundless.  Contractors can add software to government issued workstations; the most common addition was the company email.  Government regulations clearly identified that up to 10% of a workstation can be used for other than contract specific activities.  There are, of course, a whole host of guidelines about appropriateness and security.  But Ben was not violating any rules.  Don was acting per his "mad-man" reputation.  I knew the incident would largely be forgotten as long as I did not ignore Don.  So two days later I told him I had looked into it, but my hands were tied.  The regulations clearly give me no basis for any disciplinary action.  Don accepted it without a complaint.

3) Ben's wife was a slow cycling manic-depressive.  This had nothing to do with his conflict with Don, but it added to Ben's stress.  His wife was very distrustful of his work situation.

4) The 14 year old mentally retarded daughter of one of the staff was raped.  For some time her mind was not on her work.

5) The software manager needed extensive time off.  He was attending the trial of the person who had murdered his step son 2 years earlier in a robbery.

6) The avionics manager spent most of the month before and after the anniversary of the unsolved murder of his fiancée in a deep depression.

7) The hardware manager, who felt he should have my position, was taking actions directly contrary to what had been asked of him.  Dave and I put him on formal probation.  He came around and is still with the company.

8) Corporate had assigned an individual to the project.  John was an Associate VP.  He was a 2 digit badge holder.  Two digit badge holders were individuals who were among the first 99 employees of the company.  Neither Dave nor I had any say in the matter.  I was told to make him a productive member of the team until another position could be found for John.  John's resume was impressive and his accomplishments were meaningful.  My initial thought that John might be a corporate selected replacement for me turned out to be totally wrong.  John did none of the assignments given him.  I had complaints from other staff members of harassment to the point of physical threat.  John was a known to be a collector of knives and guns, which added to certain staff member’s concern.  When I confronted John he immediately became belligerent.  I discussed the matter with Dave and we agreed there was no option other than to document his behavior.  Before we were through we had involved the corporate senior VP of Human resources, who put John on an extended leave of absence.  The situation was thought to be so sensitive we had security attend when John was informed.  It turned out that John's behavior had been going on for some time, but no one had documented it so corporate was at a loss as to how to proceed.  John had been a very significant contributor in the past and they did not want to just fire him.  After my report they put him on extended leave of absence with full pay on the condition that he have a complete medical examination.  We later learned that John had an inoperable brain tumor.  It was the cause of his behavioral change. 

Dave and I were very concerned.  The productivity of the staff was clearly being affected by the personal turmoil.  Most of the above was visible to everyone. 

Totally unconnected to this work I had been extending my Ph.D. work from a theoretical ability to create a simulation of organization behavior to a practical capability.  Such simulations would include personnel issues as above.  I had managed to convince Don to support a side project of testing my theory.  I wrote a set of specifications and we retained a subcontractor to implement my simulation in software.  When the subcontractors, Michael and David, delivered the software and I ran the simulation I was disappointed but not surprised.  The simulation was clearly not correct.  This was after a first attempt and it was somewhat complicated.  I assumed there was a programming error and thus I resigned myself to finding the mistake.  Three days later I had not found the fault, but I did learn a few things from Michael and David about programming.  Well maybe the code is not at fault.  Just maybe, the fault was in my design.  So I spent another 2 days reviewing my simulation design.  I could see nothing wrong.  I had been so convinced it would work, but how could it be that all of the personnel problems didn't have a meaningful effect on cost or on-time delivery.  Perhaps the fault was my assumption that the effect should be there. 

So I asked a different question.  I had been asking, "Why didn't the project fail as I added more personnel problems or get better if I reduced the problems?" Instead I asked, "Why was the project so resilient to personnel problems?" And then it all made sense.

A feedback loop was keeping the project together.  It started with a cultural attitude.  Everyone involved believed that when a pilot strapped a jet on his back his life was at risk if a mechanic made a mistake.  Then there was the attitude that if the mechanic said our system had a mistake in it, it had a mistake.  One might question if the mechanic was right about the nature of the mistake.  But, if the mechanic thought the system was wrong then, he would likely do something incorrect or not use the system.  Therefore, our work was always at fault.  Everyone in the project got a report on the mechanics' evaluation.  As I increased the number of personnel problems the number of mistakes increased, but they always got fixed.  If I interrupted the feedback at any point in the simulation, nothing I did to fix the personnel problems would result in successful completion of the project.

The project was astoundingly successful.  It exceeded all expectation.  It was on time and within budget.  My principal contribution was to not interrupt the feedback. 

As a side note the company I worked for was so impressed they decided to follow up with a corporate project.  The corporate project would adapt what we had done for the military to the commercial airline industry.  They were going to make hundreds of millions of dollars.  By this time I was no longer with the project.  I had finally started doing the job for which I was originally hired.  I tried to tell them it would not work.  Not with this team anyway.  There was no feedback loop.  The staff just didn't care how much money the company made.  They did care what happened when a pilot strapped a jet on his back.  There just wasn't enough risk in the commercial industry to hook them into a feedback loop.  The corporate project failed.

If you do everything else wrong and get the feedback loop right you will succeed.  It is that important and that strong.  Alright there is one caveat.  The staff has to have the minimal skill necessary to do the work, but only the minimum skill necessary.

ç  Prior Page of Text     Next Page of Text è
(C) 2005-2014 Wayne M. Angel.  All rights reserved.