by Paul Dye
An organization that wants to be successful needs to continue to encourage people to study successful leaders—and to identify good leaders for those who are trying to pick their role models.
Mission vs. Organization
Like most large organizations that started out small, NASA (and its suborganizations) became a self-eating watermelon. In many cases, NASA became more concerned with organizational survival than with mission execution. It can be hypothesized that this was part of the conversion to a “business” outlook, in which the survival of the business is assumed to be a top priority. But in the case of a mission-oriented organization, such as NASA was when it was formed, the goal is not organizational survival but mission execution. This is one of the reasons that we became so conflicted in program management—we did not have a clear mission and, therefore, we simply tried to make the organization survive until the next mission came along. But if the organization isn’t right for the mission, then the mission suffers as the organization tries to refit the mission.
I would submit that organizational survival should not be a significant driver in a group that is trying to execute bold, important missions. In fact, I like to tell people that I really had no emotional attachment to, or interest in, MOD—the Mission Operations Directorate. This shocks many, and is, in a way, a bit of baiting (because I do care greatly for the people and the traditions of MOD). But I didn’t come to work in Houston to be part of MOD—MOD didn’t exist. I worked for the Flight Operations Directorate (FOD) back then, which later split into the Flight Crew Operations Directorate (FCOD) and MOD. The world did not change when these organizational changes took place. These changes were merely necessary to better align us with our mission (which was, at the time, to fly the Shuttle forever and go on to do other, bigger things as well).
While it is a great and necessary thing to build comradery and esprit de corps around an organization like MOD, I believe that it is more important to rally the troops around a mission. So long as the organization supports the execution of that mission—or vision—then the synergy is ideal. As soon as the leadership finds that they have to change the mission in order to make it better align with the organization, then they have a problem. It needs to be the other way around. All organizations should be molded to fit the mission, and not vice versa.
People used to work at Johnson Space Center (JSC), putting in very long days and working weekends, because they believed in the mission—whether it was flying the first men in space, going to the moon, or flying the first reusable spacecraft. Even building the ISS was a great mission that had lots of dedicated people putting in excessive amounts of personal time. But later, we spent an inordinate amount of manpower trying to come up with ways to preserve our organization, grow our organization, or organize our organization—with few mission results to show for it. Lean and mean—that is how you accomplish the missions.
It should be noted that just a few years after I left the agency, JSC did, in fact, change up the organizational structure of operations again, this time recombining the Flight Crew Operations Directorate with the Mission Operations Directorate. In essence, they came back full circle to where they were when I joined JSC in 1980. The new Flight Operations Directorate has been working as a single entity now for a number of years, just like we did in the early days of the Shuttle program. This doesn’t mean that MOD was a bad idea; it was a good idea for its time. But times change, and organizations need to change along with those times—and the missions.
Process vs. Product
About the time I started to get into a management role at NASA (as a lowly section head), the agency started looking for the latest management tools, theories, and practices. In my early days, it was clear that everyone in the organization was focused on technical matters—getting the job done, making sure our technical products and people were up to the task, and getting missions flown. Staff meetings were about those technical issues, vehicle status updates, training schedules, and so forth. Every bit of information we handled was mission related. Then things changed. We know why: the Shuttle was going to be an ongoing operational program “forever,” and we felt that we needed to change from an R & D model to a production model for the human spaceflight operations organization. So we started looking at how business ran factories and production organizations. And this meant we started to focus on the processes more than we focused on the product.
Staff meetings became purely about process development. The theory is simple: if you fully understand the process, and document it well, you can create a “black box” into which you dump raw material, and out the other end will come finished, quality products. A product can be a fully trained flight control team. It can be a mission. It can be a new simulator. As far as management is concerned, the job becomes one of feeding the appropriate stock into the black box and making sure the box keeps running. Those managing the box no longer need to know or care about what is going on inside the box. It is far easier to manage than to create—and creation is what is going on inside the box. Humans tend to want to take the easy path.
The problem with this, of course, is that the easy path rarely, if ever, gets you anywhere. The truly creative people who advance an organization or field are, unfortunately, limited in number. We like to think that everyone we hired had the capability to be a star, but sadly, not everyone does. It is a subset of the employee population who can come up with new ideas and lead the way. The rest “feed the box.” But when the focus ends up on the box itself, rather than on what actually goes on inside the box, the creative people are left out of the day-to-day operation. As a result nothing new gets done. Nothing new gets created. And the organization stagnates. If the box doesn’t work, the organization no longer has the people who know enough about how it works to fix it or make it better. Attempts at process improvement fail, with thousands of man-hours spent for nothing—because it takes creative people to make it better, and those creative people need to be focused on the product, not the process.
I saw this almost every day in the last decade (or more) of my NASA career in our operational training organization. We spent a huge amount of time in defining the training process, and that time was being spent by our senior people who could just as well have been using their time and technical expertise to actually train folks. The overhead associated with process development was enormous, and the resulting training products just weren’t that good. In the end, we were not in a mass production business; we were a boutique shop, and we didn’t exist to produce millions of computers or cell phones, or cars. Our business was to make custom units, each one different, each one needing to be adaptable to changing situations. We needed to look at organizational models that emphasized this and then use our experienced people to actually conduct the technical training—not just build boxes that don’t seem to be very effective. As I left the agency, these needs were being examined—a sign that organizations can at least be introspective enough to realize that they might need to be fixed.
The Need for Mentors
With very few exceptions, flight controllers are made, not born. In order for an engineer to become a flight controller, they need some form of instruction. In particular they need active participation in their development by senior, accomplished instructors who have “been there and done that.” In the aviation world, the good instructors are older, seasoned, experienced pilots who pass on not just the physical skills of flying but also the lessons of many thousands of hours that help to build good judgment. At the highest levels of airline training, instructors are frequently pilots who have popped off the top of the stack due to the mandatory retirement age or a medical issue. These experts continue to earn their living in aviation by providing training for the next generation. It’s a progression that sits in contrast with MOD’s interesting history of staffing the training division with the newest, least experienced, fresh-out-of-school folks who—while full of good intent and energy—have no idea how to teach flight control skills b
ecause they had never been a flight controller.
To be fair, the training organization grew out of a need to train astronauts, not flight controllers. In the earliest days of human spaceflight, the crew was involved in defining their own training needs. The engineers followed along, supporting those needs with training devices, simulators, and classes. Flight controllers took care of training themselves since they were the ones developing the equipment and techniques to fly the missions. As programs, systems, and operations became more complex, the training organization grew such that it began providing integrated training for everyone involved in the operation. But it never really absorbed flight controllers who could teach the necessary basic skills needed by young, developing controllers. So we ended up with the excited new folks who had come to learn the systems and transfer that knowledge to flight crewmembers, but who were out of their depth when trying to teach the subtleties of flight control to engineers who had more experience than they had.
Over the years, MOD codified the values and standards that we expected flight controllers to meet, but we were less than successful at actively teaching these to every candidate who came along. Only by giving clear examples to follow, and actively helping new students practice and iterate on these skills, could we eventually produce the quality of individual that we expected to be sitting on console. This process takes time, and it is hard to make the time shorter because console expertise is not easily quantifiable. Using experienced instructors (which means senior flight controllers or Flight Directors in an active, instructional role) to conduct this training is necessary but expensive. The right people are few and it is hard to spread them around. As a result, there was the high number of failed certification attempts for FCR flight controllers. Although students had gone through the prescribed number of training exercises, something was missing in what they actually learned, and they failed to meet the standards set by the ultimate authority—the Flight Director Office. Time and again, failures were not associated with a lack of systems knowledge, but rather with communication and teamwork skills—things that must be learned with experience.
One of the ways in which this experience had been obtained (in the past) was through Multipurpose Support Room (MPSR) experience. Not only did this give the FCR operator a chance to actively teach the skills needed for the advancement of the trainee while they were in the back room, it also gave the observant trainee a chance to see those skills being exercised (successfully or poorly) by other flight controllers. It is not uncommon to find that more can be learned by watching than by doing, and while this is not always true, there is much to be gained by watching another person succeed—or fail. If nothing else, seeing a poor performance and the resulting critique helps people make more of an effort not to find themselves in the same situation. This MPSR experience was never explicitly identified as a significant contributor to the later success of a flight controller; rather, MPSRs were seen as a necessary evil in order to provide support in a discipline with too much going on for one person to handle.
Unfortunately, one of the results of making flight control operations more efficient was the thinning down of flight control teams. For some disciplines this meant the elimination of the MPSR altogether. The front room flight controller was all there was. This meant that a new flight controller had to start out totally exposed to the big organization. Unable to shelter behind their FCR operator for the early part of their career, they did not have the opportunity to observe how things worked from a position of relative anonymity and safety. The mistakes they made were in the public forum. One way the organization tried to handle this was to create a sub-tier of integrated training, held off-line in miniature control rooms, using training organization instructors to play the roles of crewmembers as well as instructors. Unfortunately, this still didn’t give the new flight controllers a real playground in which to mature their skills because the experienced operators were too busy flying the actual mission to spend much time in these sessions. So when the young flight controllers were exposed to the world of real integrated sims, they suffered poor pass rates on evaluations.
Training costs time, and that means money. But without proper training you end up with an organization of people who don’t have the tools and experience to do the job. Money and time spent up front, early on in a person’s career, pays dividends later. It is shortsighted for any organization to forgo that up-front investment.
Expert Leadership
One thing that was almost universally true in the old days of Flight Operations (which begat Mission Operations) was that the Section Heads and Branch Chiefs (and Division Chiefs for that matter) had all been experts in the type of work that their organizations performed. Group Leads in the Systems Division had been FCR systems flight controllers. Group Leads in Flight Dynamics had been Flight Dynamics Officers. Section Heads in the training organization had been senior instructors or Sim Sups. Now it is true that folks moved between disciplines, so that the Data Processing Systems Section Head might have been a Propulsion Systems Officer (although more often than not, the promotion was within a discipline). Nevertheless, the Section Heads were all expert flight controllers, and they could accurately judge the skill levels of their workers because they had been in those trenches themselves.
In the latter-day MOD, we had numerous people in leadership positions who had never sat on console—or at least who never did it successfully at a high level. We sometimes had people passing judgment on certification issues when the skills they were examining had never been examined in themselves. I believe that this was one of the primary reasons why we had a dismal “pass” rate on certifications for some FCR positions later in the program—people were not well prepared for their cert runs because the people responsible for getting them ready didn’t really have the skills themselves. This was not universally true, of course—we had many group leads and senior managers who were expert flight controllers, and it showed. But we had a lot of less-experienced managers, and their results showed it as well.
The Marines have a tradition that everyone starts out as a rifleman. In a war situation, every Marine is therefore still a rifleman—from the private up to the general in the theater. Everyone is expected to fight if the need arises. I believe that Mission Control was a stronger organization with a better reputation when we were closer to that model. I believe that we needed to try harder to fill the leadership positions with people who had the experience that we expected from their followers. MOD drifted too far from the ideal and needed to correct its course back toward those who had proven that they understood what went on in real-time operations. Workers will always have a greater respect for management when an organization does that. Consequently, morale—and dedication to the mission—will be measurably higher.
The Role of Engineering in Real-Time Operations
Manned Space Flight Operations began with a small team of folks working out of the Langley Research Center. This team was responsible for the creation of the idea of manned spaceflight in the United States. It all started with folks who wanted to send people in space. They needed hardware to do it and they were able to outline what they needed—but then those hardware requirements were handed over to the design engineers to build. (At least that is the ops-side view of things. Like physicists arguing with mathematicians over who is actually supporting whom, the engineering side will say that they dreamed up the concept and simply “hired” the ops guys to fly them. Neither side is wrong.)
The operations team really began by coming up with a flight plan for the Mercury missions—what it was that they were going to do—from the first ballistic lobs through to the all-day orbital missions. In order to support the missions from the ground, they had to create the tracking network that allowed the maximum amount of command and telemetry. (Dr. Christopher Kraft, the first NASA Flight Director, once told us that the initial Mercury tracking stations were situated where they were so that the ground could talk to the crew about every fifteen minutes bec
ause, in the days before radar coverage, that was how often pilots of that era had to check in with air traffic control.) They also needed to create the tools and ground systems to look at the data, generate the commands, communicate between stations, and compute trajectories. This all turned into the organization called Mission Control.
The Engineering Directorate and the contractors who built the hardware always provided the engineering support, but these folks lived in a different world from the Operations team. The Operations team constantly trained with the clocks running—they learned to operate at the speed of flight. They couldn’t stand down to consider a problem; they needed the best answer they could generate in a short period of time. Engineering was (rightfully) used to taking the time necessary to do a complete analysis, a luxury that Operations didn’t have. So Operations developed a culture of knowing as much as they could while extrapolating beyond the “known” to make the most educated decisions possible. This is an entirely different technical discipline than design engineering. The Mission Evaluation Room (MER) function is, obviously, vitally important to the real-time team, but it needs to be remembered that the real-time team was created for a reason.
There is nothing bad whatsoever about the engineering organization’s approach to what they do; it is simply different than what is required in operations. In a similar way, the launch control team at the Kennedy Space Center had a different job. While they did have to deal with quick and precise timing, they could almost always go into a hold if things weren’t exactly right. The vehicle was still bolted firmly to the earth, after all. Their job was to safe the situation, then talk about what to do next. It’s not better, or worse—it’s just different… and you need different cultures to do different things.