Academy Sharing Knowledge

The NASA Source for Project Management and Engineering Excellence | APPEL F A L L | 2 0 0 7

National Aeronautics and Space Administration

Inside

INTERVIEW WITH JOHN MATHER

 LAUNCH LESSONS AT WALLOPS

 THE NEXT-GENERATION WORKFORCE AND PM
O N T H E C O V ER

The Cassini spacecraft surveys Saturn’s outstretched ring system in the infrared from 

a vantage point high above the planet’s northern latitudes. This image was taken at 

a distance of approximately 900,000 miles from Saturn with Cassini’s wide-angle 

camera, using a combination of spectral filters sensitive to wavelengths of infrared light. 

The Cassini-Huygens mission is a cooperative project of NASA, the European Space 

Agency, and the Italian Space Agency. Photo Credit: NASA/JPL/Space Science Institute
19 5

DEPARTMENTS

3

In This Issue 

4 

From the APPEL Director

49

ASK Bookshelf

50

The Knowledge Notebook

52 

ASK Interactive

INSIGHTS

9 

Does a Good Engineer Make 

a Good Project Manager?

BY GEORGE N. ANDREW Even the best 

engineers need to learn new skills before 

they can be effective project managers.

11 

Equations and Lies

BY KARL IAGNEMMA A robotics researcher 

and fiction writer compares creativity in 

science and literature.

19 

Interview with John Mather 

BY DON COHEN The Nobel-prize-winning 

NASA scientist talks about the down-toearth work behind COBE’s discoveries 

about the origin of the universe.

30

The Next-Generation Workforce 

and Project Management

BY DANIEL W. RASMUS Members of the 

millennial generation are bringing new ideas 

of what work means and how to do it to 

NASA and other organizations.

38

Viewpoint: On a Need-Notto-Know Basis

BY WILLIAM H. GERSTENMAIER Too much 

information can be as bad as too little. There 

are ways to reduce what you send and 

spend time on.

STORIES

5

On the Wallops Range

BY CHARLES TUCKER A dedication to 

discovering and applying the lessons 

of experience contributes to launch 

success at Wallops.

14 

The Cassini Resource Exchange

BY RANDII R. WESSEN AND DAVID PORTER 

The teams developing the Cassini mission 

to Saturn used a market-based trading 

system to put resources where they were 

needed most.

25 

Space-to-Space Communications: 

In-House Hardware Development

BY MATTHEW KOHUT Staying on schedule 

is important but sometimes prevents 

project teams from doing essential testing 

and analysis.

34

Apollo: A Young Engineer’s Perspective

BY DAN HOLTSHOUSE The challenges and 

rewards of building the Apollo guidance 

and navigation system.

41

Einstein for Children: 

Learning and Teaching

BY MARC SPIEGEL The experience of a 

performer who teaches schoolchildren about 

relativity suggests strategies for anyone who 

has to explain difficult concepts.

45

Making and Monitoring 

Critical Assumptions

BY HUGH WOODWARD To carry out a 

water-reduction project, the Oxnard team 

continually tested its initial assumptions.

Contents

30

ASK MAGAZINE | 1
The Academy of Program/Project and Engineering Leadership (APPEL) and 

ASK Magazine help NASA managers and project teams accomplish today’s missions 

and meet tomorrow’s challenges by sponsoring knowledge-sharing events and 

publications, providing performance enhancement services and tools, supporting 

career development programs, and creating opportunities for project management 

and engineering collaboration with universities, professional associations, industry 

partners, and other government agencies.

ASK Magazine grew out of the previous academy, the Academy of Program/Project 

Leadership, and its Knowledge Sharing Initiative, designed for program/project 

managers to share best practices and lessons learned with fellow practitioners across 

the Agency. Reflecting APPEL’s new responsibility for engineering development 

and the challenges of NASA’s new mission, ASK includes articles that explore 

engineering achievements as well as insight into broader issues of organizational 

knowledge, learning, and collaboration. We at APPEL Knowledge Sharing believe 

that stories recounting the real-life experiences of practitioners communicate 

important practical wisdom. By telling their stories, NASA managers, scientists, and 

engineers share valuable experience-based knowledge and foster a community of 

reflective practitioners. The stories that appear in ASK are written by the “best of 

the best” project managers and engineers, primarily from NASA, but also from other 

government agencies, academia, and industry. Who better than a project manager or 

engineer to help a colleague address a critical issue on a project? Big projects, small 

projects—they’re all here in ASK.

You can help ASK provide the stories you need and want by letting our editors know 

what you think about what you read here and by sharing your own stories. To submit 

stories or ask questions about editorial policy, contact Don Cohen, Managing Editor, 

doncohen@rcn.com, 781-860-5270.

For inquiries about APPEL Knowledge Sharing programs and products, please contact 

the Knowledge Sharing Project Manager, Rosie Robinson, ASRC Management Services, 

6303 Ivy Lane, Suite 130, Greenbelt, MD 20770; rosie.robinson@asrcms.com; 

301-837-9067. 

To subscribe to ASK, please send your full name and preferred mailing address 

(including mail stop, if applicable) to ASKmagazine@asrcms.com.

Staff

APPEL DIRECTOR AND PUBLISHER

Dr. Edward Hoffman

ehoffman@nasa.gov

EDITOR-IN-CHIEF

Laurence Prusak

lprusak@msn.com

MANAGING EDITOR

Don Cohen

doncohen@rcn.com

EDITOR

Kerry Ellis

kerry.ellis@asrcms.com

KNOWLEDGE SHARING MANAGER

Rosie Robinson

rosie.robinson@asrcms.com

KNOWLEDGE SHARING ANALYSTS

Ben Bruneau

ben.bruneau@asrcms.com

Johanna Schultz

johanna.schultz@asrcms.com

Katherine Thomas

katherine.thomas@asrcms.com

APPEL PROGRAM MANAGER

Jon Boyle

jon.boyle@asrcms.com

DESIGN

Hirshorn Zuckerman 

Design Group, Inc.

www.hzdg.com

SENIOR PRINTING SPECIALIST

Dave Dixon

david.a.dixon@nasa.gov

PRINTING

GraphTec

Issue No. 28
Most NASA missions have majestic goals. The Apollo 

program that put men on the moon, the rover landings on 

Mars, flights to the outer planets, and the space telescopes 

and other instruments revealing truths about distant galaxies 

and the origin of the universe are tributes to the ambition, 

curiosity, and resourcefulness of generations of scientists 

and engineers. NASA’s history is in part the story of men 

and women who have had an extraordinary ability to imagine 

new questions and invent ways of answering them.

The robotics researcher and fiction writer Karl Iagnemma 

(“Equations and Lies”) writes about the fundamental mystery 

of the kind of creativity that comes up with a problem or 

perspective no one has thought of before. He goes on to 

detail some of the long, hard work required to turn that 

flash of inspiration into the reality of a functional robot or 

convincing piece of fiction.

A lot of what we do at NASA consists of that kind of hard 

work: the endless hours of design, review, manufacture, 

and testing, all the painstaking nuts-and-bolts tasks that 

lie behind that photograph of Saturn’s rings or the ability of 

Spirit and Opportunity to roll across the surface of Mars. 

Many of the articles in this issue of ASK focus on the often 

unglamorous work on which the success of glamorous 

projects depends. In the interview, for instance, John 

Mather talks about the endless hours of discussion between 

scientists and engineers to devise instruments that could 

measure subtle variations in the background radiation of the 

universe and be possible to build, and about the importance 

of knowing how to run productive meetings. “On the Wallops 

Range,” by Charles Tucker, describes the almost fanatical 

pursuit and application of the lessons of experience to 

ensure successful launches. Wessen and Porter’s “The 

Cassini Resource Exchange” explains a novel method for 

distributing project resources. Several articles (“Spaceto-Space Communications,” “Apollo: A Young Engineer’s 

Perspective,” “Making and Monitoring Critical Assumptions”) 

illustrate the importance of thorough testing—of hardware, 

software, and the assumptions that shape and guide 

projects. The fact that the Project Management Institute 

has recognized NASA as one of twenty-five outstanding 

organizations in project management (see “ASK Interactive”) 

is another indication of the Agency’s ability to do the downto-earth work space exploration requires.

As Dan Holtshouse’s Apollo article also makes clear, 

successful projects maintain a vivid sense of the connection 

between all the daily, demanding, meticulous labor and the 

grand, dramatic goals. It was being continually aware of the 

fact that they were building something on which the lives 

of astronauts and the pride of the country depended that 

made it possible for them to work those many exhausting 

hours and devise test after test to make certain this new 

technology would work. Mather, too, notes that the COBE 

team cheerfully worked long hours in part because “they 

knew they were doing something important.” Certainly one of 

the critical jobs of the successful project manager is to keep 

people from losing sight of the grand goal as they struggle 

with the complexity and frustrations and even sometimes 

the tediousness of their daily work.

This is part of what Ed Hoffman is talking about (“From 

the APPEL Director”) when he notes that teams can get 

in trouble by focusing too much on a narrowly defined set 

of project milestones. He emphasizes the importance of 

relating all project activities to the organization’s overall 

strategy—that is, to the inspiring larger goals that justify all 

that hard work.

Don Cohen

Managing Editor

In This Issue

ASK MAGAZINE | 3
One issue has emerged as a common concern in 

my recent discussions with project practitioners 

representing a broad cross-section of public and 

private sector interests around the world. Are 

project failures increasing? Is some vital component 

of good project execution missing? This concern 

is not surprising. It is reinforced by the Katrina 

tragedy, by failed Iraq War construction projects, 

by falling debris hitting cars in the Boston Big 

Dig, and by delays in fulfilling orders for the new 

Airbus super jumbo jet. 

American project managers in particular possess 

a reputation for getting it done, and rightfully so. 

After all, our know-how and technology got us to 

the moon and back several times. They will get 

us back to the moon, permanently this time, and 

then on to Mars and beyond. But recent failures 

raise nagging questions about why so many project 

teams have not succeeded.

This is not to say failures cannot eventually 

become huge successes. We forget the flawed 

mirror in the Hubble when we marvel at the 

magnificent images of our wondrous universe 

it produces. Our memories of the first buggy 

Internet Explorer browser fade when we use the 

current fabulous multimedia-capable version of 

the software. The best teacher is failure, if the right 

lessons are captured and absorbed by individuals 

and organizations. But I wonder if the current 

publicized project failures could cluster around 

some powerful issues that are often neglected?

Of course, there are some well-known 

components of successful execution, including 

accurate requirements, good planning, risk 

management, adequate resources, and talented and 

committed personnel. But I think there are other 

critical conditions for project success that are seldom 

acknowledged and therefore rarely attained.

First, projects need to be intricately and 

actively tied to the organization’s overall strategy 

and reviewed and debated frequently by leaders and 

practitioners to assess their relevance. Too often, 

projects operate in isolation, focused on a narrowly 

defined set of milestones that ultimately fail to 

connect with interrelated activities and objectives. 

As a result, they neither support nor benefit from 

that wider context. Second, the execution of 

required activities and processes often falls short 

of what is needed. Lack of clarity about objectives, 

specified activities, and accountability means that 

the focus on executing the organizational strategy 

will eventually diminish, even though everybody 

is working long and hard hours. Finally, open 

communication and transparency are critical 

for project success, sustaining commitment and 

follow-through by practitioners who truly embrace 

the goals. 

One reason I continue to believe in our efforts 

at ASK Magazine is that they allow practitioners 

to communicate project knowledge across diverse 

organizations and help to connect project teams 

with the broader organizational context.

One more point: As I continue to talk to 

practitioners and visit a wide range of projects in 

many organizations, I’m more and more convinced 

that good leadership is a non-negotiable component 

of success. Only excellent leaders can ensure that 

the issues I’ve raised are effectively addressed. ●

From the APPEL Director

Getting Results in a Project World

BY ED HOFFMAN 

4 | ASK MAGAZINE
The TacSat-2 launches from Wallops Flight Facility.

BY CHARLES TUCKER

“I tell people I’m a true geek,” Jay Pittman 

says, laughing. He’s driving on a two-lane strip 

of blacktop flanked by summer-green crops, 

heading seven miles southeast from the main 

base of Wallops Flight Facility toward a tiny 

barrier island off Virginia’s Eastern Shore, where 

the Wallops launch and research range stretches 

along a sandy strand of the Atlantic Ocean. 

ON THE

WALLOPS RANGE:

A Geek’s Guide to 

Lessons Learned

Photo Credit: NASA

STORY | ASK MAGAZINE | 5
“I’m a computer science mathematician,” he adds, by way of 

explanation.

Pittman is also chief of the Wallops Range and Mission 

Management Office. Before taking that job in January 2002, 

he ran a systems software engineering group in the engineering 

directorate of Goddard Space Flight Center, where he led teams 

of civil servants and contractors providing “end-to-end” software 

services to Wallops missions. 

“That was exciting!” he exclaims, as if to reinforce his selfdescribed geekiness. 

But if Pittman gets jazzed reminiscing about software 

engineering, it’s nothing on the order of his enthusiasm for his 

current post. “Honestly, this is the best job in the whole world,” 

he says. 

How did a computer geek end up doing rocket stuff? The 

“end to end” comment tips his hand. “Even as far back as 

college”—he’s a Virginia Tech alum—“I really didn’t care that 

much about the software itself. What I really enjoyed was the 

process.” The getting there, from one end to the other. 

Across the past six decades, Wallops—the only launch 

range owned by NASA—has been the site of more than 16,000 

launches, from sounding rockets and balloons to orbital launches. 

By virtue of the facility’s small size, nimble and low-cost 

operations, and, to use Pittman’s term, “super-responsiveness,” 

the process is unique. 

In one six-month span, from December 16, 2006, to 

April 24, 2007, the Mid-Atlantic Regional Spaceport, Pad 0B,

at Wallops Island was the site of two orbital launches. 

Both the TacSat-2 (Tactical Satellite-2) and NFIRE (NearField Infrared Experiment) missions were launched on Air 

Force Minotaur I rockets—TacSat for the Air Force Research 

Laboratory, NFIRE for the Missile Defense Agency. Both 

launched on schedule to the second. 

Their success hinged on the ability of the project teams to 

get the missions off the ground quickly: seventy-two days for 

TacSat-2 from the time of delivery of launch vehicle; forty-nine 

days for NFIRE. Achieving that quick turnaround depended on 

an apparently paradoxical type of project management—tight 

supervision and democratic participation—in a style that suits 

Wallops’s soup-to-nuts approach.

“Almost all our projects are concept to launch—end-to-end 

projects,” Pittman says. “It’s an extremely dynamic process.” 

Which makes the range chief and the range a perfect fit. “That’s 

one of the best things about this job: the opportunity to sort of 

sit in the midst of these project managers, to be responsible not 

only for watching over these projects as they get to completion 

but then, at the end of a mission, to get back in and sort of push 

out all the experiences to the other project managers in such a 

way that everybody gets better.”

For Pittman—the man managing the mission managers—

the process is everything. Following a successful launch, it starts 

immediately all over again with the lessons learned from the 

mission that just concluded. From Pittman’s perspective, the 

success of the first Minotaur launch was “really only complete 

when we did it again with NFIRE. The lessons learned from 

TacSat-2 were a big part of the success of the follow-on mission. 

We kept those in front of us the whole time,” leading up to the 

second Minotaur launch four months later.

Befitting a computer science mathematician, Pittman takes 

a pragmatic, stepwise approach to the problem of converting 

lessons learned from a static collection task to a dynamic activity. 

He’s clear-eyed about the purpose of the process. And when he 

talks about lessons learned, he becomes animated, drawing out 

words for emphasis, in his native Virginian drawl.

“The key thing about lessons learned is that you have to put 

them in a context where they are visible and actionable. They 

can’t feel like a beating. And they can’t be so wispy as to be 

ignored. That’s the magic.

“If you think about all the reviews we do at Wallops, when 

we do a launch readiness review we generally have the same 

agenda whether we’re doing a Minotaur or a sounding rocket 

or whatever. It’s all the same stuff; it’s just a question of scale. 

WE GOT COMPLIMENTS FROM OUR EXTERNAL REVIEW PARTY ... AND SOMETHING 

ELSE—THERE WAS A CONSTANT REFERENCE TO LESSONS LEARNED FROM PAST 

MISSIONS AS WELL.

6 | ASK MAGAZINE
In fact, we do exactly what Vandenberg does, exactly what 

the Eastern Range [Cape Canaveral] and everybody else does. 

What we do for lessons learned is, we categorize the lessons and 

actually stick them in a bucket that corresponds directly to a 

topic that has to be addressed at the major reviews. And we 

put that in the hands of the project managers—and also in the 

hands of the reviewers. 

“So our review panel for TacSat-2 came in not only with the 

materials that they were going to review, but with very specific

lessons learned about each one of the areas. And what happens 

is, there begins to be a dynamic between the project managers 

and the review panelists. So just by allocating lessons learned 

in this way, we ensure a personal dynamic is going to occur 

