Skip to main content
Community Contribution

Why Boeing Focused on Behaviors, Not Tools, When Building Its KM Strategy

Jun 29, 2015
Jyoti Patel

This blog from APQC discusses how Boeing merged two organizations and developed common processes, knowledge management capabilities, and data system architectures while also designing a knowledge management strategy that emphasizes behaviors over tools. APQC interviewed Jyoti Patel, knowledge management strategist at Boeing. This blog originally appeared April 6, 2015. You can follow Jyoti on Twitter @Jyotibfly.

APQC: In 2010 Boeing Test Evaluation (BT&E) tasked a team with developing a consistent enterprise strategy for process management, knowledge management, and systems engineering. Why did the organization feel this was important?

Jyoti: BT&E was a new organization that brought together teams that were previously split between Boeing Commercial Airplanes and Boeing Defense Systems, and its challenge was to integrate these teams into a cohesive, high-performing organization to implement a common approach to testing Boeing Products including airplanes, fighter jets, and rotorcraft. Fourteen core capability organizations were defined, the largest of which was ours: Instrumentation and Data Systems. My team, the technical excellence team, was charged to lead the way for BT&E and the other capabilities to integrate by developing a common language, process architecture, and KM approach. We needed specialists that understood the organization from the inside to be dedicated to this full-time, which sent a message about how important this work is.

APQC: You began developing a strategy by gathering feedback through nationwide site visits. What was something that surprised the team that employees mentioned over and over?

Jyoti: We found six high-level themes that were repeated across our sites in some form or another. The two that were the most surprising were (1) the desire for rotational programs within BT&E and (2) big-picture education and visibility. In retrospect, it makes sense that within a large organization like ours, where becoming compartmentalized is a natural state, people are hungry to obtain a systems level perspective. We found this to be especially true of our teams who interface with other teams a lot, and not so true of our smaller independent teams and labs.

APQC: At Boeing you tried to avoid pitfalls that other KM programs have fallen into, such as focusing too much on tools rather than behaviors. What was the biggest struggle you had to overcome?

Jyoti: The biggest struggle we had to overcome was shifting the learning culture to match both our current dynamic business environment and the evolving expectations of our incoming employees. Specifically, we knew we had to shift the perception that knowledge sharing, in all of its forms, is secondary to the primary work. We built a multi-channel knowledge strategy at a high level but in order to execute it, we had to meet people where they were and with what they were already doing. Informal knowledge sharing happens all around us, so part of our challenge was shining a light on the existing pockets of goodness and working with teams to enhance the effectiveness of what they were already doing, highlight how it fit into the strategy, and grow their efforts from there.

APQC: One goal of your KM program is to facilitate knowledge transfer between new hires, future experts, and late-career employees. What approaches are you using for this?

Jyoti: After identifying the target audiences for our knowledge transfer approaches, we combined the best of the programs that were being used both in the larger Boeing system and within our own groups. Our design build organization had a homegrown, tiered mentoring program for new hires that stood out for two reasons. First, it made new hires eligible to mentor other new hires after a year, which saved the time of our experts and leads while also fostering a teaching mindset in our early-career employees. It also recognized the need to free up the time of our most senior employees to dedicate to mentoring activities instead of strictly working projects. For future experts, we leveraged an existing enterprise approach called Enterprise Engineering Technical Mentoring (EETM) which nurtures the concept of building strategic partnerships based on critical skills between our experts and mid-career employees. Finally, for employees leaving the organization for any reason, especially retirement, we leveraged an enterprise framework called the Knowledge Transfer Toolkit. One of the underlying drivers of our team’s mission was to support the development of knowledge transfer plans for our retiring baby boomers who, in many cases, possess a lifetime of specialized knowledge. Part of our role is to consult and coach exiting employees. We customize and execute the approach based on their particular needs.

APQC: What are the pros and cons of capturing knowledge through a wiki?

Jyoti: Our wiki, e-Book, has over 550 pages of content and 955 users; it has been built over 6 years as an entirely grassroots effort. I’ll speak to the cons first. It’s difficult to maintain a navigational structure that works for a diverse range of users, which happens when new groups join. We want to grow the user base to drive more participation, which leads to a higher standard of content. I think striking the balance between the right number of users while maintaining relevance to your core users is key. We have a lot of content consumers, but only a subset of those are content creators/editors, which means that there is a critical mass of users for a wiki to maintain efficacy. Another con is that our engineering population values content approved by experts, so it has been a hurdle for those folks to accept an open source model. Also, it’s slow to build content momentum within an organization where the demographics are so polarized and the level of comfort using a wiki is very inconsistent among employees. This is a long-term resource with long-term gains and had to be approached accordingly.

One of the main pros is that the wiki represents an ideal of how we should be capturing knowledge. Within our organization, the 70/20/10 rule is well known and espoused, but when the majority of people think about capturing knowledge, they use traditional methods like creating training material for a class or writing an informal document to be distributed locally. The formal training is still widely accepted as the standard despite an awareness that the world today provides better methods for on-demand access to information, and the wiki is a great example of that. Many people in our organization not only recognize this but practice it, and these people form the majority of our active users. The fact that this was a resource created for the people, by the people, without the cost of bringing in the IT organization fosters a big sense of pride for what we have created here (a community of learners connecting not just knowledge, but more importantly, people). Finally, the on-demand attribute is a huge advantage, especially in the fast-paced dynamic world of flight test. People need answers and they need them fast, 24/7, and from anywhere in the world. Our folks don’t have time to dig through servers or training material, and the wiki supports that.

APQC: Boeing’s KM program makes serving people first a priority. What are the keys to doing that?

Jyoti: I think that ultimately you have to place relationships and connecting people with one another above all else. People can and will use those relationships and resources for a myriad of reasons, a subset of which might be related to your organization’s core mission. For instance, InSite (Boeing’s social network) has all kinds of interest groups, some of which seem to be outside the scope of what we do. Not all of them provide a tangible ROI, but the power of the community, as well as the massive potential of connecting great ideas with people who can help make them happen, is enough to sustain their existence and promote innovation. I also believe a key to serving people first in KM is: Don’t be afraid to “design tight, run loose”. Our targets and environments are constantly changing. This means our plans, projects, and our own beliefs are all subject to change depending on the latest environmental scan. If you listen to your customers throughout your project lifecycle and use that data and your relationships to co-create a better product, you will surely succeed. For me this translates to a solid operating structure and rhythm that connects the right people to perform course corrections and ensure progress to goals as needed.