Tag: management

Flight Director Fables

Aesop’s fables have been famous for two millennia.  They are obviously fictional stories – animals talking and such – but they are still useful for teaching important concepts to children – and adults.

 

When I joined the Flight Director office there were a number of fables that we were taught.  Supposedly true, I cannot say that they really are.  But the moral of these stories was the point.  I’ll share just two with you today.

 

First Fable:  how to end your career quickly.

 

Gemini 8 was as close a call as American had in space up to that time.  Neil Armstrong and Dave Scott had just completed America’s first space docking between their Gemini spacecraft and an Agena target vehicle.  Suddenly, the stack started spinning up for no apparent reason.  Emergency undock was performed by the crew who hoped that the problem was with the Agena.  It was not, the spin rate increased more dramatically after separation.  Armstrong shut off the Gemini spacecraft’s primary attitude control system and activated the secondary system which was designed for limited use during re-entry.  Attitude control was regained, the crisis averted, everybody started breathing again. 

 

The Flight Rules called for an immediate deorbit once the re-entry attitude control system was activated; it had limited fuel and limited life.  So Flight Director John Hodge (Blue Flight) had the team execute a rapid deorbit to the secondary landing site in the Pacific Ocean near the destroyer USS Mason.  You might think that was the right thing to do.

 

Unfortunately . . . .

NASA management found out about the situation after the crew was in the ocean.  According to the legend, Hodge did not take the time to pick up the phone and call the Program Manager, the Center Director, or even his boss, the Chief of the Flight Director office.  The situation was stable, and even though waiting around was not necessarily a good thing, there was no reason that a couple of hours delay would have significantly increased the crew risk.  Upper management was severely out of sorts with Blue Flight because they were not called in to review a critical action that really could have waited, despite what the Flight Rules called for.

 

Bottom line:  John Hodge never served as Flight Director in Mission Control again.

 

Now, that is the way the story was told to us wide-eyed Flight Director wannabees.  Is it true?  Is it accurate?  Is it complete?  I have no way of knowing.  Probably not. 

 

But that is not the point of the fable.  The moral of the story for all rookie Flight Directors is ALWAYS INVOLVE YOUR MANAGEMENT.   Any time that a critical action can reasonably be delayed for even a few minutes GET ON THE PHONE WITH THE BOSS.  No matter what the Flight Rules say.  After all, it’s just your career on the line . . .

 

Second Fable:  Lies will catch up with you.

 

A long time ago, it seems hard to imagine now, there were no privacy laws and the press was ALWAYS interested in crew health.  Since about 60% of all astronauts have ‘space adaptation syndrome’ for the first three days of weightlessness.  The press could always get a good barf story.  Sometimes it seems like journalists never left the 5th grade.  Today a Flight Director can respond to questions about crew upchuckitis by saying “Detailed discussions about crew health are covered by the medical privacy act.  I can tell you that there has been no mission impact from any crew health issues.”  There is rarely any mission impact these days because we have learned to build a light schedule the first few days to allow the crew to get past the need for the emesis bags. 

 

In the early days of shuttle, such niceties did not exist.  Every eight hours the offgoing Flight Director had a post-shift press conference and had to withstand the barrage of questions from the media, who were just hoping to get some human interest story out of the tight lipped and technical NASA officials.  John Cox, Granite Flight, kept drawing the “space sickness” questions.  He made the huge mistake of putting out a fib:  ‘Crew is doing fine, no problems to speak of”  in one of the early press conferences.  A day later, the crew was definitely NOT doing fine, activities had been cancelled.  But Granite Flight kept up the pretense.  The press corps was suspicious.  By the third day Granite Flight’s denials fell apart and the media went into witch-hunt frenzy.  The video tape of that heated press conference is kept in the Flight Director training catalog and it is ugly with a capital U.  The head of Flight Medicine, Dr. Sam Poole, had to come in and save Dr. Cox.  Sam put a soft spin on things and more or less diffused the issue, but the damage was done.  Granite Flight’s credibility with the media was in the dumpster.

 

Now, is that the entire, completely accurate story?  Probably not.  But we all had to watch that press conference videotape knowing that we would be in that hot seat in the very near future.  The moral of the story:  DON’T LIE TO THE PRESS.  They will find out sooner or later and it will be very bad. 

 

Whenever people ask me how to deal with the media, I reply: “The first rule is tell the truth, never lie.  You will be found out and your credibility will be gone from then on.”  I’ve had lots of practice with press events after learning that less from poor old Granite Flight, and I can confirm it’s true.

 

John Cox was a great Flight Director and served for many mission.  I have a great deal of respect for him, not the least of which is that he dug his way out of that hole.

 

Remember, everybody is useful, sometimes just as an example of what not to do.

Getting Myself Fired