between the manager and the panel.”

But that’s just the beginning, says Pittman. 

“There are ripples to this that are even more important,” 

he continues, “because that’s just how we get it through the 

review—and how you get it through the review is nothing 

compared to what you really need to be doing to do the work. 

Now we’ve created a process where the project team says, ‘Geez, 

why are you doing it this way?’ and the project manager says, 

‘Well, I knew you were going to ask this. I don’t want to see us 

not learn this lesson.’ So now the project team members start 

to anticipate that the project managers are sensitized to these 

things, and they start doing them.

“That’s the theme. That’s the process. We’ve become 

almost obsessed with this idea that we’re going to proceduralize 

everything.”

To make the magic work—to really make it “actionable”—

the trick is to make the lessons learned applicable.

“The real problem,” says Pittman, “is crunching down the 

relevant stuff and putting it in front of people and making it 

relevant to their jobs. When you do it like this, you have just 

vast re-use of best practices. And people become very sensitized 

to things that didn’t work, and the next time they say, ‘We’re 

never doing that again!’ You’ve sort of made it a stepping stone 

on a path that they normally walk.

“And when you do that, then you’ve achieved something.”

In his office back at the Wallops main base, Pittman 

scrolls through screen after computer screen of lessons learned 

inputs and reports for the TacSat-2 mission. The culmination 

of all this information is, among other materials, a 225-

page presentation-style compendium of lessons learned. The 

document begins with a bar-chart summary of findings in 

nearly forty categories, from testing and countdown to range 

instrumentation, through mishap plan, budget, decision 

authority, and ground systems to safety, security, requirements, 

facilities, waivers, and so on. It includes both a summary of 

THAT’S ONE OF THE BEST THINGS 

ABOUT THIS JOB ... TO BE RESPONSIBLE 

NOT ONLY FOR WATCHING OVER THESE 

PROJECTS AS THEY GET TO COMPLETION 

BUT THEN, AT THE END OF A MISSION, 

TO GET BACK IN AND SORT OF PUSH OUT 

ALL THE EXPERIENCES TO THE OTHER 

PROJECT MANAGERS IN SUCH A WAY 

THAT EVERYBODY GETS BETTER.

ASK MAGAZINE | 7
major trends and a detailed report for each of the categories. 

Each detailed report in turn has a lesson statement, an impact 

statement, a recommended action, and a response from the 

range and mission management office.

“Look at this!” Pittman says, staring intently at the screen. 

“We even learned stuff about waivers. There’s one waiver process 

that was so broken that we finished TacSat, and the day after 

we started the waiver process for NFIRE because it was just so 

whacked. Here’s the data behind all that.

“Or look at this. We didn’t have a good line of sight to the 

launchpad. It was obscured. So we put that into a category that 

would be applied to a review and recommended actions, then 

the team turned it into actions and we fixed the problem [for the 

NFIRE launch]. In fact, most of these were fixed sitting right 

here, when I’d call somebody in and say, ‘Apply some of your 

budget to fixing that problem.’ And it goes away. Ultimately, 

there were more than 200 of these that we then rolled into about 

fifty overall lessons.”

In all this enthusiasm for the process, it’s clear that Pittman 

takes particular pleasure in the democratic inclusiveness of the 

procedure: “We pride ourselves on the fact that we get lessons 

learned from everywhere. We get them from radar operators 

and security guards—those are the people who tell us, ‘You 

know what, you guys, this looked good in the review but it 

didn’t work on launch.’ And then we had to do this and that 

and the other thing. 

“We took the [TacSat-2] launch team, put them in a room, 

and looked at how many lessons we got from the team. Are 

there any groups of people that we got no lessons from? Surely it 

wasn’t perfect in Security—where are our inputs from Security? 

And right on down the line.”

Transparent. Relevant and applicable. Not wispy, but 

not burdensome. On the Wallops range, the magic of lessons 

learned works. “On NFIRE,” Pittman says with some pride, 

“we got compliments from our external review party about the 

constant reference in the second mission to the TacSat lessons 

learned. And something else—there was a constant reference 

to lessons learned from past missions as well. A lot of what we 

did on NFIRE and TacSat, we did because we knew it to be the 

right thing for a sounding rocket.”

Now Pittman is off and running. With thousands of 

Wallops missions as a reference point, the Range and Mission 

Management Office chief is just warming up to the subject. ●

CHARLES TUCKER works with Dr. Edward W. Rogers, chief 

knowledge officer at Goddard Space Flight Center, on organizational 

learning and knowledge management initiatives using case studies 

of Goddard and other NASA missions.

8 | ASK MAGAZINE
Good engineers know a lot. They know how and when to 

multitask; they can focus on details as well as the big picture; 

they interpret requirements and make good judgments about 

which are necessary and which are merely desirable; they make 

educated decisions about risk; they are team players and listen 

to others’ opinions; they brainstorm, whittle down to viable 

options, and make decisions; they empower, mentor, and teach 

others; and they take and give constructive criticism. Many of 

these qualities are also essential for being a good project manager. 

So why don’t all good engineers become good managers?

A Difficult Transition

When I made the move from engineer to manager, upper 

management expected me to handle all project issues and 

concerns and report back plans to correct them. Trying to 

do that on my own, with no formal training, I ran the risk 

of becoming a micromanager and a stranger to my family. I 

eventually realized I needed help from my whole team. Sharing 

the load meant the project could be successful, and I could 

leave work at a reasonable time and have a family life. I also 

believe that letting my team know that I couldn’t do it all myself 

encouraged them to come to me when they, too, needed help on 

a particular task. No one ever told or showed me that this was 

something I should do as a manager—and must do to become a 

successful manager—and learning the lesson was painful.

I made mistakes and couldn’t avoid all the pitfalls that come 

with moving from a specialist role to a managerial one. During 

unfavorable (not constructive) feedback, I learned I was doing a 

poor job of managing my budget and schedule and that my team 

was filing complaints about me. That was tough to hear, but it 

told me what type of manager I had become. In some areas I was 

a “micromanager” and in others I was a “hands-off manager.” 

One of my early projects as a manager involved a guidance 

system for a launch vehicle, which I let the contractor handle 

completely because, at the time, I had little guidance system 

expertise. At the critical design review, it became clear that the 

contractor had accidentally designed for a suborbital launch 

trajectory, which meant the vehicle would come back to bury 

itself in the earth, rather than an orbital trajectory. Had I 

taken time to familiarize myself with the system along the way, 

I could have caught the problem early on. I was paying too 

much attention to the areas with which I was most comfortable 

and familiar and avoiding the unfamiliar because it was 

uncomfortable, and I had a greater chance of messing it up. A 

tight schedule and low budget compounded the problem. At 

this point, I had two choices: proceed on my current path and 

more than likely continue to be unsuccessful, or acknowledge 

my error and get some help. 

Instead of falling deeper into fear and ignoring the tough 

feedback, I asked the company vice president, who had been a 

Does a Good Engineer Make 

a Good Project Manager?

BY GEORGE N. ANDREW

Many at NASA believe the myth that good engineers make good project managers. My twentyeight years of experience in engineering and management have taught me that engineers are often 

poorly equipped to manage projects, but it isn’t always their fault. 

I WAS PAYING TOO MUCH ATTENTION TO 

THE AREAS WITH WHICH I WAS MOST 

COMFORTABLE AND FAMILIAR AND 

AVOIDING THE UNFAMILIAR BECAUSE 

IT WAS UNCOMFORTABLE, AND I HAD A 

GREATER CHANCE OF MESSING IT UP. 

INSIGHT | ASK MAGAZINE | 9
project manager, why I was perceived as doing poorly in some 

areas. I found a mentor and sought training outside the firm 

to help recognize my faults and failures. I also set aside time in 

regular staff meetings to ask my team how I could help them do 

a better job and what I could do to be a better manager. Taking 

that risk was frightening and overwhelming. I was fairly sure 

that raising those questions would strengthen their impression 

that I was less than capable of doing the job. Instead, I began to 

regain the team’s trust, and we began to work better together.

Finding a mentor and training to improve my people 

management skills were the most important steps in turning 

my failure into success. I learned not only how to work with 

people better but also how to recognize the fear of failure that 

was sabotaging my ability to succeed. 

Making the Change 

So perhaps the question should not be does a good engineer 

make a good project manager, but rather how can we help a 

good engineer become a good project manager?

Good systems engineers have experience seeing the big 

picture and multitasking. Good detail design engineers are well 

versed in managing details. These strengths can also be pitfalls. 

A systems engineer may fall into the role of a hands-off manager 

by losing sight of the details, while detail design engineers run 

the risk of becoming micromanagers. Both should aspire to 

become empowering managers who have natural leadership 

skills and can balance a project’s demands with their team’s 

abilities. Recognizing an engineer’s strengths and limitations 

should be the first step in making the change from engineer to 

project manager. 

What both types of engineers need most is training in how 

to work successfully with a team. Supporting and leading a team 

requires a different skill set than supporting a system. Good 

engineers need training in how to become good managers, no 

matter how talented they are. Thinking that they will be good 

managers because they are good engineers only perpetuates the 

myth and sets them up for failure.

I am not a perfect project manager, nor a perfect engineer 

for that matter. I have learned how to ask for help, empower my 

team, give credit where and when it is due, continuously work 

with a mentor (seeking a new mentor when I am without one), 

take bad news and issues up the chain, and develop (with my 

team) a recovery and implementation plan. We managers need 

to prepare our high-performing engineers better for the new 

responsibilities they will face as project managers. The first step 

is recognizing that technical ability alone and even technical 

ability combined with natural leadership skills are not enough 

to make the transition successful. ●

This article is based on a presentation from NASA’s 2006 PM 

Challenge. The original presentation may be found online 

at http://pmchallenge.gsfc.nasa.gov/Docs/2006attendeepresentations/2006presentationsCD-attendee/George.Andrew.pdf.

GEORGE N. ANDREW is an independent consultant with twentyeight years of experience with spacecraft and launch vehicles, 

including fifteen years in project management. He has developed 

and presented numerous tutorials and authored several articles 

on systems engineering in spacecraft and launch vehicles. He is 

currently working as a program systems engineer on the NOAA 

GOES-R series weather satellites at Goddard Space Flight Center.

This article mentions different managerial archetypes. 

Below are qualities I have observed or experienced from 

each type.

THE MICROMANAGER

The micromanager seems never to delegate; always 

has to do things himself; doesn’t plan (and wonders 

why there is always a problem); looks to blame instead 

of encourage results; performs crisis management; 

believes whatever is done isn’t done well enough; thinks 

there is never enough time to get anything done; seems 

to always claim the fame; rarely rewards subordinates; 

and is motivated by fear. 

THE HANDS-OFF MANAGER

The hands-off manager seems to always delegate; never 

does things herself; asks others to do the planning; 

reviews very little work from her subordinates; approves 

everything either without reviewing it or asking questions 

about it; doesn’t understand why or what decisions are 

made, as she doesn’t make the decisions; seems to 

work in the shadows of others; may or may not reward 

subordinates; may or may not claim the fame; and is 

motivated by fear. 

THE EMPOWERING MANAGER

The empowering manager delegates with an observant 

eye; shares in the work; works with others in planning; 

always looks ahead; empowers those that work for him; 

reviews work and suggests improvements; pushes those 

who work for him to step forward; encourages creativity; 

looks to solve the issues and not place blame; looks to 

do the right thing; manages time; and is motivated by 

confidence and trust. 

10 | ASK MAGAZINE
When I was a young, eager PhD student at Massachusetts 

Institute of Technology (MIT) searching for a thesis topic, I 

would take long, late-afternoon walks around the Institute, 

hoping to stumble upon inspiration in the paint-scabbed 

hallways. Inevitably I ended up in Building 4, the domain of the 

music department. The pianists would be practicing, usually 

something difficult and melancholy, and music would trickle 

from the instruction rooms and fill the corridor. For a moment, 

my unwritten thesis would be forgotten, and I would remember 

that there were, in fact, other things in the world besides simplex 

algorithms and Bode plots and Kalman filters. (These random 

musical interludes were, I’m sorry to say, some of my most 

pleasurable moments as a graduate student.)

I eventually found a thesis topic in the field of robotics. 

Specifically, I investigated autonomous control algorithms for 

planetary surface exploration rovers. (Full disclosure: my research 

was sponsored by the wonderful folks at NASA’s Jet Propulsion 

Laboratory.) To complement my major field of study in robotics, 

I chose as a minor field a subject that had interested me since I 

was a boy: fiction writing. Making up stories. Lying, though in 

a classy and interesting way. If musicians could find a home at 

MIT, I figured, then so could an aspiring fiction writer. 

When I proposed this course of study to my PhD thesis 

committee, I expected to be reminded that my work lay in the 

realm of fact, not fiction. Instead, the three professors nodded 

vaguely. “If that’s where your interests lie ...” one offered. I 

interpreted this as enthusiastic approval.

Fast-forward three years. I was strolling the Institute 

corridors, my thesis recently defended, my mood brighter than it 

had been in a long, long time. Through a combination of sweat 

and luck, I’d had my first book of short stories published, and the 

event was accompanied by an article in the campus newspaper. 

I happened to bump into one of my thesis committee members. 

He offered me a bemused grin. “I read about your book in Tech 

Talk,” he said. “I didn’t know you were writing short stories!”

“Well, I did minor in fiction writing,” I said. “You approved 

my course of study. Remember?”

“Ah!” he said, as though a profound mystery had been 

explained. “I thought you were studying friction!”

And so it has continued in both my careers, as a robotics 

researcher and fiction writer. Whenever I reveal that I’m a 

researcher who writes fiction—or a fiction writer who dabbles 

in research—I’m met with curious disbelief, as though it’s 

impossible to pursue such singularly distinct activities.

But what I’ve come to realize is that the two efforts—

conducting engineering research and writing fiction—are much 

more similar than my thesis committee members (and many 

other people) might think.

Let me tell you a story.

BY KARL IAGNEMMA

INSIGHT | ASK MAGAZINE | 11
I don’t mean to suggest that research efforts have plots or 

characters (save for the eccentrics that haunt university and 

government laboratories alike). What I mean is that the process 

of performing research is similar to the process of writing a work 

of fiction—or at least it is for this researcher/writer.

I view both research and fiction writing as exercises in 

structured creativity. Both begin with a blank page then progress 

through different stages, each focusing on an increasingly fine 

level of detail. To illustrate this process, let me briefly describe 

two of my own recent experiences: researching methods for 

autonomous vision-based terrain sensing by Mars surface 

exploration rovers, and writing a short story called On the Nature 

of Human Romantic Interaction. The goal of the research was to 

develop a method for autonomously analyzing images of Martian 

terrain to identify the location of large rocks and hazardous drifts 

of regolith (the loose, dusty material that covers solid rock below). 

The short story described a—fictional—failed PhD student who 

yearned to formulate an equation that would predict the time 

evolution of his flaky girlfriend’s affection for him.

Where did these ideas come from? I have no idea. Like all 

ideas, they emerged from the subconscious swamp of everything 

I’ve read and overheard and dreamed about and forgotten. 

Nearly all my ideas are bad ones; a few, though, throw off a 

certain indescribable spark. And choosing an idea—hauling it 

from the subconscious swamp into the harsh light of critical 

examination—is the first, and most difficult, stage in the 

creative process.

This first stage, more than any other, relies on an individual’s 

talent. I am convinced that talent in the research domain is 

expressed primarily in a person’s ability to choose interesting 

research problems to address. I’ve worked with researchers who 

were shockingly intelligent, and others who possessed formidable 

analytical skills—but the ones I consider most talented were neither 

the smartest, nor the most skilled, nor the best schooled. They 

were the ones who had an unteachable ability to ask the question, 

“What if we could do X?” (Here, X represents something startling 

and useful that many other researchers have overlooked.) 

Talent in fiction writers can follow a similar pattern. Great 

writers are often unexceptional stylists—I’m thinking of Philip 

Roth, Richard Ford, and Robert Stone, to name a few—but 

possess an ability to describe a character or event or setting in 

such a way that its essential nature is revealed. Think of John 

Cheever’s (or John Updike’s) vision of American suburbia, or 

E. L. Doctorow’s depiction of early 1900s New York. Great 

writers, like great researchers, can find beauty and meaning in 

even the most commonplace material.

The difficulty of this first stage arises from its fundamental 

lack of structure. When faced with a blank page, our minds 

often tend toward the mundane—an imitation of a story that 

we heard last week; a minor variation on a technical approach 

that we read about last year. While it is easy to rehash an old 

idea, it is very hard to create something truly new. Art and 

science agree on this point: newness is a necessary (though not a 

sufficient) condition for any good work. Writers since Sophocles 

have struggled to make it new, since even the most shop-worn 

concept—boy meets girl, boy loses girl, boy feels awful—can 

become fresh, and powerful, when imbued with a distinctive 

voice, placed in a unique setting, or described in a style that 

challenges our assumptions about the way language must be 

used. In scientific research, newness is essential: if an idea is not 

