Back to Top
Knowledge Community Corner: Irene Kaye Interview

Johnson Space Center (JSC) and Irene Kaye, JSC Chief Knowledge Officer.

Photo Credit: NASA

Irene Kaye discusses knowledge management at Johnson Space Center.

Disclaimer: This material is being kept online for historical purposes. Though accurate at the time of publication, it is no longer being updated. The page may contain outdated information or broken links. Current Knowledge Community Corner articles are available here.


Irene Kaye, Chief Knowledge Officer (CKO) at Johnson Space Center (JSC), discusses knowledge management and services, underscoring how knowledge services continue to change at the center level, as they do across the Agency, to become more critical to mission successes. She also emphasizes that the ability to search easily for knowledge remains paramount especially when great change takes place at a center level as it has with JSC.

Fortunately, Kaye is familiar with JSC; she joined the Structural Engineering Division at the JSC in 1988. She has served as the Chief of the Structural Engineering Division, Manager of the Program Engineering Integration Office, and Assistant to the Director of Safety and Mission Assurance. Since September 2014 when she was appointed as the new CKO at JSC, Kaye has been responsible for the development of an integrated knowledge management strategy across the entire center. She began this action by conducting studies of current JSC knowledge management activities, evaluating current policies and processes, and collaborating with other NASA centers and private industry to identify and apply best practices.

Do you have a formal or informal knowledge management and services strategy?

Right now, we have a learning document developed when Jeanie Engle, the former JSC CKO, was in place. We follow the processes in that formal document, the Organizational Learning Plan, which describes our knowledge management processes which are outlined in a straightforward approach: identify critical knowledge, capture it the best way available, maintain it in a way that does not affect the viability/usability of the knowledge, make it easily retrievable to the NASA workforce through search, and make sure it is easy to find and share through taxonomy/ontology capabilities. It sounds straightforward, but some of this can be daunting.

In the aftermath of all of the changes and reorganizations here at JSC, we are reinitiating some of the things from that document. The “formal process” is in progress of being reinitiated. Jeanie did an awesome job of putting together the knowledge websites at JSC. We have five different websites; four websites we maintain—and when I say maintain I mean continually uploading new data and other content we have been able to retrieve and capture. They are JSC Knowledge Online, JSC Lessons Learned Database, and Shuttle Knowledge Console, and all are open to NASA Only. It is one thing to have the information and another thing to use it. One of the challenges we are focusing on right now is how are we going to make existing data useful. Engineering is our largest organization and they have an enormous amount of data that is currently not accessible to more than a few people.   We have had several very good initial meetings to discuss options for ways to facilitate better knowledge capture. I’m not saying what has happened in Engineering so far has been bad by any stretch, but there is a lot more that can be done. This is part of the reinitiating we’re doing right now. It begins with reestablishing points of contacts for all of the new organizations and meeting on a regular basis to identify areas where we can best use our resources.

What is the best way to work more aggressively to ensure that the workforce here at NASA is learning from across the Agency?

First of all, we have to get our own ducks lined up at the center level. There are parts of JSC that are working well to this end. An example is FOD (Flights Operation Directorate)—which was formerly MOD (Mission Operation Directorate)—that has always had an excellent approach to training and knowledge capture.   Sharing information has always been a challenge though because of firewalls protecting proprietary or export controlled information. Pointing this out is not to say that we don’t already work well with the other centers: I came out of Engineering, so I am fully aware of all of the connections we have had with other centers. None of us work everything on our own. We have had folks from other centers work at JSC, mostly via long distance, because we were short on personnel in certain technical areas. Those collaborations worked out very well in the past and will happen again in the future, but we must have a project or a program to collaborate on to work together. We also need to be able to provide the data necessary for them to do their jobs from a remote location. This means it is essential for data to be shared across the agency in a seamless manner.