In 1985 I was a Propulsion Systems Officer in the Space Shuttle Mission Control team.  I was responsible for the reaction control system that was absolutely vital to orient the space shuttle outside the atmosphere, and for the orbital maneuvering system which provides the final push to get the orbiter into orbit and the deorbit burn to come home.  These liquid rocket systems are a mechanical engineer’s delight:  lots of plumbing, valves, some smoke and fire, knowledge of orbital mechanics required, thermal control, crew interaction, and software.  We had a great team and I was proud to be part of most of the early shuttle missions.  But it was time to make a move to supervisor, and in the spring of the year I was selected to be the leader of the INCO group.

INCO stands for Integrated Communications — that’s just about what you think:  radios, recorders, instrumentation, television.  That discipline is an Electrical Engineer’s delight.  Not mine.  I took exactly one EE course in college and nearly flunked it.  But the big bosses said it was OK, I would be a supervisor who knew all the processes and procedures for Mission Control.  I didn’t need to understand the technical stuff, they told me, that was what the staff was for.

That was a lie.

Very quickly I found out that understanding the basics of radios and digital electronics was absolutely mandatory for supervising the INCO team. 

Oh, and the INCOs were responsible for the coffee pots for the MCC — but that story will have to wait for another post.

I decided that I would have to go through the process to be certified as an INCO if I were to lead this group.  This is not easy!  The INCO team is made up of the shift leader in the FCR (who you see on TV) – he is the guy who owns the title “INCO” and responds directly to the Flight Director; then in the “back room” are the support staff:  RF COMM, and INST.  The entry level position was INST.  The Instrumentation Officer is responsible for the onboard telemetry, the signal conditioners, the engineering recorders, etc. 

I understood nothing about any of this stuff.  But the INCO folks recognized that they would have to teach me their job if I were going to be an adequate leader, so they all pitched in.  I read the books, went to the lectures, observed the operations in the MCC, did all my homework.  Then I was ready to start working in the MCC for the integrated simulations.  With the astronaut crew in the space shuttle simulator in building 5, and an entire Mission Control team in building 30, these sessions were intense.  The Simulation Supervisor and his training team were diabolically clever in developing training lessons where interlocking malfunctions could appear insurmountable – but which a good crew and MCC team could overcome.

On my final day as the supervisor of the INCO section, I participated in an integrated Ascent simulation.  We would practice launching the shuttle over and over and over again, with the clock picking up about 2 minutes before liftoff, and as soon as the shuttle cleared the tower malfunction after malfunction appearing in short order.  Most of the time the crew survived.  Sometimes the shuttle even made it to orbit.  But it was intense.  And back in the office, all the Flight Control management is listening to the comm loops to hear how well the team is doing.

It was an artifact of the system that when the simulator starts at T-2, not all the communications system is in the right configuration.  In real life, the INCO team has many hours to command all the various components to the optimum conditions for launch, but in an integrated Ascent sim, there are two minutes to get everything configured properly onboard.  This meant that the INCO, the RF COMM, and the INST were all banging away on their command keyboards furiously to get all the commands sent to the (simulated) shuttle before lift off.  In those ancient days (well before PCs and point&click logic), the consoles had the Multifunction Command and Display Keyboard.  Basically this was a bunch of pushbuttons which had the hexadecimal alphabet on the keys plus one larger key marked “Command Execute.”  You had to know the hexadecimal code for the command you wanted to send; have the dexterity to type it in correctly; confirm on the computer display the code was entered properly; then hit Command Execute for the big mainframe computer on the ground floor of the MCC to send the command.  A fraction of a second later the command would be received at the shuttle (real or simulated) and if everything lined up properly Things Would Happen.  The Right Thing, you hoped.

So with each run, my job was to start the MADS recorder – capturing the “ancillary” data for post flight analysis.  As soon as the simulator went to run at T-2 minutes, I would carefully type in the hexadecimal command for MADS recorder start, verify that code appeared properly on my computer screen, and push the command execute button. 

Ascent simulations are not very interesting to the INST operator because Sim Sup generally targets the bigger systems — main engines fail, external tanks leak, fire breaks out in the cockpit, stuff like that.   Ascent runs take only about 15 minutes, then you debrief, turn the simulator around, and start again.  Many times.  After all day, I got pretty good at starting the MADS recorder.  Ticky tickety tick, execute.  Next run:  ticky tickety, tick, execute.  And repeat. 

On the last run of the day, I punched in the numbers by rote, disregarded the computer screen and hit the execute key.  “WHY DID THE FM TRANSMITTER JUST TURN OFF” echoed in my headset.  “INST – YOU SENT THE WRONG COMMAND!”  Uh oh.  Just one little keystroke wrong.  I was the goat.  

The debrief was not fun. 

When I got back to my office, there was a note on my door from the Division Chief:  “Come see me”. 

As I said, that was my last day as an INCO.  Back in the PROP section the next morning. 

Moral of the story:  Treat each command as if it were your last.  It could be.