new, it does not represent an advance in the state of the art, and, 

therefore, it is not worth investigating.

The next stage of the creative process involves exploring 

the space of our idea. Now that we know what we’re after—the 

problem we want to solve, the story we want to tell—we hunt 

for methods, techniques, and tricks that will let us solve our 

problem, or tell our story, in an interesting and meaningful way. 

Often the struggle lies not in formulating a potential approach to 

a problem, but deciding which among several possible approaches 

will allow us to most elegantly—or rigorously, or beautifully—

achieve our goals. To solve a given mathematical problem, for 

example, one must often choose between pursuing an analytical 

solution or relying on numerical analysis. In fiction writing, the 

same story can usually be told from various different points of 

... THE TWO EFFORTS—CONDUCTING ENGINEERING 

RESEARCH AND WRITING FICTION—ARE MUCH MORE 

SIMILAR THAN MY THESIS COMMITTEE MEMBERS 

(AND MANY OTHER PEOPLE) MIGHT THINK.

12 | ASK MAGAZINE
view; the choice of point of view—first person or third person 

(or second person, even)—strongly influences the lyrical and 

dramatic possibilities of the work.

In our efforts, we have progressed from a pair of blank pages 

to ones filled with scribbled notes and crossed-out questions, 

scrawled reminders in the margins. Our desk is piled with 

journal articles written by previous researchers, novels written 

by other writers. And as we probe equations and sketch scenes, 

we conduct what amounts to a search through the constrained 

space of our idea, hunting for something good: an analysis 

technique that lends insight into a particular form of equation; 

a combination of character and tone and setting that yield the 

unmistakable whiff of good fiction. 

In our rover research example, this stage requires us to 

identify visual features of the Martian surface that yield clues 

about the terrain’s physical characteristics. Are features drawn 

from terrain color more descriptive than those drawn from 

texture? Should we approach the problem as one of classification 

or segmentation? And in our fictional example, is this failed PhD 

student in his late twenties or early forties? Did he quit graduate 

school by choice, or did he flunk out? And should the story be 

told from his point of view or that of his flaky girlfriend?

(For those of you scoring at home: in the rover research 

we decided to pursue a Bayesian approach to multiclassifier 

fusion, to merge the outputs of supervised classifiers operating 

on image color, texture, and elevation features. In On the 

Nature of Human Romantic Interaction, I wrote about a fortyone-year-old ex-PhD student named Joseph who dropped 

out of the (fictional) Michigan Engineering Institute but 

continued to man the twenty-four-hour computer hot line as 

he wooed his young girlfriend. (The equations describing the 

time evolution of her affection, by the way, were of the LotkaVolterra variety.))

The final stage of the creative process is revision and 

refinement. We’ve figured out how to solve the research problem 

at hand; we understand what story we want to tell, and how we’ll 

tell it. Our simulation results are promising; our characters are 

vivid and our scenes compelling. Our conclusions feel surprising 

but somehow inevitable. 

What remains is to bring the work to a state of near 

perfection by making minor (or, occasionally, not so minor) 

changes. This stage focuses primarily on individual words and 

numbers: adverbs and adjectives and gain levels and parameter 

values. Should the image features be extracted over an 8 x 8 pixel 

window, or 12 x 12? Should a filter be used to mitigate noise, or 

not? And if so, what are the best locations for the filter poles?

And should Joseph—poor, hapless Joseph—be forty-one 

years old, or will making him forty-three increase a reader’s 

sympathy for his plight? Should his girlfriend be named Kate or 

Alexandra? Should the evening sky be “eggplant-colored,” or “the 

color of a deep bruise?” Our work nearly finished, we scrutinize 

every choice—every metaphor, every variable—hoping to 

transform something decent into something good, something 

good into something excellent. And eventually—weeks, or 

months, or even years after we began—we quit, exhausted, 

unable to bear another moment’s contemplation of the work. 

The creative process ends with a whimper, rather than a bang.

There are individuals, I know, whose creative processes are 

profoundly different than the one I’ve just described. Writers 

who pen a single, inspired sentence, then watch a story unspool 

with little revision. Researchers who bash every problem 

they encounter with a single, well-worn analytical hammer. 

I’d suggest that these differences, however, say more about 

differences in personality than they do about the (supposed) 

gulf between art and science. What if? can be answered in many 

different ways—through an elegant assembly of equations, or 

through pages of interesting lies. ●

KARL IAGNEMMA is a principal research scientist at MIT and 

author of the books On the Nature of Human Romantic Interaction 

and The Expeditions.

ASK MAGAZINE | 13
BY RANDII R. WESSEN AND DAVID PORTER THE CASSINI RESOURCE EXCHANGE

14 | ASK MAGAZINE | STORY
Saturn sits enveloped by the full splendor of its 

stately rings. Between the blinding light of day 

and the dark of night, there is a strip of twilight 

on the globe where colorful details in the 

atmosphere can be seen. 

Photo Credit: NASA/JPL/Space Science Institute

ASK MAGAZINE | 15
Unfortunately, the cost of the two spacecraft grew too large, 

and in 1992 CRAF was canceled. This placed Cassini in a 

precarious position politically. Canceling one of two missions 

did not reduce the cost of the remaining spacecraft by half; the 

savings were only on the order of 25 percent. The challenge was 

to complete the development of the Cassini spacecraft without 

accruing massive cost overruns. 

But substantial cost growth is the rule and not the 

exception when building planetary spacecraft. Cassini had to 

develop a large and complicated science payload as well as the 

spacecraft itself. The program had $200 million and four years 

to build twelve sophisticated science instruments designed to 

explore the Saturn system. Cassini had to find some approach 

for controlling the appetites of its instrument development 

teams for additional resources. The usual method involved the 

science instrument development manager holding a reserve for 

instrument development problems. This method produced an 

unsurprising, undesirable outcome: as instrument teams ran 

into trouble, they asked the science instrument development 

manager for help. 

This placed him in a difficult position. He had to 

determine if the request for additional resources was valid. Did 

the instrument development team make an honest mistake 

that increased the scope of their instrument, or did they take 

additional development risks knowing there would be reserves 

to help them if they got into trouble? Instrument teams tend to 

think reserves are their own personal insurance policies.

Cassini’s leaders knew that in the past this approach didn’t 

stop the cost growth of the instruments. But either a large cost 

overrun from an individual instrument development team or 

small overruns from many instrument teams could result in the 

cancellation of the program. Some other approach had to be 

used to control the growth of instrument resource demands. 

Desperate times called for desperate measures. The program 

looked to its home institution, the California Institute of 

Technology (Caltech), and contacted the economists from 

the humanities and social sciences department. The Cassini 

program managers wondered if economic theory could be used 

to control real-life development costs. 

The first thing the economists did was work to understand 

the particular Cassini problem and then review past missions to 

obtain a historic perspective. After analyzing the problem, they 

realized that Cassini’s instrument development challenges could 

be resolved with a market-based system. 

These systems use markets (the demand for particular 

commodities) to obtain better information about what is and is 

not really needed. They are used all over the world in all types 

of industries to solve scarce-resource allocation problems. But 

could this economic tool solve Cassini’s science instrument 

development issues? How could individual instrument provider 

It’s amazing what you can do when you don’t have a choice. That exactly describes the Cassini mission 

to Saturn when its twin sister CRAF (Comet Rendezvous and Asteroid Flyby mission) was canceled. 

CRAF and Cassini were designed together by the Jet Propulsion Laboratory for NASA as part of the 

Mariner Mark II series of spacecraft in the early 1990s. The thinking was that developing a common 

spacecraft for deep space exploration would mean substantial cost savings for both the comet and 

Saturn missions. In addition, the common spacecraft design would give the Saturn craft the benefit 

of the larger fuel tanks needed for CRAF’s orbital mission around a small comet, and CRAF would 

get a large communication antenna from Cassini, which needed such a dish to return data from a 

billion miles away. This design approach also promised to benefit all future outer planet spacecraft. 

16 | ASK MAGAZINE
demands possibly be in the best interest of the overall science 

payload? Finally, if the program decided to go with a marketbased system approach, how could it be sure the system would 

help solve their particular problem? After all, they only had one 

chance to build their science payload within budget. Should the 

program use such a radical and unknown approach? Could they 

afford not to?

The Cassini team needed to be convinced somehow that a 

market-based system could solve their problem. Fortunately, the 

economists had a technique to allay some of the team’s concerns. 

They would use experimental economics to test the tool that 

would be used by Cassini. Experimental economics can be 

thought of as a kind of “wind tunnel” for human behavior. That 

is, it can construct an operational environment that accurately 

simulates the behavior of the instrument development teams. 

Students at Caltech could be paid according to how well 

they performed. Each student would have to make decisions 

about choosing riskier or less risky development approaches to 

simulate the building of their particular instruments. The lab 

environment would introduce random “good luck” and “bad 

luck” events affecting the student-run instrument teams. Those 

students who performed well (that is, had the smallest growth 

in demand for additional resources) would be paid the most. 

Those students who had a large growth in resource demand 

would be paid the least.

Once this environment was established, parameters could 

be adjusted to understand how changing circumstances affected 

students’ behavior. By performing experimental runs with 

various parameters, the full range of instrument development 

team behaviors could be modeled. The results of running such 

experiments at Caltech showed that the students did indeed 

behave like instrument teams and that a market-based system 

could be designed to control the resource growth of the twelve 

Cassini instrument development teams.

In 1993 the Cassini program opened the Cassini Resource 

Exchange. To help the instrument development teams get over their 

fear of this radical online tool, each team was assigned a Caltech 

student who would do the actual bidding for instrument resources 

under directions from the instrument managers. The students 

were also motivated to find and complete trades because they were 

paid according to their ability to make successful transactions.

Initially, instrument data rate, budget, mass, and power 

were available to be traded. The science instrument development 

manager had veto power to disallow any trade that was not in 

the best interest of the instrument teams or the Cassini program 

itself. In fact, the instrument teams did a great job defending 

their own instruments and needed no intervention. In addition, 

instrument teams involved in the trade had to come to a 

consensus on the terms of the trade and agree that all completed 

transactions were in the program’s best interest.

To be honest, there were skeptics. Some believed that the 

instrument teams would play “mass futures”—that everyone 

would hold on to excess mass and wait for the price per kilogram 

to go through the roof: buy low, sell high. Others thought that 

capitalism was great but were not sure what it had to do with 

building science instruments. My favorite criticism came from 

individuals who thought market-based systems were a form of 

gambling. One thought the Cassini mission should be renamed 

the Casino mission!

The Cassini Resource Exchange was available from 1993 to 

1995, the last three years the instrument teams were building 

their instruments. Some interesting trends became apparent. 

The first was that most teams traded for dollars and mass but 

were intimidated by the idea of trading for power and data 

rate. Both power and data rate had to be traded across multiple 

modes. That is, you could not trade five watts for $15,000. You 

had to specify how much power you wanted to trade in multiple 

spacecraft power configurations. This got confusing fast for the 

instrument developers, and most didn’t trust the system. Since 

it was difficult to check the results manually, most teams just 

stayed away from trading those resources. However, instrument 

teams loved “money market” trading of funds from their 

individual budgets. 

A money market trade occurred when a particular 

instrument team ran into financial trouble in a particular year. 

An instrument team would find that its overall (multiyear) budget 

INSTRUMENT TEAM A MIGHT REQUEST $200,000 FROM TEAM B 

THIS YEAR IN RETURN FOR GIVING TEAM B $212,000 NEXT YEAR.

ASK MAGAZINE | 17
was fine, but they had problems in the current year. Instrument 

team A might request $200,000 from team B this year in return 

for giving team B $212,000 next year. A team would state how 

much they needed this year and what they were willing to pay 

out the following years. If no team was interested, the instrument 

team could request less money this year or increase how much 

they were willing to pay later. The beauty of this type of trade is 

that team A solved its financial problem and team B would get a 

return on its “investment.” Both teams won.

Thanks to the Cassini Resource Exchange, the program was 

able to successfully build and deliver all instruments on time. 

As for the instrument resources, the overall cost of the Cassini 

science payload grew by less than 1 percent. And the science 

payload mass shrank by 7 percent. The science instrument 

development manager was able to return excess mass to the 

Spacecraft Development Office.

When a spacecraft/instrument problem arose, the Cassini 

program was able to do something that had never been done 

before. It held a “mass auction.” In this particular case, the 

program needed funds for stiffer plasma wave antennas and the 

Spacecraft Development Office had excess mass. This problem 

was basically a bad interaction between the antennas and the 

spacecraft. Since it wasn’t anyone’s fault, the program asked 

the instrument teams to submit “blind” requests for mass. If 

instrument teams needed mass, they would submit sealed 

envelopes with how much mass they were willing to buy and at 

what price per kilogram. Once the bids were in, the Spacecraft 

Development Office opened the envelopes and arranged the 

bids from the highest to lowest price per kilogram. The program 

then sold mass to the highest bidders until enough money was 

raised to pay for the stiffer antennas.

The success of the Cassini Resource Exchange allowed for 

a rapid transfer of this technique to the commercial sector. The 

Caltech professors who developed the system started a company 

and created a trading system based on the Cassini algorithms. In 

one case, the Los Angeles Air Quality Management Board used 

this approach for controlling smog emissions in the Los Angeles 

basin. The RECLAIM system gave polluters an allocation of 

how many tons of pollutants they were allowed to dump into 

the environment. Each year the overall number of tons would 

be reduced. Individual companies could decide either to pay for 

expensive air scrubbers and then sell the “credits” that resulted 

from polluting less than their allocation or to buy credits from 

other companies. The results have been impressive, and these 

market-based “cap and trade” systems are being considered for 

the entire state of California, seven states in the Northeast, and 

even the Kyoto Accord for controlling greenhouse gases.

Resource trading has been evaluated by many NASA projects 

and was used again on Terra, the Earth-orbiting platform, to 

solve instrument development issues. Once again the technique 

did a wonderful job controlling instrument growth. People 

still think of a market-based system as risky, and many remain 

unconvinced of its ability to solve their resource problems. As 

more and more companies switch to market-based techniques 

to solve their issues, however, project managers may begin to do 

the same. I’m not saying that we will replace systems engineers 

with resource brokers, but one day soon you may be bidding 

your way to the launchpad. ●

DAVID PORTER is the George L. Argyros professor of finance 

and economics at Chapman University. He received his MS in 

mathematics and PhD in economics from the University of Arizona. 

RANDII R. WESSEN joined the Jet Propulsion Laboratory in 

1984. He has worked on Voyager, Galileo, Cassini, and the Mars 

Exploration Rover projects. He has teamed with David Porter on 

market-based systems research for the past twelve years.

18 | ASK MAGAZINE
John C. Mather was study scientist and project scientist for the 

Cosmic Background Explorer (COBE) and principal investigator 

for the Far Infrared Absolute Spectrophotometer (FIRAS) on that 

mission. He shared the 2006 Nobel Prize in Physics with George 

Smoot for measurements of cosmic microwave background 

radiation that support important elements of the big bang theory 

of the universe’s origin.

He is currently senior project scientist for the James Webb Space 

Telescope and chief scientist for the science mission directorate at 

NASA Headquarters. Don Cohen spoke with him in his office at 

Goddard Space Flight Center.

I N T E R V I E W W I T H

COHEN: On COBE, how did you get from 

a research idea—measuring cosmic 

background radiation accurately—to a 

project that works?

MATHER: We were all hardware-oriented 

scientists. We tried to solve some of the 

obvious engineering problems, like where 

to put the observatory to get a protected 

environment. Fairly early on, we found 

the orbit we needed to use. The scientists 

were functioning as much as they could 

as engineers, trying to design a mission 

concept that could actually be built. Of 

course, we didn’t know how to make 

something spaceworthy or deal with such 

a huge scale of effort. We were assigned 

to work with the IUE [International 

Ultraviolet Explorer] project team, 

which was about to launch the IUE. So 

there was a complete engineering team 

already in existence, and we had some 

brilliant engineers to work with at that 

point. They said, “We’ll take you under 

our wing; we’ll work with you to figure 

out what you need.” Since I was the 

John 

Mather

BY DON COHEN

INSIGHT | ASK MAGAZINE | 19
study scientist, I spent my life with them 

trying to figure out how to make this 

project real.

COHEN: What was that process like?

MATHER: I met with engineers practically 

all day every day. We would just talk: 

How can you do this? How hard is 

that? How well do you have to do this? 

Of course, there were quite a few things 

that we couldn’t calculate. This was 

before everybody had a laptop that could 

calculate anything; I wrote handwritten 

memos with my version of a calculation 

of a requirement.

COHEN: In your book, you say engineers 

think of scientists as “arrogant and naïve.”

MATHER: We come from different cultures 

and have different ways of thinking. 

Engineers are trained to make something 

that really works. The scientist says, “I 

know I can’t do this or that, but I want to 

find a way around all the things that can’t 

happen.” That’s why I spent so much time 

with engineers. They knew what could be 

done, and I knew what we wanted to do. 

