The NASA pirates that transformed mission control

We often look on renegades and rebels as troublemakers, individuals who have to get with the programme so that the organisation can be aligned.

Our research at NASA’s Johnson Space Center, however, suggests that we need renegades more than we think. Far from disruptive, they can be a powerful means of shifting organisations towards new futures.

When the young engineer John Muratore joined the Johnson Space Center in 1983 after four years in the Air Force Space Shuttle Program, he was surprised to see that the computer architecture in operation in the Shuttle mission control center was still the Apollo-era mainframe system.

Displays were monochrome, lacked graphics, and the system could handle only a limited number of simultaneous calculations otherwise it could be overwhelmed. Any changes in functionality could take months to implement.

Muratore wondered whether the incumbent mainframe system could stand up to the burgeoning mission demands and complexity of the Shuttle programme, not to mention the mission control needs of the planned International Space Station.

He believed that a distributed system, based on a cluster of Unix-based off-the-shelf personal computers recently made available in the market, could potentially offer greater functionality, graphics, scalability, robustness, and a truly real-time interface. Expert systems, an early form of artificial intelligence, could then be deployed on such a system and could give flight controllers greater diagnostic and fast response capabilities.

In 1986, in the wake of the Challenger accident, Muratore’s concern morphed to a strong desire to do something to elevate the capabilities of mission control so as to respond to mission demands growing in scope and complexity.

Progressive budget cuts after the Apollo landings meant that the agency had to find ways to deal with these demands with ever decreasing resources. Muratore connected with a small group of newly recruited engineers who he realised felt the same about the incumbent system.

Many were in fact surprised when they arrived at NASA to find that the technology of the agency’s mission control was not as advanced as the computer systems of their sometimes modest alma maters. This small group of renegades wanted to future-proof mission control by using an open, upgradable and scalable systems architecture that could potentially incorporate not invented yet future technologies.

The group’s concerns initially fell on deaf ears. The feeling in mission control was that the incumbent system had taken humans to the moon; it was highly tailored, tried and tested, and flight controllers and software engineers knew its every quirk. If there was any life-threatening emergency, nobody wanted to have to deal with a new, untested system. The Apollo-era mission control room was a living symbol of one of humanity’s greatest accomplishments and fostered intense emotional attachment.

But Muratore and his cohorts were undeterred. They decided to apply for a small internal grant for “new technology”, and with those meagre funds they started putting together borrowed hardware and writing new code, to create a mission control system that could initially run parallel to the incumbent system.

Muratore and his renegades had to write code on borrowed hardware that they could only keep for 90 to 120-day cycles (that’s how long they could borrow free computers from NASA suppliers, according to government rules). They would work in their lunch hour, evenings and weekends.

After about a year they took their system, composed of clusters of off-the-shelf hardware and their tailor-made code, into mission control in a vacant part of the room. The flight controllers made it clear that they did not want them there, at which point the legendary flight director Eugene Kranz, who understood what the renegades were trying to accomplish, came out of his office and asked the flight controllers to give the kids a chance.

The renegades were allowed to position their system in the control room and slowly it started to demonstrate its worth as it continued to run seamlessly on two separate occasions when the mainframe crashed. At any time, the flight controllers could glance over at the new system and see color graphics, integrated reports on the status of Shuttle systems, and user-friendly interfaces.

They realised that they could make faster and more accurate decisions with the new system, than when having to interpret the shapeless rows of monochrome numbers on their own screens. Over time, the various technical systems that were required to fly the Shuttle were transitioned from the mainframe system to the Unix-based computer cluster.

The Pirates are born

Over time, Muratore thought that his ragtag renegade group needed an identity, so the “Pirates” were born. The group created its own symbology; logos, posters, t-shirts, mugs, and other group symbols, and regularly communicated face-to-face in “all-hands” meetings as well as spur-of-the-moment gatherings. 

Their “Pirate paradigm" consisted of several values that challenged the established culture, such as: “Do not wait to be told to do something, figure it out for yourself; challenge everything, and steel yourself for the inevitable cynicism, opposition, rumors, false reporting, innuendos, and slander; break the rules, not the law; take risks as a rule not as the exception; cut out unnecessary timelines, schedules, processes, reviews and bureaucracy; just get started, fix problems as you go along; build a product, not an organisation; outsource as much as possible.”

The Pirates were all about achieving results, resilience in the face of challenge and maintaining personal responsibility.

This way of operating was nothing short of a revolution in the procedural, rule-bound, hierarchical culture of the agency. It was seen as an intrusion that angered many, who wanted to see the Pirates fail.

The Pirates faced fierce opposition from the established order, including middle management. The software developers group, for example, the flight operator felt that the Pirates, by writing their own code, were encroaching on the developers’ domain.

