Ed Rogers, Chief Knowledge Officer (CKO) at Goddard Space Flight Center (GSFC) discusses knowledge management and services, emphasizing how knowledge functions will have to change in the near future.
Dr. Rogers introduced the Pause and Learn (PaL) process, developed an internal case study methodology, designed and runs the Goddard Road to Mission Success workshop series, and advises senior leaders on how to shape organizations for learning and uncover thinking patterns that inhibit and drive innovation.
Is there a formal or informal knowledge management and services strategy at GSFC?
We have formal documents and papers available on the web. Our strategy primarily focuses on management lessons, though we don’t ignore technical lessons. NASA is actually very good on technical lessons because we write everything down that we do. We do occasionally make mistakes, but it is not too hard to find what went wrong. We know how to tighten things up on the technical side of lessons. We always have our eyes and ears open to those kinds of lessons. There is sometimes, however, an issue of not sharing technical lessons from one group to another so we are always trying to improve sharing across projects. But the management lessons of how we do stuff, are challenging. So our strategy is to focus on those management lessons—which is why we run a lot of case studies—which are hard to understand outside of context: they are judgment calls, there are nuances of the environment, they are concerned with what was going on at the time that affected decisions made. It is easy to make those Monday morning quarterback decisions, but we don’t learn anything that way. We need to understand what decision were made and why. Otherwise we just jump back and forth: the proverbial swinging back and forth from one popular management technique to another. For example, Let’s try faster, better, cheaper. Now: slower, more risk intolerant. Now: faster, better, cheaper. Back and forth. That is the essence of failing to learn. We make the same mistake over again. The second part of our strategy is learning where the learning takes place, locally, where the action is. The people in the lab need to make sure they have learned everything they can from their experience and not be in a rush to share it. A few people do care about getting those lessons quickly, but there is too much of a rush to take lessons learned from people quickly rather than letting people generate lessons learned once everything to be learned has been generated. This is the essence of the PaL process—building reflection and learning into the work process. There is also a lot of resistance to taking lessons quickly rather than waiting for people to figure out what they have learned and be motivated by that. A third part of our strategy is to avoid learning lessons out of context where people may learn the wrong things. That can be dangerous such as reducing lessons from whole projects to bullet points without context. These points are typically communicated well or collaborate—but they don’t mean much without any context. Or possibly the lessons become “hide your information from HQ” or “don’t work with these people” because the situation is taken out of context and put into a personal view without group reflection. Someone says, “I shared my information with Headquarters, and Headquarters cancelled my program: the lesson is don’t share your information with Headquarters.” Those kinds of personal observation lessons can be deadly for an organization.
What is the best way to work more aggressively to ensure that the workforce here at NASA is learning from across the Agency?
The real key to learning is to make it interesting—to make it attractive to other people. People love to learn. You don’t need to tell someone to learn. But we’ve made it hard and boring. Within the general workforce outside of NASA, normally, jobs are broken down to narrow roles, to perform day after day, because this is easy to control and maintain. The attractive thing about NASA is our jobs are ambiguous and are challenging, about problem-solving. Our work allows people at NASA to learn. So what we have to do is to make it easy for them to learn. Unfortunately, some of the online systems are so dumbed down that—like mandatory Government training—they don’t rate highly. That is not how people would choose to learn. If they had a choice, they want to delve into story, to share with their friends, and they want context and consequence, to know why. We need to do a lot better job of encouraging this kind of learning that often happens in the lifecycle of a project, not outside of it. It is a simplistic solution to have all a project’s documents sent to some warehouse, crunched into some grinder, and then made available to everybody else. This is not entirely useless, but it is only a small piece of the learning picture. People don’t want to spend the whole day in the library to find a lesson. The lesson has to be there in people’s everyday processes and procedures, which is often how we have come up with processes and procedures, from lessons. But we do have to question, which is not what bureaucracies—which strip out the learning from procedures to make them rules—want you to do. We hire smart people at NASA: if we question something, we will discover what is obsolete or what can be improved. Hiring smart people and asking them to just follow rules blindly is a waste of talent and doesn’t foster organizational learning.
Are there other highly technical organizations that have aggressively ensured that the workforce is learning from across their organizations?
For years, British Petroleum (BP) focused on management scenarios built on the facts that they have archived. In their knowledge management training, people worked through thought-provoking scenarios. Twenty years ago, they would train with what then seemed like ridiculous scenarios like, “What would happen if oil was 100 dollars a barrel?” when oil was 30 dollars a barrel at the time. What they came up with were solutions that helped them. That is how they connected knowledge management to training, to make better decisions. A few years back, the World Bank did a lot of storytelling and scenarios, not just stashing and storing information, because knowledge is only useful when people have a question. Few people sit and read the dictionary; they only pick up the dictionary when they have a question. Organizations that build learning and knowledge into the lifecycle of projects are doing better than organizations that just build a system like a dictionary.
Is there a best or leading practice on how to assign personnel with explicit responsibility to capture and evaluate and share critical knowledge?
Typically, what organizations do is just assign responsibility to whoever they think is just standing around. People who are available often have no clue what they should do with knowledge. That often hurts those in knowledge management and services who have been trying to do something. When the organization sees the clueless behavior, they associate those really doing knowledge services with the clueless behavior. It would have been better to not have assigned anything to someone who did not understand how knowledge works. When assigning personnel to knowledge functions, we have to remember these skills—capture, evaluate, share—are not inherit in most workforces. In our workforce, we don’t hire people to solve knowledge-based problems. We don’t hire people who can do analysis of organizational aspects of what went wrong and how decisions were made. When this happens, there is a danger of people retreating to conspiracy theories of “management had it in for us” because they don’t have the skills to really analyze what is going on so they fill in the blanks. You need people who understand how organizations work and who are willing to train everyone—but mostly managers—on how to share knowledge in a meaningful, interesting way. They are smart, but we can’t assume they have these skills.
What do you see as the big challenge to knowledge sharing that has impacted your organization?
When you are in the category of training and when there are budget issues or priorities changes, there can be challenges, and you see that with the cancelling of ASK Magazine and scaling back at HQ. There is a lot of interest when it is a hot item and then budgets dry up. Soon, you don’t have anything to work with. Importantly, though, there is a real commitment to the outcomes—like Chris Scolese or Mike Ryschkewitsch and others who have worked at Centers and HQ—who know we need to do better in managing projects, how the Centers and HQ work together, how to commit to working on these issues instead of chalking it up to a “personality” issue or something else. Instead of people being committed to outcomes, many get committed to pet projects, some cool, nifty thing that everyone gets wrapped around. Space Book is a good example of that. It was a cool tool, but it didn’t deliver 10 percent of the hype that grew up around it. It is easier to get people committed to a particular project that they can bet on than understand what we are really trying to accomplish. If something does not work out, try something else. If something is not working now, come back to it later. We have to maintain commitment to the “soft” stuff, what I do here at GFSC and what Hoffman does at HQ. Leaders ask, “How many case studies have you written?” but insightful leaders know that case studies provide what really happened during a project and what people thought about and that is going to help the person understanding the case study applying knowledge and know what to do for the future. The challenge of getting leaders to be committed to the outcomes of what we are trying to accomplish requires leaders listening long enough to understand. When the leadership changes—as it soon will—you have to start all over again explaining why what we do is important. It takes a while for leaders to get it. Right now we are fortunate to have leaders across Goddard who really get the value of investing in learning and sharing so these activities are welcomed. New leaders will assume it can be done faster or without stopping to learn. They will make many of the same mistakes the last group made. Very few lessons learned are anything new except to that crop of leaders. Ten years ago a NASA executive at HQ told me that Knowledge Management was all about getting the technology architecture correct. She spent two million dollars over the next two years accomplishing very little. Then she told me, “I’ve figured out that KM is really 90% about people and 10% about the technology. This is one of the worst examples of failing to learn or relearning in a very expensive manner. That’s what we are trying to avoid with all these cases, PaLs, and workshops by constantly keeping these lessons in our conversations and our training.