They’d say, “You can’t do that,” and I’d 

say, “If we change our request a little bit, 

could we do that?” That’s how the project 

evolves. I like to work on seemingly 

impossible engineering tasks. A scientist 

has to work with the engineering team 

to find a way around the impossible. It’s 

fundamentally a science-engineering job. 

The part that says, “Let’s find a path that 

combines the engineering possibility with 

the scientific wish”—that is science. Not 

all scientists have a talent for that.

COHEN: Have you worked with the kind 

of scientists who don’t work well with 

engineers, who just say, “These are my 

requirements?”

RUNNING MEETINGS WELL IS A tremendously IMPORTANT 

SKILL: how to hear FROM ALL THE PEOPLE SO THAT YOU 

DON’T MISS GOOD IDEAS; how to send PEOPLE AWAY 

knowing SOMETHING’S GOING TO HAPPEN.

20 | ASK MAGAZINE
MATHER: None of the people I work with 

are like that. There are people you would 

call theorists who have no interest in 

hardware or talent for it. We need those 

folks, too. They figure out what this 

information means.

COHEN: How does a hands-on scientist 

develop the practical skills he needs?

MATHER: You have to do hands-on 

stuff. In graduate school, I had to learn 

something about everything on the 

instrumentation we did there. The other 

scientists I worked with on COBE did the 

same. They built balloon payloads; they 

built laboratory hardware; they sawed, 

drilled, and soldered; they made circuit 

boards. You have to do stuff until you 

get some instinct about what hardware is 

like and how it acts. Someone was telling 

me recently that almost anybody who is 

anybody in ultraviolet astronomy got his 

start with Stu Bowyer at Berkeley. He 

was doing sounding rocket programs. A 

sounding rocket is like a miniature space 

program. It’s got all the problems that 

space observatories have, but it’s over in five 

minutes. A student has the opportunity 

to learn every aspect from beginning to 

end by working on such a small project. 

Similarly with balloon payloads, which 

most other people who have developed 

into hands-on space scientists have done. 

Those are the two basic categories: start 

off in school working in a lab where they 

do this stuff, and learn by doing. Watch 

how other people do it. If you were to look 

around at people who are now scientific 

leaders within NASA, you would find 

a large fraction of the PIs [principal 

investigators] and project scientists on 

flight programs got their start on sounding 

rockets and balloons.

Alan Stern [associate administrator 

for NASA’s science mission directorate] 

at headquarters is pushing hard to 

show that there is a career path for PIs 

or project scientists that leads through 

hands-on stuff. Now, for instance, if you 

look at the PI requirements for the SMEX 

AO [Small Explorer announcement of 

opportunity] that we’re about to open, 

you have to prove that you’ve done 

something on a space mission, which 

includes balloons, sounding rockets, and 

real space missions. Alan is saying, and 

I think he’s right, “Show me that you’ve 

learned how to do stuff.”

COHEN: On COBE, were you able to 

communicate your excitement about 

looking for fundamental facts about the 

universe to engineers, and did that help 

the collaboration?

MATHER: Yes, and it did help. They knew 

they were doing something important. 

That’s the only way I can explain why 

they cheerfully came in nights and 

weekends. Eighty-hour workweeks were 

not uncommon, especially at the last 

part of the project. I think we eventually 

developed a pretty good relationship 

between scientists and engineers, because 

we’d learned to know and trust each 

other. Now people tell me this was the 

best project they ever worked on.

COHEN: Do they tell you why?

MATHER: For two important reasons. One: 

the work was obviously important. Two: 

it was in house. Engineers love to do 

things. Going out to California to watch 

somebody else do work is not really much 

fun.

COHEN: In your book, you say the 

work was done in house because you 

couldn’t have contracted out such 

groundbreaking instruments.

MATHER: We did not feel there was any 

way to write a contract to do what these 

instruments had to do. Even after we had 

settled on the design, it was hard to say, 

“These are the requirements,” because 

we just couldn’t analyze well enough. 

Maybe these days we could analyze 

better in advance because we’ve got better 

computers and numerical modeling 

tools.

COHEN: Would you still recommend 

in-house work on groundbreaking 

technology?

MATHER: I would, but not unconditionally. 

In-house teams face hazards as well. 

University labs can do certain things 

better than we can. It’s harder for us to 

bring in the radical thinking of graduate 

students. Thinking about small prototype 

ASK MAGAZINE | 21
equipment is a good thing to do at a 

university lab. We did that with COBE, in 

fact. They built a prototype for the FIRAS 

instrument at MIT and told me that I had 

designed it wrong, that the focusing wasn’t 

working. That was correct, and we fixed 

it. I don’t think we would have found it 

as quickly and as easily in our labs here. 

When you’re hunting over a wide range 

of territory with lots of ideas to try out, it’s 

hard for an engineering team to shift into 

that mode.

COHEN: What kinds of problems—other 

than engineering realities—did you face?

MATHER: Some were organizational. We had 

something called “matrix management,” 

which we love and hate. The good thing 

about it is there’s a huge pool of talent you 

can draw on. The bad thing is those people 

are not yours. When you want their time, 

they may be busy doing something that 

someone else said was important. We had 

a cartoon that showed two boats with 

lots of oarsmen. Matrix management is 

people paddling in every direction and 

no manager at the end of the boat. The 

other one is project management the way 

project managers like to do it: they know 

who’s in the boat; there’s a guy at the end 

beating a drum; everybody is paddling in 

the same direction. Our problem wasn’t 

about scientists versus engineers. It was 

engineers, managers, and everybody 

fighting over a scarce resource.

So priority really matters. COBE was 

set up as an in-house project that could 

draw on Goddard resources, but it had 

low priority. We were a training program; 

we helped recruit bright, young people. 

When Hubble had difficulties, they could 

swipe our engineers. It’s hard to make 

progress when you’re the lowest priority. 

You don’t get very far when your team is 

frequently taken away from you.

COHEN: When the Challenger disaster 

happened in ’86, it became clear that 

you wouldn’t send COBE up in a shuttle 

and would have to cut its weight in 

half for a rocket launch. You’ve written 

about deputy project manager Dennis 

McCarthy pulling people together in a 

“skunk works” to continue the project.

MATHER: It was the only way to do it. 

And once it was clear that it was going 

to be possible, headquarters said, “Great, 

do it now.” So we went from the lowest 

priority to the highest, or second only 

to the Hubble telescope. Suddenly we 

were able to accomplish things and build 

a project management structure with 

people dedicated to the team and working 

together in one place. The fact that JWST 

[James Webb Space Telescope] has priority 

matters immensely and mattered from 

day one. When Dan Goldin, then head 

of NASA, said, “This is really important, 

and we’re going to do it,” brilliant people 

came from everywhere to work on it. If 

he had said, “It’s a good idea, but it will 

have to compete with a lot of other good 

ideas,” I don’t think we would have made 

nearly the progress we’ve made.

COHEN: The advantages of bringing 

people together seem clear. Can it be 

done without a crisis?

MATHER: There’s no particular reason 

why every project can’t be like that. The 

challenge for management, though, is 

deciding whether they can afford to put a 

person on a project full time. The project 

manager says, “I need to know who’s on my 

project all the time. If someone completes 

a particular job, I’ve got something else 

for him to do.” The matrix manager says, 

“If that person’s job is done, I want him 

to work on another project.” It’s hard to 

cope with matrix management flexibility 

if you’re a project manager. The lesson 

learned on matrix management is it’s OK, 

but assign people full time and make sure 

they know whom they’re working for 

during big blocks of time. In the earliest 

days of COBE, we had people charging a 

tenth of their time. They were able to go 

to a meeting, but they didn’t have time to 

produce anything useful. A tenth really 

equals zero. It drove us crazy, and I don’t 

think it made those people happy.

COHEN: What was it like working with 

McCarthy and [project manager] Roger 

Mattson?

MATHER: I loved working with those guys. 

Roger’s been gone now a long time, bless 

his heart. Dennis is still around. When 

you walked into his office with a problem, 

you’d talk for a while, and then he’d sort 

of give you a wink and a grin. You’d know 

22 | ASK MAGAZINE
he understood what you’d asked for and 

was going to do something about it. Tony 

Fragomeni, the observatory manager, was 

another person I loved working with. He 

used colorful expressions that were not 

always polite, but people knew he meant 

what he said and was going to get the 

matrix organization to work with him.

Tony used to sit at the end of the table 

with a plastic baseball bat and make sure 

he heard from the right people. Running 

meetings well is a tremendously important 

skill: how to hear from all the people so 

that you don’t miss good ideas; how to send 

people away knowing something’s going 

to happen. You have to say, “I understand 

that this is the decision.” Absolute clarity 

is required. If you dither around and put 

off the decision for another week, you’d 

better have a plan for what you’re going 

to do instead. Drawing decisions out of 

discussions and actions out of ideas is 

the secret for getting anything done. If 

we could have a training program for 

scientists and engineers, I would say the 

number one thing would be how to run 

a meeting. You can piss away people’s 

good will and their time and money with 

meetings that do nothing.

COHEN: I’m struck by the fact that 

COBE experienced several “happy 

accidents”—like the time a delicate 

instrument escaped damage in the 1989 

San Francisco earthquake because the 

man who would have been testing it went 

off to be married that day and put it in 

safe mode. Are there ways projects can 

increase the chances that the accidents 

that happen will be happy ones?

MATHER: The thing that helps ensure happy 

accidents is people working like crazy to 

make the good things happen. Of course 

we were aware that earthquakes happen in 

California, so stuff was strapped down. 

COHEN: There’s an element of forethought.

MATHER: There’s some forethought. The 

test program is a way of trying to make 

happy accidents happen. Murphy was 

right: things will go wrong. Our job in 

the test program was to think of them all 

and make sure we had a test that would 

find them before we launched. In order 

to have good luck, you have to work 

like mad thinking of things that could 

go wrong. Harvey Moseley says being a 

scientist is about fixing what’s broken. 

Building a space mission is like that. The 

test program tries to break it. There’s no 

possibility of designing something right 

the first time.

 There was one case of technological 

change made for the DMR [differential 

microwave radiometer] instrument. We 

were delayed for various reasons and 

needed to save some money, so we ended 

up eliminating one of the frequency bands 

THE DIRBE ... INSTRUMENT WAS specially designed TO FIND 

the stuff NOBODY COULD EVER SEE BEFORE: ALL THE LIGHT 

FROM the earliest galaxies. WE THOUGHT we’d never have

A TELESCOPE BIG ENOUGH TO SEE THOSE GALAXIES. NOW, 

WE THINK we have, AND we’re building it.

ASK MAGAZINE | 23
of the DMR and using the saved resources 

to up the technology on the others. If we 

hadn’t done that, we wouldn’t have found 

the big bang bumps. That’s one of those 

happy technology accidents. This one 

was accidental because cosmic bumps 

had never been predicted well enough to 

tell us how hard we had to try.

COHEN: You made an educated guess 

that this trade-off was worthwhile.

MATHER: We knew it would be worthwhile; 

we didn’t know it was critical. If we had 

not made that change, we might not have 

discovered the CMB [cosmic microwave 

background] bumps. Or it would have 

required four years to get the sensitivity 

we got in one year. That’s one of those 

happy accidents of technology. 

COHEN: Are the scientific aims of the 

James Webb Space Telescope you’re 

now working on an extension of what 

came out of COBE?

MATHER: For sure. COBE and WMAP 

[Wilkinson Microwave Anisotropy 

Probe] and Hubble have all been pointing 

us at science of the early universe. With 

COBE, the DIRBE [diffuse infrared 

background experiment] instrument was 

specially designed to find the stuff nobody 

could ever see before: all the light from 

the earliest galaxies. We thought we’d 

never have a telescope big enough to see 

those galaxies. Now, we think we have, 

and we’re building it. The COBE DIRBE 

instrument found light from unknown 

sources that are still unknown. If you 

find something that wasn’t supposed to 

be there, you should build something to 

find out what it was. JWST is it.

COHEN: Did your COBE experience help 

with designing JWST?

MATHER: It’s hard to be specific about 

that. When you start a new mission, the 

hardest problem is figuring out what 

shape it is and where it is going to be. It’s 

a geometry problem. The orbit you put 

it in tells you the thermal environment. 

The shape tells you what temperature it’s 

going to be. The whole thing is geometry 

at the beginning. I love geometry. In high 

school, I would sometimes lie awake all 

night trying to solve a geometry problem. 

There was a lot of that with the initial 

phase of the JWST. It’s remarkable that 

the concept we’re building now looks an 

awful lot like the concept we had on the 

boards a few weeks after the start of the 

JWST studies. It took a few weeks to 

find the right shape and the right orbit, 

at least in general terms. Everything else 

is detail.

COHEN: When is it supposed to go up?

MATHER: 2013. It seems like a long time, 

but it’s only six years, and we’re running 

like crazy. We have a good plan, and we’re 

quite far along.

COHEN: What are the main challenges?

MATHER: The biggest challenge is not 

screwing up. Even manufacturing stuff 

that we know how to make is hard. 

Probably the hardest part that anyone 

will see is the mirrors. We’ve got eighteen 

wonderful beryllium hexagons to build. 

We’ve got to get process control so we 

do every one of them right. It’s so easy 

to find a way to screw up. If one person 

pushes the wrong button one day, you 

lose some important piece. We’ll have a 

long period of time to test the observatory 

after it’s finished. We are counting on 

that to find and repair any problems that 

are still there.

COHEN: Do you find some of the same 

spirit on JWST that you had on COBE?

MATHER: When things are working well, 

people enjoy the process. They don’t 

mind going to the meetings. People on 

this hall who don’t work on JWST have 

told me they hear laughter coming out of 

the project meetings. They say, “I want 

to work on that project.” A good sense of 

humor combined with getting the right 

thing to happen is important. I think the 

project management sets the tone a lot of 

the time. It’s not easy to tell people how to 

do that; some people have that talent. ●

24 | ASK MAGAZINE
BY MATTHEW KOHUT

IN-HOUSE HARDWARE DEVELOPMENT

Space-to-Space 

Communications: 

The Goldstone Deep Space Communications Complex, 

located in the Mojave Desert in California, is one of three 

complexes that comprise NASA’s Deep Space Network 

(DSN). The DSN provides radio communications for all of 

NASA’s interplanetary spacecraft and is also used for radio 

astronomy and radar observations of the solar system and 

Photo Credit: NASA/Jet Propulsion Laboratorythe universe.

STORY | ASK MAGAZINE | 25
The space-to-space communications system (SSCS) is designed 

to provide voice and telemetry among three on-orbit systems: 

the Space Shuttle orbiter, the International Space Station (ISS), 

and the Extravehicular Activity Mobility Unit (EMU), the space 

suit worn by an astronaut during a space walk or extravehicular 

activity. SSCS is designed to allow simultaneous communication 

among up to five users. The system consists of space suit radios 

(SSER), the shuttle orbiter radio (SSOR), and the space station 

radio (SSSR). The three have common elements but also unique 

features and different designs.

NASA decided to treat the SSCS as an “in-house” 

development, meaning that its own personnel would design 

and deliver the system. The Agency held a competitive bidding 

process and selected a prime contractor to refine the design and 

manufacture the radios. 

A Difficult Reorganization

The formal start of the SSCS project coincided with a 

reorganization within the engineering directorate at Johnson. 

Two divisions, the Tracking and Communications Division and 

the Flight Data Systems Division, merged into a new Avionic 

Systems Division. At the same time, a new project management 

office was created to manage the engineering project teams that 

in the past had interacted directly with the Space Shuttle or ISS 

programs. Both administrative changes affected morale, and 

several key engineers with radio expertise opted not to work 

for the project management office, which now had oversight 

over the SSCS project. At about the same time, the Johnson 

engineering directorate awarded a new general engineering 

support contract. As a result, all the contractor designers 

on SSCS left the project before Lemke took the reins. The 

engineering drawings those designers had completed for the 

prototype were nowhere to be found.

In short, Lemke began his first significant NASA project 

management assignment under a new internal organization, with 

no engineering drawings, none of the designers who had worked 

on the earlier phase of the development, and a project team with 

no expertise in the complex SSCS radio system architecture. 

In Lemke’s estimation, hard work was the answer. He relied 

on a team that was ready to give its all, despite its inexperience 

with the inherited technical design. The project itself was a 

motivator: it was the biggest project in the division, the work was 

important and challenging, and it offered a rare opportunity to 

do hands-on hardware development. 

Starting Over

The in-house team of designers began the painstaking process 

of deriving drawings from the prototypes, using calipers, ohm 

meters, and other reverse-engineering tools to determine the 

exact specifications of the boards. Every measurement was an 

opportunity for a mistake; a single missed connection might 

mean that an entire circuit wouldn’t work. The team’s progress 

When Johnson Space Center’s Matt Lemke showed up for work as the project manager of the spaceto-space communications system at the end of 1994, he looked forward to leading a team of NASA 

designers on the biggest project in his division. Lemke was an experienced avionic design engineer 

