Much of the work we do at NASA is truly world-class and routinely we push the capabilities of science and engineering by leading the way. Lately, I’ve thought a lot about how we can push the envelope of our engineering work to improve how we build spacecraft at NASA Goddard, where I work.
But I find that often we are like the mad scientist who invents new technology that is going to change our lives, but can’t seem to find his wallet. It seems that we often cannot do some very practical, day-to-day activities to keep our “capability engine” well tuned, poised, and ready to strike at solving the next big problem.
I think there are tremendous opportunities for us at Goddard and more broadly across NASA to improve our process of the way we do engineering and to introduce some new tools that will substantially allow us to stop re-inventing the wheel and focus more on solving the titan challenges we face everyday.
There are three areas which I believe can tremendously help. They are the title of this article. I will dive into each of them below.
1) respect for data
I find that we are kings of silos. We have a separate, monolithic IT system for everything we do. This is not a unique approach — both industry and government weigh the options for tools to do our work, and often come to very different conclusions, depending on the schedule, manpower, and budget factors at play. But where I feel we fall short is that we do not think of our systems from a truely life-cycle perspective. What I mean is that we look at solving the engineering problem, but do not look at the larger implications of how we can keep our “capability engine” well tuned. We seem to see the data and information we work in on a daily basis no differently than a disposable ketchup wrapper — we feel it is simply for our pragmatic use to accomplish the engineering task for the day, but we forget that it has value in the knowledge in the larger organization. What if we were to actually treat the data and information more like an heirloom which we treated with care and made sure to give it a good home which others could benefit from down the road? I think this could have tremendous implications. I know this description is quite vague and is not any call for a particular way of doing things, but I do not believe I know enough to specify a call. I simply believe that that if we respected our data and information, and ultimately knowledge, that we would have a more long-term and wholistic view of the data and information we product as an effect of our day-to-day work as engineers, instead of treating it like dust under our feet.
2) culture of openness
“It’s very political” is a phrase I hear quite often at Goddard to describe when some process has slowed down to make its progress indiscernible. Unfortunately, I believe some get so caught up in the unavoidable politics, that they use that as an excuse to clamp down on advertising the good work they are doing. Perhaps they fear getting their funding taken away, or perhaps they feel they make be “discovered” by headquarters, or perhaps what they are doing may become institutionalized, potentially killing it. Whatever the reason, I believe some people have learned that the best way to operate is “under the radar.” What I believe this causes is a side-effect of paranoia, which gets in the way of our innocent nature of simply sharing by default. Certainly on a one or two person basis, most engineers at Goddard will give you a full run down of a situation. But in front of a group, their story slowly changes. I believe this politics is not unique to the government, but exists in any organization which comprises over 5 people. And I do not think we should try to eliminate it, its innate to the way any organization makes decisions when it has to weigh many factors.
But, I believe there is great potential to share information as I have laid out in the “Respect for Data” section previously. But if people have learned to fight their innate nature for openness, I believe that potential will never be realized. I think the solution is to short circuit the politics by incentivizing openness for our engineers at Goddard. How do we make openness so attractive that the alternative is outweighed 3-to-1? I do not have an answer, but I have a feeling that this process comes slowly with small wins.
3) social software
The web has evolved tremendously in the last few years, more than anyone could have predicted — even those who followed the tremendous steps forward of the early web. What the web allows is a democratization of information, whether it be personal or business. Facebook, twitter, and other sites have raised the level at which we interact with each other on the web. I say “with each other” instead of “with a computer” because the fundamental shift in the last decade on the web is that it does not just enhance an old activity, it transforms the old mechanistic activity to a deeper personal connection with others. What this allows is a interaction with others that mirrors more the “in-person” interaction than previously possible. So instead of just sharing words over email, I can tie into imagery, and a fully threaded conversation with identity which now allows me to track the progress of a discussion or look back at pictures of friends from many years ago, as it is all now cataloged on the web. And of course these are very simple examples of very rich interactions that these technologies enable every day by thousands of organizations.
You may ask what this has to do with engineering process and work? Everything. I believe the social web has tremendous possibility to provide the incentive I mention above for openness. If you give people the mechanism to democratize an idea and level the playing field, I believe then a culture of openness can flourish, because our engineers will realize that as they give one piece of their valued engineering data, they get back many fold. Imagine for a moment, if every engineer at Goddard posted the top 5 equations, tools, or principles that guide the way they do their work. As unbelievable as this may be for ever happening, imagine if it did. Wouldn’t that be a huge resource for everyone else for insight into the way others did their work? I’m not trying to say that the complex engineering we do can be reduced down to a formula, but which I believe this type of thing would do is give everyone insight into each others’ work and jump start an openness revolution.
Now finally, imagine if we were to take the engineering processes that we perform to execute our design challenges and adapt them for the social web. Now imagine a system which at least partially self-documents in that the record of the WHY of our work and not just the WHAT is fully documented in threaded conversation. Now with some simple framework, we could start to categorize and organize this information and we would be able to start to grasp the emerging concepts of the next generation of engineering process, which does not exist in any textbook yet. (By WHY I mean, the reasoning behind a technical decision, and by WHAT I mean the technical decision itself. The WHY is often something that is very difficult to pick up from existing documentation, but is often the most important question, because that is what involves our engineering problem solving.)
what I looking for from you
I am writing these ideas down to try to get feedback from others who have one foot in engineering within the space community and the other within seeing the potential at the intersection of technology and culture. Please comment below. Forward this post to friends and colleagues you may think would be interested. My ultimate aim is to develop the “game changing” incentive for our engineers to open up about their innovative work and ideas and to consider adopting the use of a new tools which may transform the way we do our business of scientific discovery.
what am I up to?
I am an Information Architect and Software Engineer at NASA’s Goddard Space Flight Center. I work on engineering frameworks and am trying to develop new processes for our engineers to accomplish their work, innovate, and collaborate. You can read more information and see some of my talks here: http://opennasatools.pbworks.com/AETD-Wiki Much of the thought I have shared here is from my experience in this role.