A presentation at the time by Muratore on real-time data acquisition for expert systems noted: “Technology transfer is a body contact sport. Rough and tumble between operators and developers. Do not try if you are not prepared to get bruised (ego or physically).”

At the same time, a small number of “greybeards”, established and experienced NASA scientists and managers, realised that what the Pirates wanted to accomplish was instrumental for the future of the agency. The Pirates slowly won the quiet support of individuals such as Eugene Kranz, and his lieutenants; and George Abbey, the Johnson Space Center administrator at the time. Some greybeards made a habit of hanging around the Pirates, sometimes offering advice with the benefit of their decades of experience.

In 1992, after the successful transition of the Shuttle control system, the Pirates were tasked with developing the capabilities of mission control for the planned International Space Station, whose assembly begun in 1998.

The Pirates’ mission control system operated at lower cost for both the Shuttle and the International Space Station programmes, compared to what it initially cost to run just the Shuttle programme using the Apollo-era mainframe system.

In 1994 the Pirates were awarded the Vice President’s Hammer Award which recognised groups that made outstanding innovations to the functioning of government. The award recognised the Pirates’ development of the new Shuttle mission control with cost savings of US$74 million in development, as well as recurring savings of US$22 million.

Renegades as revitalising forces

We learned about the NASA renegades as part of our research project at the agency’s Johnson Space Center that started in 2013. Over the years we conducted ethnography through long visits to the Center, management workshops, interviewed several of the original Pirates including Muratore, and consulted available NASA oral history interviews and other historical documents.

We realised that the NASA renegades that grew into the Pirate group were pioneers in agile practices even before agility entered the organisational vocabulary; the agile manifesto had not been created till 2001.

The Pirates’ motto of “build a little, test a little, fix a little,” regular short-cycle milestones to encourage continuous improvement and experimentation, results orientation, cutting out bureaucracy, encouraging personal accountability and responsibility, and challenging of convention while operating in a large, rule-bound hierarchical organisation were the essence of agility even before the term became fashionable. 

It took great courage, persistence and commitment for the Pirates to go against the organisation's culture, but it was what NASA needed to be ultimately able to operate the Shuttle programme effectively and to build the International Space Station.

We also realised that this story has important lessons for today’s organisations, particularly with the emergence of digital technologies that are redefining industries and reshaping the bases for competition.

All systems have performance limits that may make them unable to deal with novel challenges. In the 1980s mainframe computing could not deliver the functionality and flexibility that distributed computing could. Currently AI, analytics, and quantum computing can deliver performance leaps that cannot be delivered by incumbent systems.

The performance limits of existing systems can be transcended by new approaches and technologies, rather than by refining the current system, as for example the progression of communication via firstly the pony express, then the telegraph, the facsimile, and currently email demonstrates.

New approaches, however, are often resisted and suppressed by the established order and dominant interests, and discouraged by organisational inertia and the urgency of everyday fire-fighting.

This is when “positive deviants" such as the NASA Pirates come in. These are individuals and groups who are embedded in operations, understand looming challenges, and have the expertise, motivation and vision to seek and create a better way to deal with these challenges.

They are the “troublemakers” who end up bringing essential competencies to the organisation. Several organisations can attest to the value of renegade groups. IBM’s move to the internet, Lockheed Martin’s Skunkworks, and Apple’s Macintosh team were all led by such groups.

What should organisations do to foster the emergence of positive deviants? Many organisations focus on strategic and organisational alignment, expecting everyone to tow the line and pouncing on any signs of deviation from the norm.

Tight alignment and homogeneity can foster efficiency and optimisation, but also have inherent risks. Namely, they do not allow for system evolution (or revolution for that matter). Darwinian natural selection does not only occur within the market; it also takes place inside the organisation. Without deviation within, there can be no selection of new operating models or retention of these models. Organisations, therefore, have to foster sufficient diversity so they can find or develop solutions to deal with novel challenges.

Troublemakers and renegades can hold the key to step improvements. Companies that think they can get there simply through strategic and organisational alignment, without nurturing constructive dissent, may be in for a rude shock.

Organisations can foster renegade groups by being open to constructive dissent and ideally making available some seed funding (or ways to obtain it) as well as time for these groups to pursue their objectives. This kind of context can help to amplify constructive deviance rather than suppress it.

Further, such groups need to be protected from the organisational immune system, from outright hostility from the established order, by connecting them with high level sponsors who understand the value of the search for new ways.

The changes that can occur with this approach are not just incremental. The history of renegade groups shows otherwise; transformational changes to established systems can be accomplished because these groups are embedded in, and function at the heart of existing operations, with the intrinsic motivation to make a difference.

The effects of renegade groups start in a small, piecemeal way, and they gradually expand to encompass more and more territory. The NASA Pirates officially disbanded in 2002, but their effects reverberate. They took their ways of operating with them across the organisation, with several former Pirates now in leading positions across the agency.