who was relatively new to project management. He would soon discover that he was starting with 

little more than an immature prototype system and an unforgiving schedule. He did not anticipate 

that the project would have to reverse-engineer its drawings from scratch, unravel major latent 

design defects, extend its delivery date by 300 percent, limit its systems testing to make up for lost 

time, or test the radios for anomalies on the launchpad right before its first in-flight trial on a shuttle 

26 | ASK MAGAZINE
proved excruciatingly slow, and Lemke 

realized that at this pace the project 

would never be completed. 

When he explained the situation 

to the contractor, he was assured its 

engineers could recreate the drawings. 

Lemke initiated a contract change 

and handed the boards over to his 

contractor, which was eager to prove 

itself on this project, its first at Johnson. 

Eight months later, the drawings were 

complete. The project was now where it 

should have been when Lemke arrived 

for his first day on the job. 

Fire-Drill Mode

The time the project had lost recreating 

the drawings inhibited the maturation of the design. The 

contractor was supposed to have spent those months turning the 

engineering prototypes into radios that could be manufactured 

and building test units. Instead, it recreated the laboratory 

units, which didn’t meet the project’s requirements. This 

became clear from the performance of the design verification 

test units (DVTU) the contractor had faithfully built based on 

the reengineered drawings. The DVTUs didn’t work well as a 

five-radio network for multiparty conversations.

With the scheduled delivery date for the space station radio 

closing in, Lemke elected to make the necessary fixes in a piecemeal 

fashion rather than add an additional DVTU cycle to address the 

problems on a systems level. Hoping to meet the delivery schedule 

for the space station, division management agreed. 

At this stage, the contractor informed Lemke that none of the 

units would consistently pass the specification tests. In response to 

growing concern that the NASA design had problems, the SSCS 

chief engineer expressed confidence in the design and asserted 

that the problem was the contractor’s manufacturing processes. 

Lemke pressed his contractor to stick to the design and build the 

qualification test units as though they were flight units.

The problems the contractor had 

predicted began to surface in the qualification units. Since the modem and receiver boards were identical for all three 

radios, flaws in one were reproduced in 

the others. A seemingly endless series of 

quick fixes were being made at the same 

time that the contractor kept producing 

more radios. This led to constant reworking of all the existing radios. The 

project operated in “fire-drill mode,” 

scrambling from one problem to the 

next, leading to schedule changes on a 

weekly basis and no time for rigorous 

systems testing. 

Division program management was 

assured that the fundamental problems 

were understood; all that remained was hard work to get the units 

delivered. This seemed a reasonable time in the project life cycle 

for Lemke to transition into another job opportunity while his 

deputy, Dave Lee, took the helm for the remainder of the project. 

The managerial transition was a smooth one, but no one involved 

recognized the hidden defects in the design that would soon emerge. 

Within a year, Lemke would be re-enlisted, along with temporary 

reinforcements from some of the division’s best engineers. 

Flight Time

The radios made it through acceptance, performance, and 

qualification testing. Some individual radios did not perform as 

well as expected, but they passed. The time came to modify the 

Space Shuttle orbiter and the space suits to accommodate the 

new radios. In the fall of 1998, the SSCS underwent a test flight 

on Space Shuttle mission STS-95. The flight uncovered some 

minor glitches, including an instance in which one radio would 

not talk to another. This problem was attributed to operator 

error and solved by re-cycling the system’s power (turning it off 

and back on). The SSCS team thought the radios were ready for 

a real in-flight trial. 

The Space-to-Space Communications System 

provides two-way communication among the Space 

Shuttle orbiter, the International Space Station (shown 

here), and the Extravehicular Activity Mobility Unit.

Photo Credit: Johnson Space Center

ASK MAGAZINE | 27
The project delivered its first radio to the space station 

in November 1998. At this point, problems seemed to be 

decreasing; there were still lots of fixes, but the technical work 

seemed manageable. The delivery schedule, however, remained 

daunting, as the project team faced demands for twenty-four 

flight radios and almost 300 spare modules. The next major 

effort was preparation at Kennedy Space Center for mission 

STS-96, which would launch in the spring of 1999. 

One month before the launch of STS-96, the project was 

granted special access on the launchpad to conduct burn-in 

testing of the radios. (Burn-in testing typically involves running 

electronics products with the power on for a number of hours 

to uncover defects resulting from manufacturing aberrations.) 

SSCS project manager Dave Lee and Lemke, who at this point 

was a consultant to the project, flew to Kennedy to lead the 

test. After the problems on STS-95, this test was established 

to regain the program’s confidence that the SSCS system was 

stable, reliable, and error-free. 

The SSCS team was granted permission to spend the entire 

evening of May 10 on the launchpad with the shuttle orbiter 

Discovery for dedicated SSCS radio tests. The first few hours 

were uneventful. A few anomalies were noticed, but the team, 

still committed to vindicating the radio’s reputation, rationalized 

them as flaws of the ground support equipment. 

Then a thunderstorm approached, producing severe 

radio frequency turbulence across the marshy plains of the 

launchpad vicinity. With each crack of the thunder, the SSCS 

radio signals buzzed and oscillated crazily. As they heard new 

sounds in their headsets, the radio operators characterized them 

with descriptive nicknames: “motor-boating,” “rain on the 

roof,” “laryngitis.” Even after this test, many latent defects still 

remained undiscovered, the most punishing of which would 

prove to be the radio’s hypersensitivity to other signals near its 

frequency range. 

By morning, the radio’s reliability problem was evident to 

every senior manager at the center. With the launch seventeen 

days away, the shuttle crew had to be trained in recovery 

procedures in case the radios malfunctioned in flight. A highly 

talented mission operations engineer, David Simon, helped the 

SSCS team characterize the problems, and he taught the crew 

how to respond by creating a cue card describing all the potential 

problems and mitigations. (The crew was already trained in the 

use of hand signals in the event of a complete radio failure.) 

The last-minute training proved necessary. Astronauts 

experienced “motor-boating” during a spacewalk. The preestablished procedures allowed them to recover gracefully 

from the malfunction, and the crew successfully carried out its 

mission despite the problems with the radios. On the ground, 

the SSCS team was ecstatic that nothing derailed the overall 

success of the mission.

Aftermath and Recovery

But SSCS had failed dramatically in a high-risk and highvisibility situation, and the debriefings of the STS-96 crew 

drew the attention of NASA’s senior management. The shuttle 

and the EMUs had to be retrofitted with the original radios 

for the next flight. The failure also marked the beginning of 

the project’s turnaround. Management ordered the SSCS to 

fix the system. Cost and schedule were secondary to finding 

the root causes of the problems. Every element of the design 

was reviewed. This allowed the team to conduct the extensive 

systems testing that it had foregone in the run-up to its first 

flight. The project also received resources to bring in experts 

who could help solve the problems. 

One of these experts was Mark Chavez, a soft-spoken and 

highly gifted radio frequency (RF) engineer, who took the 

helm as chief engineer. Troubleshooting a complicated design 

that was never fully documented or understood is a challenging 

reverse-engineering task. After hundreds of hours of testing and 

analysis, Chavez and a talented support team found the key 

issue plaguing the radios: a hypersensitive demodulator circuit 

that saturated itself every time another signal was near the SSCS 

frequency. The effects of the storm on the launchpad were now 

understood, as were other performance problems that seemingly 

occurred at random, such as on-orbit interference that, it 

appeared, was probably caused by taxicabs in South America. 

28 | ASK MAGAZINE
Latent defects were isolated one by one in a focused and 

deliberate process that brought in the division’s best design 

engineers in RF, software, and electronics. Each discovery 

helped explain the next problem in line, a phenomenon that 

division chief engineer Paul Shack described as “peeling away 

the layers of an onion.”

Each engineer took responsibility for a specific known 

problem and ran extensive isolated tests to address every issue. 

The final graduation test was an extensive system test using every 

known configuration imaginable for a five-radio network—all 

conducted in the noisy open-air environment of the Johnson 

Space Center’s back lot field, adjacent to all the RF noises of fast 

food restaurants, two-way commercial radios, and noisy cars. 

A huge space station airlock mock-up was trucked into the test 

field to serve as a simulated space station structure to reflect and 

diffract RF energy from the transmitters. Simulated space suits 

were outfitted with radios and installed in the bed of two pickup 

trucks that were driven around the field to try to confuse the 

radio network’s stability. At the end of this grueling process, the 

team could claim success at last. 

A year after STS-96, the SSCS was redeployed for STS-101 

in May 2000. The phantom noises that had plagued the system 

previously were gone. By the time of STS-106 four months later, 

the SSCS achieved error-free operations for the first time. It has 

continued to do so ever since. 

The SSCS project went through seventy-five contract 

modifications and six contract analysts in the process. The story 

has no single hero: a minimum of 181 people were directly and 

significantly involved in the project’s ultimate success. 

In hindsight, Lemke can point to three major lessons of his 

SSCS experience. “The first lesson is that technical performance 

must come first. Schedules and cost projections are meaningless 

if the design isn’t solid. My first priority on projects today is to 

get the right technical team in place with the right experience 

and the right mentors. 

“The second lesson I learned is the need for validation 

testing in realistic environments. The radios were fully tested, 

verified, and certified to meet all requirements prior to flying. 

Unfortunately, hundreds of hours of successful testing provided 

no assurance of proper operation if the testing wasn’t thorough 

enough. It wasn’t until we took a system view of the radios and 

tested them as they would fly that we uncovered our design 

flaws. 

“The final major lesson was to communicate schedule issues 

early and effectively. Had I fought harder and more effectively 

for my team to have the needed time up front, we would have 

saved countless contract modifications, configuration changes, 

and fixes in flight hardware that should have been done on 

development hardware,” he said.

He saw the failure during the STS-96 mission as a turning 

point that led to the resolution of the project’s difficulties. 

“That’s where we got to spend the time with our design to really 

get to the root cause. We got to do the testing, got to find out 

where the flaws were, and fix it,” he said. “It was just getting the 

team, the time, and the management support to solve it. There 

were no more Band-Aids. ‘Go solve it, and whatever it takes, 

you do it.’” ●

... TECHNICAL PERFORMANCE MUST 

COME FIRST. SCHEDULES AND COST 

PROJECTIONS ARE MEANINGLESS 

IF THE DESIGN ISN’T SOLID.

ASK MAGAZINE | 29
The Next-Generation Workforce 

and Project Management

BY DANIEL W. RASMUS

The workplace is changing in ways not due entirely to the introduction of new technology or new 

philosophies of management. The workforce itself is changing. The rise of the millennial generation 

brings workers who are more introspective, more connected to the world and their community, and 

less willing to align themselves to the needs of employers.

30 | ASK MAGAZINE | INSIGHT
For organizations like NASA, which rely on the knowledge, 

commitment, and skilled leadership of its people, the millennial 

generation joining the workforce as baby boomers retire will 

create challenges across the next several decades. Understanding 

something about this generation can help organizations make 

the best use of its many talents.

Who Are the Millennials?

The millennials were born between 1980 and 2000. 

Demographers call them the millennial generation, but they 

have other names as well: the MyPod generation, GenY, baby 

boomlets, or the boomerang generation. The oldest members of 

this generation are beginning to join the workforce now. 

In the United States, the millennials have watched their 

parents shift from a long-term employer to an outsourcer 

on short notice. They have seen a steady increase in foreign 

manufacturing while domestic manufacturing jobs wane. 

Many live in single-parent homes, and many in homes where 

both parents work. They have witnessed highly publicized 

corporate scandals, critical failures in iconic programs like the 

Space Shuttle, and relentless scrutiny of the business practices 

of successful firms. And they have heard parents and relatives 

complain about the retreat of employers from comprehensive 

health care and long-term retirement security.

This is also a generation characterized by high levels of health, 

prosperity, and education. From an early age they have had access 

to health care and a massive day care system; they have graduated 

from college in unprecedented numbers. Their lives have been more 

structured than their parents’, filled with the practices, rehearsals, 

events, and recitals their participation in sports and arts entails. 

In their limited unstructured time, they have turned from the 

passive entertainment of television and imaginative engagement 

of literature to exploring, connecting, and collaborating in 

the personal, dynamic, virtual world of the Internet. Unlike 

previous generations, they see their lives as more or less a 

seamless experience, where anything that interests them is part 

of the whole, and the traditional distinctions between work, life, 

learning, and service are blurred or eliminated.

Their learning, their knowledge of world events, and their 

lives online have shaped a generation that is self-reliant and 

entrepreneurial, a generation easily bored and technically savvy. 

Perhaps most disturbing to employers is this generation’s emerging 

propensity to give up money and economic benefits for time.

Many millennials do not have a firm attachment to the 

idea of career, instead seeing new opportunities in diverse areas 

as opportunities to learn. This attitude is not unique to young 

people joining the workforce now but appears endemic to the 

millennials, who, many believe, will continue to behave in this 

way throughout their work lives.

The life experiences of the millennials have so far created a 

generation that possesses these traits:

• Lacks trust in corporations

• Focuses on personal success

• Has a short-term career perspective

• Is quickly bored

• Is team oriented

• Builds community 

• Sees no clear boundary between work and life in general

• Is socially responsible

• Will sacrifice economic rewards for work–life balance

• Expects to work anytime, anyplace

These characteristics create new challenges for managers. 

Because of the magnitude of the shift from baby boomers to 

millennials, it is unlikely that organizations will successfully 

reorient the millennials to what has come to be considered a 

traditional work ethic; rather, the workplace will need to adapt 

to the attitudes and needs of this generation.

Knowledge and Talent Retention

Millennials consider their knowledge and skill more as a source 

of employment mobility than of career growth. Many see their 

knowledge as personal and portable, not organizational and 

collective. When it is communal, it is very communal, openly 

shared across their networks without regard to boundaries. 

ASK MAGAZINE | 31
Social networking sites often reflect a disregard for boundaries 

and an open, exploratory view of learning, where the search 

for an answer, the journey itself, is as well documented as the 

conclusion, if a conclusion is ever arrived at.

Microsoft has developed the following guidelines that may 

help organizations retain and attract millennial talent:

• Create engaging environments that inspire, challenge, 

and motivate employees

• Integrate millennials into a variety of projects, assignments, 

and career opportunities

• Favor flexible work schedules, locations, and arrangements 

(telework, work at home, and job share) 

• Use the diverse experiences and backgrounds of the 

workforce to create innovative work environments that 

challenge assumptions and create new opportunities

• Harness personal talents and skills by creating opportunities 

for people to contribute in a variety of roles

• Involve them in collaborative, team-based projects and 

environments

• Allow and support the pursuit of personal and social 

outside activities

• Create effective training and mentoring opportunities

• Harness knowledge created “just in time” through 

personal networks and recognize contributions from new 

methods of work 

Of course, organizations should take their own cultures 

into account when preparing for the millennial workforce, but 

they will need to take a hard look at their behaviors and values 

and decide if they are worth retaining if they limit access to the 

knowledge and skills of the next-generation worker.

Process Continuity

Maintaining knowledge across the life cycle of a long program 

has always been a challenge. In the past, though, most job 

changes were internal or upward within a team, and expertise 

remained available. The next-generation worker’s interest in a 

diversity of experience may lead to high rates of turnover. This 

means that organizations will lose knowledge unless they can 

find ways to rapidly transfer it to new members, or to retain it 

in knowledge bases or other codified forms. We at Microsoft 

are seeing a growing use of wikis and blogs as impromptu 

knowledge bases.

Microsoft sees “reciprocal mentoring” as an effective means 

for transferring skills. Experienced engineers, for instance, can 

help new peers better understand the business and the politics 

of the organization, as well as some of the practical wisdom of 

their engineering experience, while new employees challenge 

assumptions about how technology is used and help mentor 

older employees in new ways to apply it. 

This kind of learning does not exclude more focused time 

where individuals learn from each other outside the work 

experience, but it does offer a way for employees to model the 

lifelong learning process while taking advantage of its outcomes. 

Reciprocal mentoring is a skill that will take time to master, but 

it has the potential to engage employees by providing clear value 

to both parties.

Professor Birgitte Holm Sørensen from the Danish 

University of Education sees lifelong learning as a core skill in 

the future. She believes that, as the hierarchy of the classroom 

gives way to more collaborative learning, students will be 

encouraged to teach their instructors about technology; she also 

sees educators acting as project managers who empower teams 

of students to manage their own educational experiences.* This 

approach not only models learning but begins to help students 

appreciate the skills they will need to communicate ideas in a 

way that helps others absorb them.

Technology creates an opening for modeling lifelong 

learning and a mechanism for delivering it. Many businesses 

adopt a wide variety of collaboration technologies that help 

them take advantage of talent in a distributed workforce and 

retain knowledge from employees leaving a company. These 

techniques will continue to improve, but they are sufficiently 

advanced to be effective tools today. As engineers experiment 

with new forms of learning, they will influence the design and 

implementation of future tools that will provide them with 

the capabilities necessary to more easily and effectively deliver 

continuous learning within their communities, and beyond.

