By Edward Ingraham
I began working with Stanford University, the Gravity Probe B (GP-B) prime contractor, in 1993 and worked full time at the contractor’s facilities from 1997 to 2005. When I first visited Stanford, the GP-B team was working in a classic laboratory research environment. The team was brilliant to watch as they came up with solutions to the many technical issues they faced. They were not afraid to challenge each other on even minor technical issues. In one of my first meetings, I watched co-investigators argue about whether the atomic number of niobium was 92.90638 or 92.90637. I didn’t know the fifth decimal point of the atomic number of niobium off the top of my head! How was I to add value to this incredibly smart bunch of scientists and engineers? It turns out there were some useful things that I did know. To successfully launch GP-B, I knew that one day this team of academic researchers needed to create an aerospace infrastructure to perform the tasks that awaited them. We started pulling in the reins to convert GP-B from a research project to a flight program—not all at once but by introducing continuous, systematic improvements at a pace that allowed the majority of the workforce to adapt. Changing how a team works isn’t easy, especially if you need to maintain their trust and cooperation while doing it. Here are some important approaches.
Learn and Teach
Stanford engineer Ken Bower inspects the Gravity Probe B fused-quartz block, which houses the four fused-quartz gyroscopes.
Photo Credit: Stanford University/Russ Leese
Initially I worked to become part of the team. I got beyond the review meetings to where the real work was going on. It was important to spend some energy becoming part of the team and proving my value. All new leaders or team members must do this to be effective. I think we all need to earn the right to be part of a team regardless of what our official roles and responsibilities are. Humans are social creatures and team dynamics play an important role in one’s effectiveness. Initially engaging others in what they do, listening more than talking, and helping others accomplish their tasks are all great ways to earn the right to influence the process. For the customer at a contractor’s facility, this is also a great way to gain in-depth knowledge of existing processes. It’s difficult to really understand what is broken without rolling up your shirtsleeves and doing some of the work yourself. You learn where the processes are breaking down.
When Stanford said it didn’t have the resources or expertise to train its people, I worked with the team to devise a process to build flight hardware on campus and brought in other NASA personnel to help train and certify key members of its workforce. The training included the nuts and bolts of building and testing flight hardware for NASA, and it was designed specifically for Stanford’s applications. The engineers, technicians, scientists, and managers began to appreciate how everything from purchasing parts, writing test procedures, dispositioning discrepancies, and approving readiness reviews came together logically to demonstrate that their subsystems, systems, and eventually their spacecraft were ready to fly. The training gave team members a common understanding of how they needed to operate and demonstrated that NASA and the contractor were on the same team.
Manage Change Thoughtfully
To be an effective project manager, you must see your role as the one in charge of understanding and monitoring all interfaces, whether subsystem to subsystem or team member to team member. Interfaces require effective communication, whether between electronic boxes or humans. Be on the lookout for key interfaces that span organizational lines and could create a barrier within your team. For example, when I first started, the program had a weak system for process changes. A new, unified Program Change Board (PCB) system was organized at Lockheed Martin, Stanford, and Marshall Space Flight Center to handle all programmatic and technical changes for the program. I worked hard to get that system started and working efficiently. That meant modifying the contract to include NASA representation at the contractor’s level, which was key to coordinating all levels of the decision process. It gave everyone involved clear insight into what was going on. In the end, more than 675 changes were effectively processed.
Find Common Ground
When I came into the program in the early nineties, the challenge was not just to integrate flight subsystems but also to integrate NASA, Stanford University, and Lockheed Martin—organizations with three very different mind-sets. To see the other teams as collaborators instead of competitors, team members needed to understand each other’s challenges and adjust their ways of thinking.
When a large number of NASA engineers joined GP-B a couple of years before launch, the contractor team—which already felt overworked—resented spending what seemed like more time replying to NASA engineers’ questions than working on the project. NASA engineers, for their part, were not used to having only limited access to the contractor. Both sides were frustrated. We worked on getting them to see each other’s points of view and looked for solutions to the conflict. The contractor hired additional personnel. NASA changed its priority and emphasis to a risk-based management system. This served to substantially reduce questions about some subsystems that posed little or no risk to mission success and allowed concentration on mitigating issues that could threaten mission success. In the end, this compromise produced a solution that served the team and the project well.
Seek Out the “Doers” on Your Team
Sift through the “knowers” and find the “doers” for your project. There is a loose and imperfect relationship between knowing what to do and the ability to act on that knowledge. Many times, people confuse talking about what a group ought to do with actually getting it done. A “doer” is someone you can rely on, for instance, to get a particular system manufactured and tested. We had several “go to” team members who could jump into a difficult situation and succeed. A manager who is a “doer” creates positive change in the team to make it more effective and more able to create a product that fulfills its mission. Concentrating on words rather than turning words into action is the easiest way for managers to fail. One of the biggest mistakes I’ve seen a manager make is believing that just because he or she said something or documented it, it would be done. Do not confuse talking a lot, sounding smart, or using complex rhetoric with “doing.”
Lessons Learned
- First, work to become part of the team. Earn the right to be part of the team through hard work and by demonstrating value as a team member.
- Listen more than you talk. Before making process changes, analyze how and why the team uses its current processes.
- Cover your flank. Ensure that NASA speaks with one voice. Make sure your senior managers are aware of what you’re doing and will back you up.
- Accept ownership of problems. Move past unproductive blaming of others and begin to focus on figuring out what to do about problems.
- Understand and manage the technical and programmatic interfaces.
- Know your contractors’ weaknesses. Help them by finding “doers” in your organization who can come in and help solve problems.
- Look for problems in the dark spots. Problems are usually found in places where others are not looking.
Understand Weaknesses As Well As Strengths
It is important to understand weaknesses in addition to strengths. The brilliance of the GP-B team members was actually both a strength and a weakness. For example, the Gas Management Assembly (GMA) used to hold and pump helium gas into the gyroscopes to spin them up in the beginning of the flight experiment did not get a lot of management attention. While this subsystem was critical to mission success, it was basically a big plumbing system. The best engineers wanted to work on other, flashier subsystems.
Stanford engineer Chris Gray inspects the number-four gyro under monochromatic light after it was removed from the Science Instrument assembly.
Photo Credit: Stanford University/Russ Leese
Responsibility for the GMA shifted among a few development engineers until it ended up on Chris Gray’s lap. Soon thereafter, Chris proposed a series of tests to try to fully understand the performance of the partially built subsystem. Each time Chris came back with test results, they showed an additional problem. It was like putting your finger in a leaking dam and having another leak pop up. I quickly concluded that we’d need a major hardware change for the GMA and Gravity Probe B to succeed. The contractor had a hard time coming to terms with a major change at a late stage in the program.
By this time, the team trusted me enough to accept my offer to fly in a NASA valve expert to help. Within a day, I had the best valve person from Marshall Space Flight Center at the contractor’s facility, and the NASA Program Office was preparing upper management for the schedule and cost impact of the major hardware change that might be necessary. By the time the decision was made to restart the development of the GMA system from scratch, NASA management and the contractor’s team were on board. NASA, Stanford, and the new subcontractor team designed, manufactured, tested, and integrated the new GMA system from scratch in thirteen months, and it worked flawlessly during the mission.
The Importance of Being There
Having NASA engineers and managers reside at contractors’ facilities, if done properly, reduces the risk of hidden problems and adds to the openness, trust, and unity of the entire team. And working day to day with flight hardware at a contractor facility provides training that no course or textbook can match. The time I spent at the contractor facility for the GP-B mission was an incredible journey and an invaluable experience that taught me how NASA should work with a contractor.
For more information on the Gravity Probe B mission, visit http://einstein.stanford.edu.