Implicit knowledge is learned through experience, on the job training, trial and error, education, and learning lessons. It is what individuals know in their heads but is not documented.  Sharing of implicit knowledge at JSC is achieved through mentoring, storytelling, lunch and learn sessions, after action reviews, and other types of person to person transfer, and from those collaborations that have happened in the past. These social networks are connections that are extremely important in identifying and sharing both implicit knowledge and explicit knowledge that is codified, there to be looked up, if you can find it.  Through colleagues, co-workers, neighbors, mentors, friends, and other practitioners, knowledge sharing and the ability to find knowledge sources continues to grow as we maximize expertise. As our social network expands, so does our ability to tap into a diverse set of implicit and explicit knowledge sources.

Are there other highly technical organizations that have aggressively ensured that the workforce knowledge is being captured from across organizations and industries?

We have a robust Strategic Opportunities and Partnerships Development Office (SOPD) that facilitates interactions with many partners, such as the Houston community itself. NASA has engaged with—there are so many examples—the oil industry, and the medical community in forums like “Pumps and Pipes”. JSC personnel attend high tech conferences, present on our projects and programs, share similar challenges we encounter, and then share solutions with industry. This happens at several established forums. Another industry example is the Houston Technology Center (HTC), which is an important organization that helps keep technical expertise in Houston, especially keeping knowledgeable contractors who have worked for NASA for much of their careers. We also help HTC by sharing our expertise with industries that have interests related to what NASA knows. We don’t want to lose the knowledge our contractors with deep skillsets have as they are let go after the Shuttle retirement and Constellation cancellation; HTC helps to keep some of that corporate, technical knowledge around by working as a conduit to share knowledge across the highly technical industry in the Houston area.

What do you see as the biggest challenge to knowledge sharing that has impacted your organization?

I think the biggest challenge, from my short time in the office, is making accessible the information that projects and programs have captured and stored online. There are so many aspects to that. We have tons of data, but no one can get to it easily. There are issues with web technologies limitations. Another part of the problem is having data organized, and having it identified in such a way so it is useful and accessible. The Google search we have here at NASA is not used frequently enough or have a big enough population of active users to make it robust. David Meza and others are trying to find better ways for search appliances, other than Google, to find information. We are buried in data. We search for something, and you don’t find what you are looking for easily, or at all. It can be that some of us don’t even know certain websites exist or when you don’t find what you are looking for then people won’t return to use our websites.

In our plan, which is still evolving, we state that the need for the semantic system can be ongoing, such as with search enhancement.  The role of the user of the semantic system should always be kept in mind when we consider search.  Whether a producer and collaborator, or a consumer of the components of the semantic system, the user’s role can stem from the purpose and need.  Users can have both roles at different points in their self-defined workflows. The accessibility, availability, and content of data to be used, whether static or dynamic, should be a defining attribute for any semantic system.  For example, newsletter announcements and scientific research might exist within the same body of content, but they are not represented nor contextualized with the same level of granularity. This is a technology challenge that can only be solved by many different approaches.

Is there a best or leading practice on how to assign personnel with explicit responsibility to capture and evaluate and share critical knowledge?

The best, I think, is to put it into every employee’s position description and evaluate them on it. If you don’t do that, they won’t likely share knowledge regularly. I also know from my own experience, you don’t put a new person into a position, show them their desk, and then walk away. From an engineering perspective or a scientific perspective, a new graduate will have book learning but that might be as far as it goes. They know how to learn from their education, but what is important—and this happens at JSC—is that everyone is assigned a technical mentor. I would always make pairings, a senior with a junior, depending on the project they were working on, and what kind of expertise you were trying to develop. You try to mix and match the people for what they need to learn. Within intern programs that I’ve experienced at JSC, interns are required to present a technical presentation at the end of the internship, and this puts pressure on both the intern and the mentor to achieve something first-rate. Mentoring is old-timey stuff. It’s apprenticeship. The best place to start for engineers can be the shop or the test labs. How are you going to be an engineer if you are not doing engineering? You develop skills by doing.

Read other interviews from NASA Chief Knowledge Officers.

About the Author

Share With Your Colleagues