Leadership

I recently received a call from a large aerospace firm asking how 

they could retain millennials more effectively and encourage 

them to go into management. They were experiencing higher 

32 | ASK MAGAZINE
than average turnover rates and had found that their millennial 

generation employees were not interested in joining the ranks 

of management. To find future leaders among the millennials, 

organizations must create an environment that encourages 

them to consider career over complete autonomy. That means 

organizations will need to rethink leadership and management 

and make them more distributed.

One way is to think about projects as communities 

rather than teams. Leaders are assigned in teams but emerge 

in communities. By embracing the emergent behavior of 

communities, projects can take advantage of the skills of 

multiple leaders, each directing an aspect of a project.

Top-down or command-and-control methods will prove less 

effective for the next generation, but millennials can be brought 

together for a mission they consider meaningful. Defining the 

mission, and remaining flexible enough to refine and redefine 

it, will create an environment in which leaders will emerge. 

Millennials with effective skills that include leadership abilities 

will emerge as leaders in projects despite aversion to a long-term 

commitment to management as a career.

Discontinuity

The coming retirement of baby boomers will be an upheaval 

unprecedented in size and impact. Organizations that thrive 

will be the ones that use their imagination, adapt quickly to 

change, entice employees with opportunities for learning, and 

retain them because they continue to challenge them and 

empower them to use their knowledge and skills to benefit both 

the organization and their team. During the next few years, we 

are likely to see movement away from traditional annual reviews 

and toward rewards based on project work. It is likely that many 

more “employees” will be or act like freelance workers. The 

workplace will experience increasing shortages of highly skilled 

workers who can engage or lead the most innovative work.

So organizations will face a discontinuity. They will enter a 

world where it is imperative to be a learning organization, where 

employees engage each other in intensive learning experiences 

after they are hired. The most important items on the résumé 

will be proof of the ability to learn, to incorporate, to synthesize 

learning, and to turn new knowledge into new value. Rather 

than a “nice to have” capability, project managers in the future 

will need to balance technical expertise with learning and 

teaching skills. Acquisition of known skills will be important to 

organizations, but the invention and acclimation of entirely new 

skills will be equally so.

Many successful workplaces will be characterized by 

emergent behavior, emergent leadership, and emergent 

communities. The outcomes of many projects may emerge from 

the process of carrying them out. The tension between change 

and consistency can be a source of innovation. The short halflife of technology, high workforce turnover, and political and 

scientific uncertainty will generate emergent opportunities. 

Embracing those opportunities will lead to innovation, 

shunning them to underperformance and uninspired design. 

Being associated with lagging technology will not satisfy the 

tech-infused, chronically attention-shifting millennials. They 

will demand an environment that inspires, one in which they are 

both the aspirants and the inspiration. That will mean a fervent 

striving toward innovation that must be satisfied to retain them. 

This striving may well take the new models of social interaction 

and open innovation in directions that are inconceivable today.

In many ways, this generation will act on what the baby 

boomers already know. The linearity and control promised by 

PERT and Gantt charts have always been something of a myth. 

Rapid global communication and unprecedented transparency 

force organizations to give up even the pretense that long-range 

forecasts and plans are meaningful. Social change, as well as 

technological change, will surprise and confound us. But if we 

accept the value of tools like scenarios to help navigate multiple 

futures, avoid rigid forecasts in favor of futures that emerge 

from the uncertainties that surround us, and encourage and 

employ the talents of our millennials, we may find new doors 

to innovation. ●

As director of Information Work Vision in Microsoft Corp.’s 

business division, DANIEL W. RASMUS guides the research 

process that allows Microsoft to envision how people will work 

in the future. As part of these efforts, he manages the Future 

of Information Work scenario program, represents Microsoft 

on the Board of the Directors for the Institute of Innovation 

and Information Productivity, and helps guide future-oriented 

experiences, like the Center for Information Work.

* Mie Buhl, Bente Meyer, and Birgitte H. Sørensen, eds., Media and ICT—Learning Potentials (Copenhagen: Danish 

University of Education Press, 2006).

ASK MAGAZINE | 33
Intro

Photo Credit: Langley Research Center

APOLLO:

A Young Engineer’s Perspective

BY DAN HOLTSHOUSE 

Lunar excursion module at the Lunar Landing Research Facility.

34 | ASK MAGAZINE | STORY
A complete greenhorn at work, I was put on a team supporting 

the integration of the Apollo Guidance Computer (AGC) 

with the gyro-based inertial navigation platform, which AC 

Electronics supplied. The computer was designed by MIT’s 

Draper Lab and manufactured by Raytheon. Integration 

activities included testing all the components together as a 

system before the complete system was shipped to NASA for 

integration with the launch vehicle. There were two G&N 

systems on board: one on the command module (CM) and one 

on the lunar excursion module (LEM), each requiring its own 

unique systems integration and testing process.

As with any new complex system that has elements supplied 

by various contractors from different parts of the country, 

collaboration, coordination, and communication (the 3 Cs) were 

absolutely critical. We accomplished the 3 Cs primarily through 

face-to-face meetings in Boston and Milwaukee and multiple, 

daily phone conferences to address problems and action items. 

(In the mid-sixties, we had no e-mail or videoconferencing.) 

Because of the physical distances between vendors, we also 

established a program office at Raytheon with our people on 

site to keep up with progress and handle problems. This seemed 

to work well, and we ended up with on-site personnel at several 

other contractor venues throughout the program to reduce 

miscommunication and ensure successful integration with the 

other subsystems. Being there matters.

Final integration testing was done in clean rooms constructed 

especially for the Apollo program. We donned white booties, 

smocks, and caps before entering the test area through an air 

lock. We tested around the clock to meet delivery deadlines, and 

this led to a lot of 3:00 a.m. phone calls from the test crew that 

required one of us from the AGC group to go in and diagnose 

the problem. It took us several months to figure out that more 

than half the system test problems were due to human operators 

making mistakes in test procedures that then put the whole 

system under a cloud. We finally realized that we could shadow 

and record the operator’s entries from a downlink connection, 

and we designed and built a monitor system (Telmons) that used 

a then-state-of-the-art asynchronous tape drive to record the test 

procedures. This eliminated a lot of the late-night calls (once 

they were being recorded, the operators were more careful) and 

relieved us of having to write lengthy reports documenting our 

analysis of why a system problem that could not be repeated 

was due to operator error. (The experience did make me a much 

better writer and required me to learn the workings of the rest 

of the G&N system.)

Before any of the system components went into final test 

in the clean rooms, they were tested at length at the individual 

component level. Here we were learning on the fly. Functional 

testing to see if the components were doing what they were 

supposed to do was fairly straightforward for the AGC and 

inertial platform. We knew, of course, that the equipment 

needed to withstand launch vibration and work in the vacuum 

of space, but we had no idea about the number of ways that 

components that worked fine on terra firma would fail in space 

My first job was on the Apollo program. When I left Ohio State University with a graduate degree 

in electrical engineering, I went to work for AC Electronics in Milwaukee, Wis., then a division of 

General Motors. This division was the prime contractor for the Apollo guidance and navigation 

(G&N) system that was responsible for guiding the Apollo spacecraft to the moon and back. There 

was an air of excitement at AC, and working on the Apollo program satisfied two of my longtime interests—aeronautics and computers. (Aeronautical engineering was my second engineering 

choice, and computers my main focus in electrical engineering.) 

ASK MAGAZINE | 35
Photo Credit: NASA/Dennis Taylor

The Apollo Display Keyboard Assembly (DSKY) used on the lunar module.

at zero gravity. We learned, for example, that a single circuit 

connection out of hundreds in the computer might flex enough 

to cause an intermittent error during the process of “pulling a 

space vacuum” in the large vacuum chamber, only to reconnect at 

full vacuum and not want to repeat itself. To solve this problem, 

we introduced a series of sawtooth vacuum test profiles—

increasing and decreasing vacuum in a sawtooth pattern to flex 

all the components more—on all our tests to ensure we stressed 

the equipment enough to confirm it was defect free. 

We were also concerned about “floaters,” that is, small pieces 

of contamination from manufacture that might lie dormant 

and undetected in all ground tests but become airborne in zero 

space gravity, after being shaken loose during launch, and cause 

a problem during flight. This turned out to be a continuing 

issue for the Display Keyboard Assembly (DSKY), which used 

mechanical relays in those days before the advent of mature solidstate switch technology. The DSKY was the crucial keyboard 

interface to the G&N system that the astronauts used to key 

in data and instructions. We learned that vacuum tests were 

not enough to surface all contaminates when a floater caused 

a failure after successful vacuum tests. We were wondering if 

there was only one floater, or more. We ended up developing 

a procedure to vibrate and shake every module, while powered 

up, on three different axes, to certify that they were free from 

defects and spaceworthy.

Soon after coming on board the Apollo program, I decided 

that I needed to thoroughly learn how the computer system 

worked. I began to study the schematics supplied by MIT but 

found them hard to follow, and I thought they would not be 

much use to the integration software programmers who needed 

to understand the logical operations of the computer system. So 

across several months we reverse-engineered the schematics to 

create a set of logic diagrams that filled an 11 x 17–inch book 

that was an inch and a half thick. Some said, “Why on earth 

36 | ASK MAGAZINE
would you ever want to do that? You must not have anything 

else to do.” But we found during the course of the program 

that “the book” was instrumental in helping us debug many 

integration problems. It also helped unravel a dramatic system 

error during flight. 

As many people know, a computer alarm on the DSKY 

went off during the LEM’s descent, one that basically signified, 

“I’m too busy to do everything you want me to do.” Actually, 

the computer never lost control, having been designed to be 

fail safe and with extra capacity, but since the LEM seemed to 

be heading for an undesirable landing spot, Armstrong took 

over control for a manual landing—and history was made. 

Meanwhile, back at the office, we scrambled to help find out 

what had happened. We used our computer logic statement 

book to see that unintended radar signals were being sent at too 

great a rate and that the AGC operated correctly after all. It was 

said that the Apollo G&N system worked so well that it guided 

Apollo 11 all the way to the moon and back and landed the crew 

closer to the splashdown target than the recovery ship that never 

left Earth’s surface.

Looking back, one thing that strikes me about the program 

was how much focus there was on contingency planning. There 

were redundant systems designed in, there were alternative 

paths identified for performing critical functions if something 

failed, and a lot of software efforts came from NASA Houston 

to test for flight programming weak spots and “what ifs.” We all 

knew the stakes were high if a problem developed after liftoff, 

so a “sustained level of worry” ran throughout our part of the 

program, causing us to test and retest for potential “left-field” 

problems that might occur. We did not want to end up blaming 

ourselves for having missed a potential problem that might have 

been discovered beforehand by thinking and working harder. 

The stress of that responsibility created some worry casualties, 

however. In retrospect, I think we, as coworkers, should have 

been more aware and offered help to those who were not 

handling the stress well.

I was at the Cape for that awesome Apollo 11 liftoff. Even at 

the observation stand a long way from the launchpad, the sound 

of the Saturn V going up was a physical force that pounded me 

in the chest like a one-two punch. It was the last Apollo launch 

that I saw and was the culmination of intense focus for me and 

the others I worked with on the program. Afterward, I was in 

need of a change, so I decided to go back to school for another 

round of study.

Working on Apollo was one of the most exciting times of 

my life. The goal of going to the moon created such positive 

force—a powerful draft of energy that aligned and focused 

the efforts of all those many contractors and people working 

at locations from coast to coast. Like some other national 

initiatives over the decades, the Apollo program continues to 

be a lasting benchmark and example of how to mobilize great 

collective efforts in achieving a challenging goal and vision. 

It shows what can be accomplished when everyone works 

together with common purpose and commitment. It was a 

great ride! ●

I WAS AT THE CAPE FOR THAT AWESOME 

APOLLO 11 LIFTOFF. EVEN AT THE OBSERVATION 

STAND A LONG WAY FROM THE LAUNCHPAD, 

THE SOUND OF THE SATURN V GOING UP WAS 

A PHYSICAL FORCE THAT POUNDED ME IN THE 

CHEST LIKE A ONE-TWO PUNCH.

DAN HOLTSHOUSE is Executive in Residence at George 

Washington University and retired director of corporate strategy 

at Xerox Corporation. 

ASK MAGAZINE | 37
Viewpoint: On a Need-Not-to-Know Basis

BY WILLIAM H. GERSTENMAIER

People have traditionally suffered from a dearth of information. 

The Battle of New Orleans was fought almost two weeks after 

the United States and England officially ended the War of 

1812—it simply took that long for the message to arrive. Thanks 

to modern technology, a lack of information is no longer a 

problem; an overabundance of information is. Technology has 

made it incredibly easy to contact vast numbers of people at 

once: simply type in the name of your office’s distribution list 

and you can let your coworkers know you’ll be out sick today. 

Type in the wrong distribution list address and you can let the 

whole building know, perhaps the whole agency. Unfortunately, 

this simplicity has brought the problem of overload down on the 

modern worker—it can be extraordinarily difficult to separate 

the wheat from the chaff in today’s electronic flow.

During a single week in October 2006, the NASA Headquarters 

e-mail servers delivered approximately 1.25 million e-mails. With 

roughly 1,000 people at headquarters, this works out to 1,250 

messages per person. The nasa.gov domain has approximately two 

million distinct Web pages residing on its servers. This yields roughly 

thirty-two Web pages for every civil servant and contractor in the 

NASA family. How easy is it to find the page with the information 

you need among those two million? How many of those can you 

access without needing a new account username and password? 

Given a choice between too much information and too little, 

almost everyone prefers the former. But too much information 

presents problems that are both obvious and subtle. Arriving at 

your office on a typical morning, you pull up your e-mail to find 

that you’ve received thirty messages overnight. You weed through 

the broadcast messages deciding whether or not they apply to 

you. You sort through the messages from your coworkers that 

you’ve been cc’d on, deciding whether or not they require your 

attention. You read through several e-mails from your boss, each 

also sent to everyone in the office, to determine if there are any 

actions you need to take or information that you can’t afford to 

miss. If you’re quick, perhaps only twenty minutes have passed, 

and yet already you’ve made dozens of decisions about what is 

important and processed a significant amount of information 

with nothing to show for it but a list of what you now actually 

have to respond to. Over time, the constant flow of e-mail 

leads to an inability to focus on a single task for any significant 

amount of time, preventing one from thinking deeply about the 

task and destroying one’s creative thinking abilities. This is one 

of the many problems of information overload.

With instant communication—both at your desktop 

computer and on mobile devices like the Blackberry—comes an 

implicit expectation of a fast reply. In the days of post mail, no 

one thought anything of waiting days or weeks for a response. 

Today, if an e-mail isn’t replied to in an hour, the sender typically 

gets nervous. Why haven’t they responded? Are they out sick? Are 

they ignoring me? Is there something I’m not aware of and need 

to be? Linda Stone, a former executive for both Microsoft and 

Apple and an expert on information management, brought 

attention to this mentality in a speech given in March 2006:

 This always on, anywhere, anyplace era has created 

an artificial sense of constant crisis. What happens to 

mammals in a state of constant crisis? The adrenalized 

fight or flight mechanism kicks in. It’s great when we’re 

A buzzing noise wakes you from your sleep. Opening one eye, you squint at your alarm clock: 

3:00 a.m. The buzzing begins again, followed by a second of silence and a loud thump as your 

Blackberry hits the hardwood floor. It isn’t time to wake up, it’s simply a new message. Thinking it 

could be important, you turn on the lamp, rub your eyes, and reach down to pick up the Blackberry. 

It’s a notice to everyone in the organization regarding a one-day training course being offered a 

month from now. The subject? Improving your time management skills.

38 | ASK MAGAZINE | INSIGHT
Photo courtesy Kerry Ellis

being chased by tigers ... but how many of those 500 

e-mails a day is a tiger? Or are they mostly mice? Is 

everything really such an emergency?

Stone calls this phenomenon “constant partial attention,” 

and it is the true cost of information overload. When even an 

hour is too long to wait for a reply, how can anyone be 

expected to focus deeply and consistently on any 

given task? We need to take time to reflect on 

things rather than just react to them.

Steven Levy, a noted science and technology 

journalist for Newsweek magazine, wrote that 

“a live Blackberry or even a switched-on mobile 

phone is an admission that your commitment to 

your current activity ... is fickle.” He’s absolutely 

correct: if you’re talking to a colleague and the 

Blackberry on your belt vibrates, it’s nearly 

impossible not to grab it and take a look. One is 

afraid to be out of contact for no good reason other 

than that one is always in contact. On the surface, 

you’re just staying current, but what you’ve really 

just done is put the person in front of you on hold 

for an as-yet anonymous e-mail. 

With all the information flowing back and 

forth, how can you be sure you are being effective, 

and not merely efficient? NASCAR racing cars are 

very efficient machines when it comes to making 

left-hand turns at 200 mph. It takes care and 

conscious attention to be sure you’re not turning 

into the NASCAR equivalent in your job: incredibly 

fast and efficient, but inflexible. If you’re thrown a righthand curve, it’s important that you are able to make the turn 

and not have to compensate with three lefts. 

Perhaps you’ve been making left-hand turns for so long 

that you can no longer see the right-hand turn shortcut up 

ahead. With information coming at the average worker at an 

ever-increasing rate, it’s easy to get caught in reactive mode, 

with no real thought given to reflecting on the situation or the 

task at hand. It is difficult to innovate in reactive mode; true 

improvement can only come if you take time for reflection. 

It should be noted that this requires a conscious effort—

opportunities for reflection very rarely present themselves.

Not all aspects of today’s information-saturated society are 

bad. If General Andrew Jackson had been sporting a pager on 

his belt, President James Madison could have saved lives 

with a simple, “Andy: War Over. Thx, Jim.” The 

communication systems we use are not at fault; 

it is how we use them that matters. While not 

everyone in the office needs to know you’ll be 

out sick, some do, and it’s easier than ever before 

to let them know. When the boss is about to 

give an important presentation, you can get 

critical late-breaking information to him or 

her quickly and discretely. Thanks to wireless 

technology, being on the road no longer means 

being out of touch; you’re only as isolated as 

you choose to be, instead of as you are forced to 

be. When appropriately used, technology can 

make everyone more productive.

The key to making information work for 

us, instead of against us, is management. To 

stem the tide of e-mail, data, and all other 

manner of products coming from every 

direction, it is critical to use the tools at your 

disposal to the greatest possible advantage. 

Most e-mail programs have rules and filters 

for classifying and sorting automatically; 

using them will help cut the time you need to 

spend sorting the wheat from the chaff. Metadata, 

an often-overlooked aspect of modern computer filing systems 

(click “properties” on any file to see the metadata), can make 

finding files on an office server quite easy, as well as assist in 

storing information regarding the history of the file, changes 

to it, the original author, and so on. Bookmarks in your Web 

browser can get you to deeply buried Web pages you use often 

much more quickly without navigating through higher levels of 

ASK MAGAZINE | 39
the site. So there are tools you can use to minimize the problem, 

and knowing and using them will give you some control over 

what shows up at your desk. Changing behavior is another 

way to exercise control. Some commentators recommend not 

checking e-mail more than once per hour so you’re not constantly 

interrupting other tasks (or reflection). This also helps break the 

cycle of expecting instantaneous replies.

Finally, it is important to be part of the solution and not 

part of the problem. Common sense and etiquette can cut down 

the amount of unnecessary information more than any tool. 

We’ll use the example of e-mail, but these ideas can be used for 

any information product you choose:

• When sending e-mail, think carefully about whom you’re 

addressing it to. It is the de facto standard operating 

procedure in many organizations to send out as much 

information as possible to as many people as possible. 

But think about how many e-mails you get that were 

sent to your entire staff that really affect only one or two 

people, yet everyone else had to spend time reading and 

deleting it. It is the sender’s responsibility to determine the 

proper distribution, rather than the receiver’s to dispose of 

irrelevant messages.

• Focus on the actual content of your e-mail. Forwarding 

a long string of replies to someone who has not been 

involved thus far puts a burden on the recipient to figure 

out what is going on. The sender should summarize 

the correspondence and include the originals only as 

background information, if at all. Also, when forwarding 

a file, it’s useful to let the recipients know what is in the 

file, rather than sending an e-mail with no text and a 

single, attached file. When forwarding a .guh file, ensure 

that your target has the ability to read .guh files, lest they 

get it, find it unreadable, and (guh!) ignore it. Again, the 

burden is on the sender, not the recipient, to make the 

proper decisions.

• Concentrate on the timeliness of your e-mail. If you need 

a response in the next ten minutes, an e-mail is not the 

proper mode of communication; pick up the phone or go 

in person. Similarly, if you don’t need a reply for three 

months, the e-mail can probably wait—the recipient 

almost certainly has enough things to track and manage. 

With the amount of e-mail bouncing around, proper 

timing on the sender’s part can help ensure that the 

recipient dispositions the information properly.

• Finally, think about why you’re sending the e-mail in the 

first place. It’s common sense not to send an e-mail in 

anger, but consider the more mundane e-mails that make 

up the bulk of our correspondence. How often have you 

read a message and thought to yourself, what was the 

point of that? Did anyone need to read that? Pointless and 

time-wasting e-mail will forever be part of our work and 

personal lives, but taking some time to think about the 

point and relevance of your missive will help ensure no 

one at the other end is scratching his head and cursing 

your name.

Albert Einstein once said that information is not knowledge. 

The amount of information washing over the average desk 

within NASA today is staggering, and none of it means anything 

without some effort on the recipient’s part to bring context to 

each piece of information so it can be dealt with effectively. The 

speed at which information is arriving can create a frenzied pace 

that, left unchecked, can lead to constant partial attention and a 

significant loss of productivity, both in the workplace and in one’s 

personal life. It is the responsibility of each individual to ensure 

that each byte is effectively transmitted, such that communication 

is truly improved. Careful management will enhance your own 

and your coworker’s productivity, and it will contribute in a large 

way to the success of the mission as a whole.

Failing that, there’s always the “delete” key. Assuming the 

letters haven’t worn off. ●

Recommended reading: Peopleware: Productive Projects and 

Teams, by Tom DeMarco and Timothy Lister; Slack: Getting 

Past Burnout, Busywork, and the Myth of Total Efficiency,

by Tom DeMarco; The Paradox of Choice: Why More Is Less,

by Barry Schwartz.

WILLIAM H. GERSTENMAIER is the associate administrator 

for Space Operations. In this position, he directs NASA’s human 

exploration of space. He also has programmatic oversight 

for the International Space Station, Space Shuttle, space 

communications, and space launch vehicles.

THE KEY TO MAKING INFORMATION WORK FOR US, INSTEAD OF AGAINST US, IS 

MANAGEMENT. TO STEM THE TIDE OF E-MAIL, DATA, AND ALL OTHER MANNER OF 

PRODUCTS COMING FROM EVERY DIRECTION, IT IS CRITICAL TO USE THE TOOLS AT 

YOUR DISPOSAL TO THE GREATEST POSSIBLE ADVANTAGE.

40 | ASK MAGAZINE ASK MAGAZINE | 40
EINSTEIN

BY MARC SPIEGEL 

for Children

Spiegel, as Einstein, interacts with students.

Photo courtesy Marc Speigel

STORY | ASK MAGAZINE | 41
I am not a scientist or engineer. I am a storyteller, a writer of 

sorts, often of rhyme, and a mostly self-taught performer with 

an audience-participatory style learned on the streets of San 

Francisco in the 1970s. But I have always had a sense of awe 

about the universe. My difficulty with math and my unfortunate 

experience with high school physics discouraged me from 

pursuing science and gave me a fuzzier view of the cosmos than 

a scientist might have. I have always found nontechnical books 

on physics fascinating and inspirational, though I rarely retain 

technical details.

In 1995, I was a storyteller sharing mostly original tales in 

schools up and down the East Coast. One way I promoted myself 

was by attending showcases where school representatives came 

to watch ten-minute presentations. I heard about a showcase in 

Queens, New York, run by a colorful arts-in-education promoter 

named Joan Lavin. When I called her, she said I could be in her 

showcase but told me she could get me more work if I played a 

historical character. 

I was married with two young children and a mortgage. 

More work sounded like a reasonable idea, but it would require 

me to stop what I was doing and dedicate myself to researching 

the life of another human being. Which one? The answer came 

quickly: Albert Einstein. I have always remembered the newspaper 

headline the day he died. I was very young and knew nothing 

about science, but I understood that someone very important had 

passed away. When I told Joan of my choice, she said, “I guess 

that will work, but don’t do the science.” I was not ten minutes 

into my research, however, before I found Einstein telling me, 

“Personal facts are not important to understand a man like me. 

What is important are the adventures inside my mind.” Science 

had to be the centerpiece of any Einstein portrayal I might do. 

I immediately saw two challenges. Audience participation 

is the heart of my performance style; I felt this performance 

had to be a visit with Einstein in which he would talk about 

his life and the adventures in his mind and answer questions 

from the audience. Somehow I had to develop the confidence 

to become Einstein and present him as alive and vibrant. The 

second challenge was the science. I had to learn enough about 

Einstein’s scientific thinking to find a natural, entertaining, and 

understandable way of presenting it to my young audiences. 

I began to read everything I could about and by Einstein, 

which was a great deal indeed. I solved the first challenge by 

having Einstein inform the audience that he was dead: “They 

have dredged me up again!” (I presented the idea more gently to 

my elementary school audience: “Don’t worry, I am not a ghost! 

I won’t go ‘boo’ to you. / The actor fixes up his hair and puts the 

mustache on with glue.”) This would be Einstein brought back 

to life by the actor/storyteller Marc Spiegel. If Einstein ever had 

trouble answering a question, he could always blame Spiegel. 

Learning and presenting the science was the greater 

challenge. I made two important discoveries in the process. 

First, when experts explain something, they often leap over 

information they consider to be elementary. I have been stopped 

in my tracks by the simple phrase from which we derive placed 

Explaining to other people something complicated that you are working to understand yourself 

can be difficult. That was my situation when I began developing my Einstein Alive! program to 

introduce Einstein and the theory of relativity to students from kindergarten through middle school. 

Now, years later, I have performed the show for enthusiastic audiences from the Arctic Circle to the 

Florida Everglades. Developing the performance has taught me a great deal about teaching and 

understanding. I think my experience may offer some useful hints to technically savvy people who 

need to communicate their expertise to others.

42 | ASK MAGAZINE
between two equations where I see no obvious connection. This 

happens with verbal explanations as well. It’s an easy trap to fall 

into; I initially made my own similar assumptions about what 

my young audience knew.

Fortunately, different writers make different leaps; if you 

read enough explanations, you can usually fill in the gaps. 

Herein lies the best advice I have learned from Einstein: the two 

most important qualities a scientist must have are curiosity and 

determination. 

The second thing I discovered was that most physicists are 

generous with their time and delight in answering questions. 

I especially thank Dr. William Parke at George Washington 

University who, among the countless ways he has helped me, 

pointed out an assumption I was making. I assumed my young 

audience knew what friction was when his college students’ answers 

on exams showed that they sometimes did not. That insight led to 

one of the most successful sequences in my presentation.

As I gained familiarity with the science, I became more and 

more concerned about how to present it to children. This led 

me to try to explain the material while I was still learning it, 

which, I found, greatly aided my own learning process. Indeed, 

I have come to believe that if you want to learn any subject, start 

teaching it to children. 

The rudimentary level of my knowledge actually became 

one of my greatest assets. I had to start on the most fundamental 

level. To explain the theory of relativity, I first had to vividly 

explain what the word “relative” meant. I talked about relativity 

with everyone I met, mostly people who had not opened a 

scientific book in decades. Along the way a good friend, singersongwriter Michele Valerie, joked that kids in my audience 

would probably say, “Relative? I have an Aunt Rose who’s a 

relative.” That’s where I began. 

In retrospect I realize that I wrote this show as I might write 

a story. The ideas that the audience must understand are like 

characters in a story. “Relative” was my first character. I needed 

to introduce this character to the audience in a way they could 

easily identify with: “Is anyone here a relative? Does anyone here 

have a brother or a sister?”

Suddenly, Einstein is not lecturing about science, he is asking 

a personal question: “Who here has just one brother or sister and 

that one brother or sister is younger than you? Were you a brother 

before your sister was born? No. Your being a brother depends 

upon your sister being born. It depends on something else. That 

is what the word ‘relative’ means: to need something else.” 

I introduced “relative” as something familiar—a brother 

or a sister. But this character “relative” has more layers. Einstein 

goes on to say, “Other things are relative. Tallness is relative. 

Am I short or am I tall?” Ninety-nine percent of the time one 

or two students in the audience will call out “short,” which 

offers a valuable tool in teaching anything: humor. “Who 

said ‘short?’” Einstein asks indignantly, bringing one or two 

students up to stand next to him. What is relative now is not 

Marc Spiegel explains the theory of 

relativity with the aid of a young participant.

Photo courtesy Marc Speigel

ASK MAGAZINE | 43
a sibling, but the more abstract concept of tallness. Einstein 

shows that relative to the students, he is tall, but relative to the 

ceiling, he is short. 

I introduce the second character in the story as Einstein 

concludes: “When something is relative, you cannot understand 

anything about it unless you compare it to something else; this 

something else is called a frame of reference.” Einstein has the 

students on stage stretch out their arms out and make a frame 

with their index fingers and thumbs. 

“If I place the frame around just Nicholas and myself, then 

I am a little tall, but if I place it around the ceiling and myself, 

then I am very short.”

Then I introduce my third character, motion, and the 

problem of motion. For this I created a 3 ́ x 3 ́ platform on 

wheels with a brake lever, a push rod, and a chair bolted to it. 

The machine rolls parallel to the audience, and anyone sitting 

in the chair faces the audience. 

Most people do not think that motion has a problem. 

Einstein, however, presents it as one in his Evolution of Physics, 

and that is how I wanted to introduce the theory of relativity: as 

a solution to a problem, the answer to a puzzle.

The basic premise of relativity is that moving and standing 

still are the same with regard to the laws of physics. My Einstein 

starts his story by showing first that moving and standing still 

have something in common: both require a push or a pull from 

something else. A push or pull makes something that is standing 

still move and makes something that is moving stop. Einstein/

Spiegel demonstrates this by pushing and pulling the machine, 

by pantomiming how we walk, hit a baseball, and slam a door.

At this point Einstein has explained what relative means, 

what a frame of reference is, and that moving and standing still 

have something that is the same about them. There is one more 

step to take. Moving and standing still are so much the same 

that you can be moving and standing still at the same time. This 

is because all motion is relative. Indeed, all motion is relative to a 

frame of reference. A teacher sits on the chair that is bolted onto 

the machine, Einstein sits on her lap, and as a student pushes the 

machine across the stage, Einstein sings:

Relative to you now I am moving, 

for that you need no map

But relative to Ms. Padgorndny, I’m not moving

I’m sitting still right in her lap.

That is the basic story of the elementary school program. The 

middle and high school programs go on to the constant speed of 

light and the resulting puzzle of relativity. Einstein now has two 

clear frames of reference to work with: the frame of reference of 

the room and the frame of reference of the machine. Now it is 

possible to talk of observers in each frame of reference measuring 

the speed of a person walking or a beam of light streaking between 

them. This leads directly to Einstein’s explanation that time and 

space are different forms of the same thing and arrange themselves 

in every frame of reference in such a way that the speed of light is 

always measured the same by everyone.

Are there lessons in my experience for “explainers” who 

don’t perform in schools? I don’t mean to suggest that real 

scientists should use song and pantomime to communicate their 

ideas, but I think many of the same basic principles apply: don’t 

assume your listeners know everything you consider obvious; 

look for vivid, everyday analogies to explain difficult concepts; 

interact with your audience; and use the power of story—its 

potential for mystery, suspense, humor, and engagement—to 

reach your listeners. ●

For more stories and answers from Spiegel/Einstein, visit 

http://www.marcspiegel.com/videos/videoquestions.html.

MARC SPIEGEL began writing and performing stories in 

narrative verse as a political science graduate student at 

Harvard. He has appeared on television, at schools, festivals, and 

corporate events. He has performed at several venues, including 

the Kennedy Center, the International Children’s Festival, and the 

Smithsonian Institute, and he was a featured performer in the 

White House Millennium Celebration.

THE RUDIMENTARY LEVEL OF MY KNOWLEDGE ACTUALLY BECAME ONE OF MY GREATEST 

ASSETS. I HAD TO START ON THE MOST FUNDAMENTAL LEVEL. TO EXPLAIN THE THEORY 

OF RELATIVITY, I FIRST HAD TO VIVIDLY EXPLAIN WHAT THE WORD “RELATIVE” MEANT.

44 | ASK MAGAZINE
BY HUGH WOODWARD

STORY | ASK MAGAZINE | 45
The project had started a couple months earlier when the City of 

Oxnard demanded that the plant, which produced paper towels 

and toilet tissue, reduce its water consumption by 10 percent. 

A paper plant may be an easy target for politicians seeking to 

please an electorate, but our plant in Oxnard was already the 

most efficient of its kind in the world. Reducing consumption 

further was not going to be easy. Nevertheless, the company, 

sensing no room to negotiate, agreed to comply and appropriated 

funds to develop and install the necessary technology. Realizing 

the complexity of the task, they selected a project manager with 

years of experience in paper manufacturing: me! 

Unbeknown to me and them, they had also selected a naïve 

project manager. I had no idea how difficult the assignment 

would be until I convened a project team meeting that sunny 

morning in Oxnard and asked a few routine questions.

“What is the scope?”

“Well, we are planning to re-use more waste water, reduce 

evaporation from our cooling towers, and install low-flow 

toilets.”

“What?” I asked incredulously. “Low-flow toilets? They will 

save perhaps gallons a day. We are looking for over a hundred 

thousand gallons a day.”

The team explained that the city had mandated low-flow 

toilets as part of the scope, presumably in an effort to be helpful.

I asked for details about the changes and soon learned they were 

all quite experimental. Even technology in use at other paper plants 

was not proven in our particular process. My anxiety increased 

when I started asking questions about current consumption.

“How much water are you consuming now?”

“We don’t know.”

“What do you mean ‘you don’t know?’”

“Well, we don’t have meters on all our lines.”

“But the city must know how much you are using. How 

will they know you have achieved the 10 percent reduction?”

“They won’t!”

They explained that, because the plant treats its own water, 

it draws water from a trunk line upstream of the city’s treatment 

facility. There was simply no provision for metering.

Resisting the temptation to suggest we do 

nothing and tell the city we had achieved the 

objective, I moved on to another subject that seemed important. 

I knew the plant was in the middle of a major expansion. 

In fact, they expected to more than double production within 

six months.

“How is the city thinking about that?” I asked.

“Well, we never discussed the expansion specifically, but 

we think they are expecting us to consume 10 percent less than 

what we would have done if we did nothing.” 

Finally, I asked about the water consumption in the orange 

juice facility. Several years earlier, the company had been looking 

to expand its production of orange juice on the West Coast and 

decided to site its manufacturing facility at Oxnard adjacent to 

its paper plant. Nobody knew. In fact, nobody on my project 

team knew anything about the orange juice operation, and they 

certainly had no idea how much water it consumed.

The immediate dilemma was how to get started. We clearly 

I remember the day I walked into the paper plant in Oxnard under a brilliant southern California 

sun with a pleasant cooling breeze blowing off the Pacific. I was reveling in the opportunity to work 

on an interesting little project far from the wintry weather in Cincinnati, Ohio. An hour later, I was 

utterly depressed. I had just been given an impossible assignment.

46 | ASK MAGAZINE
had to install meters and establish a baseline. And there was 

nothing stopping us from installing those low-flow toilets. 

But what could we do beyond that? How were we to deal with 

all the unknowns? Every attempt to establish a project plan 

deteriorated into arguments about the expansion, the orange 

juice facility, and whether or not the new technologies we were 

planning to install would work.

We eventually decided the only way forward was to make 

some assumptions. We called them “critical assumptions.” For 

example, we assumed the orange juice facility would make no 

contribution toward the 10 percent reduction. We also assumed 

the new production lines would consume the volume of water 

predicted by the design calculations. And we assumed the 

low-flow toilets would make no measurable contribution to 

our conservation target. We had no way of knowing if these 

assumptions were correct, of course, but they created boundaries 

that allowed us to establish a scope and eventually a project plan.

We knew we needed to check the validity of our critical 

assumptions periodically. We assigned project team members to 

each assumption and charged them with checking validity prior 

to each monthly team meeting and reporting their findings 

during the meeting.

With a logical framework now in place, we proceeded 

with execution. We installed meters on the incoming header 

and established a baseline that the city accepted. We also 

installed meters on every major line within the plant to 

measure consumption in each part of the facility. The 

only area that proved difficult to measure was the orange 

juice facility. As the team member responsible for metering 

explained, “The orange juice facility uses a lot of water when it 

runs. The problem is, it runs sporadically and not very often.” 

Eventually, we acquired enough data to determine the average 

consumption of the facility was a little more than 100,000 

gallons per day. 

We also studied each of the conservation ideas and developed 

estimates of the amount of water they would save and the cost 

of installing them. Eventually, we had a menu of options that 

would give us some choices about how to achieve the mandated 

reduction within our budget. We even developed a list of 

contingencies should some of the conservation ideas deliver less 

than expected. Oh, and we installed those low-flow toilets!

Our project team meetings settled into a routine. Each 

began with a review of our critical assumptions. For the first 

few months, we found no reason to change them. We then 

reviewed each of the conservation ideas. As new information 

came to light, some dropped off the list. Others continued to 

look promising. We adjusted our scope accordingly. Overall, we 

remained cautiously optimistic.

Some nine months after my initial visit, I traveled back to 

Oxnard for a project team meeting I had no reason to suspect 

would be any different. After the usual preliminaries, we began 

our review of our critical assumptions. 

“The new lines are now in production. They are not yet 

operating at target rate, but they appear to be consuming the 

amount of water we predicted. This assumption still seems to 

be valid.” 

ASK MAGAZINE | 47
“We have now converted all our restrooms to low-flow toilets. 

We have not seen any resulting change in total consumption. 

This assumption remains valid.”

Eventually it was time for the team member monitoring 

the orange juice facility to report. “Please keep this confidential 

as it has not yet been announced, but the company has decided 

to exit the orange juice business. The production facility 

here will close in less than six months.” Our jaws dropped. 

We immediately referred to the consumption data on our 

spreadsheets and saw that, incredibly, the impact would be just 

enough to achieve our target. All that remained was to close 

the project, report the reduction to the city, and return the 

unused funds to the company.

Not unexpectedly, some project team members disagreed. 

They argued the company had appropriated funds to install 

specific equipment and that we were obligated to install it. Others 

asserted we were obligated to achieve a 10 percent reduction 

beyond closing the orange juice facility. Some wanted to continue 

until the facility was in fact closed, in case the company changed 

its mind. But eventually we decided the project and the project 

team existed for one purpose only: to satisfy the city’s mandate 

that the plant reduce its water consumption by 10 percent. That 

mandate had been fulfilled.

So we got a lucky break, but there is no doubt that our 

decision to establish and monitor critical assumptions was 

key to our success. Without these assumptions, we would 

likely have spent months arguing about issues we couldn’t 

definitively understand early on, thereby failing to define a 

logical project plan. And without our monthly review of their 

validity, we might have wasted time and money pursuing flawed 

options. Without that careful monitoring, we would certainly 

have continued spending money on unnecessary technology for 

at least another six months, without realizing our job was done.

Fortunately, that was not the case. The plant achieved its 

water conservation target. The company got most of its money 

back. The project team learned a new approach to managing 

projects with high uncertainty. And I traded some dreary 

Midwest weather for southern California sunshine. All in all, it 

was a huge success! ●

HUGH WOODWARD practiced project and program management 

for more than twenty-five years at the Procter & Gamble Company, 

and he is a former Chair of the Project Management Institute. 

As President of Macquarie Business Concepts he now helps 

companies eliminate unproductive effort and unnecessary costs. 

48 | ASK MAGAZINE
ASK Bookshelf

The Ten Faces of Innovation: IDEO’s Strategies for 

Beating the Devil’s Advocate and Driving Creativity 

Throughout Your Organization, by Tom Kelley 

with Jonathan Littman (New York: Currency/

Doubleday, 2005)

As an award-winning innovation and design firm, IDEO 

creates new products and capabilities through observationbased research. Their successful designs include the first 

production mouse for Apple’s Macintosh computers (1981), the 

Palm V connected organizer for Palm Computing (1999), and 

Bank of America’s “Keep the Change” banking account service 

(2006). The design firm attributes its impressive track record to 

multidisciplinary teams and a collaborative culture combined 

with a methodology incorporating user observation, creative 

brainstorming, and prototyping. 

IDEO’s Tom Kelley and Jonathan Littman describe ten 

roles, or personas, that they believe nurture innovation and 

protect against the insidious influences of the devil’s advocate. 

According to the authors, the three “learning personas” 

continually motivate themselves and others with new ideas. 

The Anthropologist brings tremendous powers of observation 

to form unique insights into human factors that solve problems. 

The Experimenter prototypes new ideas and takes calculated 

risks to find the next innovative breakthrough. The CrossPollinator applies new ideas from seemingly unrelated fields or 

diverse backgrounds. The authors give the example of escalators 

originating from a Coney Island amusement ride.

“Organizing personas” help new ideas survive time and 

budget pressures. The Hurdler overcomes challenges through 

perseverance and turns obstacles into opportunities (sometimes 

by bending the rules). The Collaborator’s great enthusiasm 

and diplomatic skills bring interdisciplinary teams together. 

The Director orchestrates continuous innovation efforts by 

gathering talented employees into effective teams and serving 

as a creative catalyst. 

The “building personas” help create conditions in which 

new ideas grow. The Experience Architect creates experiences 

that motivate and delight. The Set Designer reinvents the work 

environment to inspire innovation. The Caregiver provides a 

supportive human-centered setting. The Storyteller makes an 

emotional connection through myths to convey information 

and provoke thought.

Kelley and Littman explain that the devil’s advocate 

appears regularly in the project rooms and boardrooms of 

corporate America, encouraging “the most negative possible 

perspective, one that sees only the downside, the problems, 

the disasters-in-waiting.” Their view of the devil’s advocate 

differs from other noted authors in the innovation arena, who 

laud the role as a positive pressure point for guiding new ideas. 

According to Kelley and Littman, the devil’s advocate kills 

new ideas. The ten nurturing personas counter that negativity 

with innovative possibilities. 

Kelley also notes that individuals may take on multiple roles 

or switch roles depending on their context. The personas cannot 

guarantee innovation, and not every successful innovative group 

will include all ten, but the book provides insight into the 

sources of innovation that NASA readers can usefully apply to 

their own groundbreaking work. ●

Here is a description of a book that we believe will interest ASK readers.

ASK MAGAZINE | 49
The Knowledge Notebook

Taking a Knowledge Perspective

BY LAURENCE PRUSAK

In our Western culture, to manage means to 

control. Especially in organizations, management 

of traditional resources like land, labor, and capital 

means being able to count and measure them, 

move them around, buy and sell them, and, in 

general, have complete control of them. It’s not 

surprising that many business schools use the word 

“control” to describe their accounting courses. And 

“command and control” is an approach, borrowed 

from the military, that defines the way most large, 

twentieth-century organizations function.

The control mind-set has always presented a 

real challenge to what has been called knowledge 

management. Clearly, knowledge is a very different 

kind of thing from those other, traditionally 

recognized sources of wealth. Knowledge is 

intangible and invisible, and there is rarely 

agreement within organizations as to exactly what 

it is. Yet it is what differentiates one organization 

from another. NASA knows how to do some things 

that no other organization knows how to do. 

Individual knowledge is aggregated and bundled 

into capabilities and capacities that allow NASA, 

for example, to launch the Space Shuttle or design 

spacecraft to explore the outer planets. The same 

holds true for countries, firms, and any other social 

organism that is directed toward a specific goal. 

Knowledge gets them where they want to go.

But when organizations, recognizing that 

knowledge is a critical resource, try to do something 

about their knowledge, they run into the control 

dilemma that is probably inherent in the term 

knowledge management. Managers naturally try 

to manage it. This is exactly what often happened 

in the first decade of what came to be called 

knowledge management. Organizations that came 

to believe that developing and using knowledge 

effectively was vital to their success tried to use all 

the tools at their disposal to manage it—that is, to 

control it.

Those attempts led to much frustration and 

wasted effort. You can’t manage, in any traditional 

sense of the word, what you can’t see, count, 

move, or even clearly define. And knowledge—so 

much of which resides in the heads and hands 

of individuals and groups and has meaning in 

particular contexts—is especially resistant to 

outside control.

But we do need to find ways to increase the 

efficiency and effectiveness of knowledge work. 

We need to encourage knowledge seeking and 

sharing. We need to provide favorable conditions 

for innovation—that is, the creation of new 

knowledge. At NASA, successfully turning the 

new Vision for Space Exploration into a reality 

will depend on making the most of our knowledge 

resources and sharing and developing knowledge 

effectively with contractors. We have to pay 

attention to knowledge.

But if control doesn’t work, what should we be 

doing?

Well, one place to start is to talk more about 

a knowledge perspective and less about knowledge 

management. A knowledge perspective emphasizes 

appreciating the value of knowledge, using it as 

best as one can, talking about it, and striving to 

work with it, while recognizing that it cannot be 

neatly packaged in databases or made to thrive 

by executive order. Such a perspective could 

counteract and, eventually, replace misguided 

attempts to manage knowledge by using all the 

wrong tools.

50 | ASK MAGAZINE
What would this mean in practice? Here are a few recent 

examples of applying a knowledge perspective that I am aware of:

• Explicitly making knowledge a key input and output 

of project work. This includes trying to identify what 

knowledge is needed to accomplish a project, determining 

how it can be obtained and used, and devising ways of 

retaining project knowledge and communicating it to other 

projects that could use it, emphasizing shared experience 

and direct contact over lessons learned databases.

• Using knowledge in the form of stories and cases to give 

employees a rich understanding of their organization’s 

values and culture. Both NASA and Petrobras, the 

Brazilian energy firm, do this well.

• Using organizational design to better develop and exploit 

knowledge. This includes fostering practice-based 

or theme-based knowledge communities. Northrup 

Grumman and Fluor are two firms that invested in 

community development and support.

• Evaluating workers in terms of their effective use of 

knowledge and promoting the outstanding performers. 

Effective knowledge use can mean anything from 

mentoring, which is often focused on knowledge as to 

how the organization works, to developing, seeking, and 

sharing more technical or domain-oriented knowledge.

This list could go on and on, but I think you get the point. 

Think about the importance of knowledge in any operation you 

are involved in and how it is being used. Then try to imagine 

how it could be used better—without worrying about measuring 

its exact features or attributes or thinking you need to build an 

elaborate system to capture or control it. Just do it. You will find 

the effort well worth your time and you will be well on the way 

to developing your own knowledge perspective and making the 

most of this essential resource for work. ●

A KNOWLEDGE PERSPECTIVE 

EMPHASIZES APPRECIATING THE VALUE 

OF KNOWLEDGE, USING IT AS BEST 

AS ONE CAN, TALKING ABOUT IT, AND 

STRIVING TO WORK WITH IT, WHILE 

RECOGNIZING THAT IT CANNOT BE 

NEATLY PACKAGED IN DATABASES OR 

MADE TO THRIVE BY EXECUTIVE ORDER.

ASK MAGAZINE | 51
ASKinteractive

For More on 

Our Stories

Additional information 

pertaining to articles 

featured in this issue can 

be found by visiting the 

following Web sites:

• Cosmic Background 

Explorer (COBE): 

http://lambda.gsfc.nasa.

gov/product/cobe/ 

• Wallops Flight Facility: 

http://www.nasa.gov/

centers/wallops/home/

• Cassini-Huygens: 

http://www.nasa.gov/

mission_pages/cassini/

main/index.html

feedback

We welcome your comments on what you’ve read in this issue of ASK and your suggestions for articles you 

would like to see in future issues. Share your thoughts with us at http://appel.nasa.gov/ask/about/write.php.

Reminder: PM Challenge 2008

Don’t forget to register for NASA’s PM Challenge 2008, the Agency’s fifth annual project management 

conference. It will be held February 26 and 27, 2008, in Daytona Beach, Fla., near the Kennedy Space 

Center. The conference will feature several tracks, including High-Performance Teams, Mission Success 

Stories, Global Perspectives, Risk Management, and much more. The awards for Software of the Year 

and Invention of the Year will also be presented at the conference. Registration opens November 14. 

For more information, and to register, visit http://pmchallenge.gsfc.nasa.gov.

Web of Knowledge

The NASA Engineering and Safety Center, or NESC, provides independent testing, analysis, and 

assessments of NASA’s high-risk projects to ensure safety and mission success. Supported by a team of 

technical specialists from the ten NASA Centers and from a group of partners and organizations outside 

the Agency, NESC delivers technical reports and lessons learned that are shared with NASA’s leadership. 

NESC also engages in proactive investigations to identify and address potential concerns before they 

become major problems. Read more about NESC at http://www.nasa.gov/offices/nesc/home/index.html. 

2007 APEX Award for ASK Magazine

ASK Magazine won a 2007 Award of Excellence in the Nineteenth Annual Awards for Publication 

Excellence Competition. The Awards for Publication Excellence (APEX) were based on excellence 

in graphic design, editorial content, and the success of the entry, in addition to achieving overall 

communication effectiveness and excellence. Visit http://www.apexawards.com for more information 

about the awards.

NASA in the News

The Project Management Institute (PMI) recognized NASA as one of “25 Outstanding Organizations 

in Project Management” in its October 2007 issue of PM Network (Volume 21, Number 10). Earlier this 

year, PMI invited organizations to submit nominations through an online process. They were looking for 

companies, not-for-profit organizations, and government entities that had achieved the following: 

• Developed a project management career path

• Pioneered best practices or demonstrated innovation in project management principles

• Acknowledged project management at the executive level 

• Attributed continuous improvement or return on investment to project management practices 

• Placed value on project management credentialing

Find out more about PMI and PM Network at http://www.pmi.org/Resources/Pages/PM-Network.aspx. 

52 | ASK MAGAZINE
Not yet receiving your own copy of ASK?

To subscribe, send your full name and preferred mailing address 

(including mail stop, if applicable) to ASKmagazine@asrcms.com.
National Aeronautics and Space Administration

NASA Headquarters

300 E Street SW

Washington, DC 20546

www.nasa.gov

NP-2007-10-476-HQ