Promote Collaborative Learning

Barb joins the virtual meeting feeling a little nervous as she fills Blair in on two recent events. First, Barb describes how she was working in the office the other day and spoke with a couple of other team members to learn more about how they support their customers and what changes to the contracting cadence might mean for their work. The discussion was impromptu, and a few minutes in, another supervisor walked past the small meeting room they had stepped into and made an off-the-cuff comment: “Does Blair know that you’re just having chat sessions while the programs are waiting for you to finish their market research and issue RFPs?”

Next, Barb describes a talk that she had with another team member, Vincent. “I’ve touched base with everyone on the team to find out how many of us are starting to see customers with different needs than in the past. When I talked to Vincent, he was adamant that nothing had changed and everything was staying the same. He said that it took him a long time to learn the standard process, it wasn’t broken, and he didn’t think anything needed to be fixed except for just working harder to get through the backlog. But . . .”

Blair senses Barb’s hesitancy and tries to reassure her: “But . . . ? It’s okay, Barb. I need to know what happened so that we can figure this out together. I know we’re not performing well sometimes, and I need help learning where and why that’s occurring.”

Barb continues, “In addition to talking to the team, I thought I should reach out to a few customers. I have a friend working on Project Charlie, so I gave him a quick call. It turns out that Vincent supports that project. Well, my friend said that Vincent insisted on following the standard process, which caused a serious delay in getting needed contractor support. So, now, I feel like I’m tattling on Vincent!”

Blair is pleased that Barb felt comfortable enough to share this with her and is not totally surprised that Vincent was not open to new approaches. Blair feels that all of the time she devoted to holding one-on-one conversations has enhanced each team member’s comfort level in sharing with her individually, and she starts to ponder ways to get the team to have these conversations with each other—such as asking Barb to let Vincent know that his actions delayed the project.1

People in agile organizations are constantly learning. And that learning can come in many different forms. Sometimes learning is a purely individual activity—such as when you take a class or read a book. Other times, it is collaborative—working together to learn new things (such as when a small group conducts an experiment or attends an instructional webinar) and then applying those things to the organization’s work. But the first step toward any type of learning in an agile organization is something we’ve already talked about: sharing information and decisions.

Without sharing, the information that you collect when sensing is essentially just a bunch of data points or facts. It doesn’t become learning until you interpret what those points or facts mean for your organization and then think or talk about it with colleagues. Even when you take the initiative to learn something on your own, the real benefit comes from sharing what you learned so that others in the organization come to the same level of understanding and can apply that learning together. That’s not to say you should try to repeat to your teammates everything you learned when you took a training class or read a book on a technical subject. However, you would do well to share the key takeaways that might be relevant to your work and then to collaborate with your teammates to apply that learning to the team’s work.

Of course, you and your team must have a sufficient level of psychological safety before you feel comfortable learning together. But once you do, learning will happen in many different ways. It will come from sensing and interpreting what’s going on around you. It will come from pilots and experiments with your products and services. And it will come from your own leadership actions. As everyone gains a genuine desire to learn more, it will also come from discussions, constructive debates, shared decisions, and—as we saw in the last chapter with Blair—even post-work conversations with friends.


While sharing knowledge is crucial for learning, not every piece of knowledge can or should be shared. So exactly what kinds of things should be shared? And what is the best way to share them? Distinguishing the type of knowledge you’re dealing with can help you find the right way to share it. Knowledge can belong to one of three types: explicit, implicit, or tacit.

Explicit knowledge is easily documented and can be shared widely without interacting with the expert; for example, processes and guidelines can be documented by experts, distributed to many others, and retained over time in a knowledge repository, such as a shared drive or database.

Conversely, implicit knowledge is acquired through your own experience or through direct contact with an expert, such as when you reach out to a colleague who has particular expertise to get help with a question or problem. Generally, implicit knowledge comes into play when the information to be shared is highly complex. Maybe you’re trying to apply a solution described in a manual or textbook, for instance, and you discover that your situation is slightly different or more complicated than the one depicted in the book; finding a coworker who has tackled similar problems might help you uncover ways to adapt the prescribed solution or find hidden steps that you weren’t familiar with. Implicit knowledge is best shared through a verbal exchange that includes the expert giving a demonstration and then assisting you (and others, in the case of training) as you try to apply the knowledge.

Finally, tacit knowledge is embedded in the expert’s experiences, which makes it hard to access and capture. It’s the intuitive part of expertise that is now second nature to the expert. Experts may take their knowledge for granted and not fully appreciate the value of their repeated experiences. This type of knowledge is best shared through long-term on-the-job training or apprenticeship programs.

Learning sometimes also happens when an employee makes a misstep, which is an honest or unintentional mistake. Agile organizations pay close attention to missteps because they often highlight areas where processes and procedures can be clarified or improved and where employees can enhance their skills. A misstep might show up in many different ways. It might be a unique case that can’t be processed in the same way as routine cases. It might be an employee who misinterprets a communication or forgets to perform an important part of a process. It might be someone who is missing a key piece of information. And because the organization’s situation is constantly changing in new and complex ways, it might be that the previous way of accomplishing work no longer applies—only you didn’t know it until it was too late. Of course, if someone intentionally makes a mistake, that should be addressed in a manner reflecting the severity of the act and in a way that promotes psychological safety (e.g., discussing it with the employee in private—not in public).

Another way that learning occurs is when someone senses contradictory to commonly held knowledge and feels safe enough to share it. This might show up as, “You know, we’ve been assuming that our customers will need more of this certain service that we provide, but I’ve been seeing customers who are finding ways to get around needing that service.” While it’s often human nature to disregard information that contradicts what we believe, psychological safety, along with norms about sharing information, provides the right setting for people to pay attention to such information. Unfortunately, it’s all too common to respond to a statement like that with, “Well, I’m going to keep my mouth shut. The director just invested a lot of money building up that service, and I’m not going to be the one to say that it was a bad move.”

Of course, psychological safety plays an important role in knowledge sharing. That’s why fostering an environment where people feel comfortable sharing their constructive views is essential in an agile organization. If there is enough psychological safety, employees will more likely share information or decisions, even if they don’t see how it’s immediately relevant. This type of sharing often shows up in the form of “I’m not sure if this means anything, but I just found out . . .” Agile organizations expect people to spend time in discussions like this; they view it as an investment (more on that in chapter 9). Although we don’t want you to spend time on fruitless discussions, it’s hard to know whether some new piece of information is relevant unless you first share and discuss it. Then the team can decide, after a few minutes, that the information is not immediately relevant and move on to the next topic. Although not every discussion will lead to a great insight that heads off a huge problem, sometimes that does happen. And the few minutes invested in each of these discussions often pays off many times over. So in the long term, agile organizations benefit from these discussions.


We talked, back in chapter 3, about using your role as a leader to set new norms. Now let’s take a look at setting norms for information sharing and interpreting and see how those norms are crucial for an agile organization.

Unfortunately, many organizations try to restrict the sharing of information while also limiting how much time people spend figuring out what information means to the organization. In the short run, this can make the organization more efficient because it frees up time to focus on the job at hand. To keep someone from being injured or to prevent a significant loss of a resource, it is appropriate for an organization to make a quick decision, examining only pertinent data. Other situations also demand that information should not be shared, such as when dealing with sensitive, classified, or personnel information. But over time, restricting information is a shortsighted way of operating because it puts the organization into reactive mode while quashing its ability to be proactive. It also detracts from psychological safety as employees get the message that it’s not okay to share information; as a result, they often feel conflicted and frustrated when they sense something that could negatively affect the organization but know they will be reprimanded for alerting others.

Even in an agile organization, however, team members can all have very different ideas about what information is and is not okay to share, because they’ve come from different organizations and had different leaders. As a leader, then, it’s your job to find ways to make sure they know what is okay to do and what they are expected to do.

It might sound easy to simply tell your team, “Be sure to share information” and “It’s okay to spend a few minutes talking about what that information means for our work.” While those statements are probably a good starting point, it’s best to let them lead you to a deeper discussion about norms with your team. Consider holding a norm-setting session where you collaboratively come up with these norms. That will give your team time to ask questions about what you really mean and come to a shared understanding about what is expected. And having them help come up with the norms will ensure that they buy in to them. Your team might even add specifics about what information is okay to share and with whom. While it’s important that the team phrase the norms in their own words, here are some examples of norms that you might expect to see:

  • Everyone should feel comfortable sharing information, even if it contradicts what we thought we knew.
  • Everyone is expected to share information and build interpersonal connections within our team as well as with others in our team and organization (barring security, legal, or personnel constraints).
  • If you see a colleague struggling with a problem, ask if they’d like some assistance and share what you know if you think it might help them.
  • If you run across information that might help someone solve a problem, avoid a problem, or generally improve how their work is done, push that information out to them.
  • It’s okay to ask for information when you need it.
  • It’s not okay to intentionally withhold information.
  • Information belongs to the organization, not to individuals; no individual “owns” information.
  • Try to provide information in a form that is useful and relevant to the person who needs it.
  • It’s okay to take time interpreting what data or information mean for your job, for the team’s work, and for the organization’s mission.

Even after norm-setting, not all team members will feel comfortable sharing information at first, and those who do might initially feel uncomfortable. So remember to keep an eye out for the behaviors that you want to see, let them know that you’ve noticed those behaviors, and reinforce them with a “Thank you for sharing that.” Even if they’re just asking a coworker to help them interpret information, for example, you can say, “I’m glad you took a few minutes to talk to someone else to figure out what this news means.” Offer praise even if the information turns out not to be immediately relevant.

After a while, those who have started to share will become more comfortable doing so, and those who have not shared will be encouraged by the positive feedback their colleagues receive before possibly giving it a try themselves. In due time, these new norms will become second nature to your team, and that will make it even easier when new team members are brought on board. Even if new-hires came from an organization where information was not shared or interpreted and they feel unsure at first, they will more quickly and easily learn that you expect them to share if doing so is just business as usual for the rest of the team.

Over time, you may not need to notice and reinforce every instance of sharing that you see, but you should still monitor the norm to make sure your team isn’t reverting to previous habits. And as information sharing and interpreting becomes “how we do things around here,” you should start seeing your team make better, more informed decisions. You might even start seeing decisions being made faster, because people have information at the right time: you might have fewer bottlenecks that were caused by someone hoarding information, for example, or employees may just feel more comfortable making the decisions you’ve delegated to them because they know they have the information they need. You are also likely to see more proactive responses as people share information before it’s needed rather than waiting for a problem to occur. As a result, you might experience fewer instances of being caught by surprise or having decisions not work out because of a blind spot. Information sharing and interpreting, in turn, feed into piloting and experimenting, which helps your team further learn and develop their skills. Sharing problems that happen in an experiment, for example, is a great way to pinpoint areas where a process can be improved.

As with most changes you make with your team, not everything will go perfectly. One pitfall to watch out for is “I need to go to a lot of meetings so that I know what’s going on.” When one person starts asking to be included in meetings simply to “know what’s going on,” that can quickly become a norm. Soon, other people might start asking to go to meetings, and suddenly your whole team will do nothing but go to meetings. This behavior can be an indicator that information and decisions are not shared widely enough. Meetings are generally more effective when information is shared ahead of time, such as in short, digestible reports or pre-reads, so that valuable meeting time can focus on making decisions. Only those who need to weigh in on the decisions being discussed need to attend. After the meeting, decisions should be shared as widely as possible, including a brief statement about the rationale for the decision.

A different pitfall that we’ve seen is when someone feels that they need to share every detail with others. Generally, people who share too much information have good intentions and are simply trying to be transparent, but the result can be that they’re wasting others’ time with too many details or too much irrelevant information. When we suggest that information be shared widely, we mean that people should simply have access to information when they need it. Sometimes that means telling people what information is available and who to contact to find out more. Having a norm that it’s okay to request information also works well, but only if people know what information exists. This balance between oversharing versus undersharing is something you will have to constantly monitor.

Still another pitfall is when a situation unfolds quickly and people feel they don’t have the time to stop and share the relevant information—or they make a decision without seeking the relevant information. Not sharing information, however, can hurt others who need it. We’re not suggesting that you put in extra hours writing emails or schedule additional meetings to convey information. And we’re not trying to imply that you ignore an urgent situation. Instead, we are asking that you use good judgment while still adhering to information-sharing norms. It’s perfectly reasonable, for example, to wait until you have attended to a higher priority or urgent situation before you share news, assuming that someone else doesn’t urgently need it. Here are a few ideas for how to share information in a timely manner:

  • Use the decision log in chapter 4 to remember to share decisions, expanding its use to include other information (not just decisions) that you want to share.
  • Delegate some of your work to a direct report, which would give her a chance to learn a new skill while freeing up time for you to share information.
  • Get help from a colleague who is less busy, perhaps rotating certain duties to help free up each other’s time for information sharing.
  • Devote a small amount of time during meetings to sharing quick updates, timely news, and an overview of new information that people can look into; ask t hose who are interested to meet offline to interpret the information.
  • During meetings, ask one person to communicate decisions made in the meetings to people who need it but are not in attendance; this will prevent duplicated efforts caused by expecting each meeting attendee to pass information along.
  • Avoid spending time filtering, summarizing, or rewriting information to share with others; instead, pass along or make available “as-is” meeting notes or pre-reads.
  • Use technology to facilitate efficient information sharing; this could be as straightforward as creating a list-serve of names when forwarding information to others or it could involve more complicated and sophisticated technology tools.

Many organizations expect managers to perform technical or functional work aligned with their expertise in addition to supervising employees. Sometimes it’s easy for managers to receive the message that managing is not their highest priority or that ensuring their direct reports’ success is not valued. We view setting norms and ensuring that the right information gets shared at the right time as an important part of a manager’s job. Your team will be much more effective if you find ways for them to know what’s going on within your team as well as elsewhere in the organization.

Sharing and interpreting information is an ongoing activity. It’s not something that should be done for a short period and then stopped. And it’s not something that should be done just intermittently, whether once a year or once a week. Although some information may lend itself to being shared according to a predictable schedule, other information may need to be shared in between those predictable times. Remember, the important part is to get information to the right people when they need it, not necessarily when it’s convenient for you. That said, figuring out who needs what information and when is an important part of your role. As part of that, you may need to ask for and act on feedback about your information-sharing practices.


Meetings can be a productive, purposeful way to share information and create new insights. They can also be a waste of resources and a drag on your time. Although holding an efficient meeting will not automatically transform your organization into an agile one, it is a necessary first step to holding meaningful discussions. Being intentional about how you set up and run your meetings, especially those that happen on a regular basis, can be an easy and relatively inexpensive way to boost your agility and productivity. With your team, develop meeting norms that feel relevant and helpful. The goal is not to create overly formal meetings but to create a meeting format that supports your team in having productive conversations. A few straightforward meeting norms could include the following:

  • Have an agenda that describes the decisions that need to be made.
  • Provide information ahead of time—and expect attendees to read it—so that the meeting focuses on discussions that arrive at a decision.
  • Invite only those needed to weigh in on the decision.
  • Decide who will inform others about decisions made.
  • Capture decisions and action items in a central location, providing access to as many people as possible.
  • Don’t meet unless you need to; cancel the meeting if there are no decisions needed.
  • Schedule each meeting for only as much time as needed, whether that means a five-minute stand-up meeting or a ninety-minute meeting; avoid scheduling every meeting for sixty minutes just because that’s the default on your calendar.
  • Schedule additional short meetings if a decision is needed before the next meeting; be sure to include everyone who is needed for that decision in the meetings and, once the decision is made, inform those who did not need to attend and weigh in.
  • Set rules that address how many team members must be present for a decision to be made.

As with other norms, ask your team to write their own set of meeting protocols. Finally, remember not to get bogged down in work that provides little value, such as overly detailed meeting agendas, verbatim meeting notes, and lengthy write-ups about decisions and action items. We suggest using a “light” approach to this documentation. A meeting agenda, for example, can be as straightforward as a list of needed decisions that appears in the meeting invitation. The agenda can then become the basis for tracking decisions by simply adding a few explanatory bullets, along with the decision and action items. Further, many organizations are moving away from complex sets of policies, which are often organized by function and difficult to maintain as situations change. Instead, some organizations are now providing “playbooks” and “game plans,” organized in ways that are meaningful to employees and provide helpful guidance while adhering to law and policy; they are updated based on employee feedback as well as changing situations.

An additional tip for fostering meaningful meeting discussions is to include all meeting participants in the discussion and give them an equal voice. Try to avoid making decisions in the “meeting after the meeting” or during side discussions, as this can reduce psychological safety by leaving some participants out of the decision-making process. The round-robin technique is one way to make sure every meeting attendee has a voice and a chance to weigh in on the discussion. Rather than have a free-for-all discussion, in which a few attendees often dominate the conversation, it can be much more efficient to ask each attendee, one at a time, to make one point. In meetings with both in-person and virtual attendees, you can reinforce a sense of inclusion by asking any remote attendees to respond first.

Finally, when making decisions, use straightforward voting techniques. One example technique is called “fist-to-five.” Fist-to-five is a low-tech way of voting or showing agreement (or disagreement) with a statement. People vote by holding up any number of fingers—from zero (by making a fist) to five—at the same time. A fist or one finger means you don’t agree and cannot live with the decision being proposed; five fingers means that you fully agree; four fingers means that you agree with most of the decision; and three fingers means you can live with the solution even if you don’t like it. By having everyone vote at the same time, no one is able to succumb to group think or peer pressure, and you ensure all voices are heard. Using fist-to-five, you could even start the meeting with a quick poll of each decision. If the team is in agreement about a certain decision, then they don’t have to spend time discussing it. They can then focus on discussing decisions that the team doesn’t agree on.

Although a constructive debate focused on the issues can be productive and informative, avoid letting the team go around in circles. To do this, you might assign one person to argue for an option and another person to argue against that same option, which ensures that both sides of the debate are represented. Remember that the purpose of the debate is not to “win”; it is to bring issues to light that inform a decision.

For decisions that the team cannot come to consensus on, run short experiments to test possible solutions. Your team might come up with several possible solutions, for example, and then select two or three of them to try out. Alternatively, you could assign people from each side of the issue to work together to design a series of short experiments and then to report back to the group. In many cases, this approach leads to uncovering new options or combining options to arrive at a solution. It also fosters collaboration as members work together to solve the problem rather than focus on making their case and convincing others.

Another technique is to set aside a short time in which meeting attendees can have informal discussion, which is especially important when some (or perhaps all) team members are attending virtually. Be sure to introduce new team members to the team. If the team is large enough, you might have them break out into small groups to talk informally. You could provide a discussion starter, such as asking each person to share something interesting they did over the weekend, or give them a fun team-building exercise, such as trivia questions to answer. Having some unstructured time to get to know each other helps build trust and psychological safety.

Finally, revisit your meeting norms from time to time and ask the team for their feedback. Talk to them about what meeting norms and techniques are working well and what ideas they have for improving meetings. In the spirit of experimentation, you could also try out some new ideas for meetings for a short time and see how they work.

Even though it might feel like a burden to prepare for each meeting, you may find that with this this level of attention, the meetings that you do have are more productive and engaging so you may wind up needing fewer of them.


A knowledge network is a group of people who come together to share ideas and expertise on a particular topic. This network can help you sense and interpret what’s going on, both inside and outside your organization. While you may be spending considerable time with your immediate team, it’s import ant to sense what’s going on in other places. Agile leaders intentionally develop their network to make sure they are getting relevant information when they need it.

To do so, start by thinking about who is already in your network. Remember to think about people you know elsewhere in your organization, such as the budget analyst who helps you complete your unit’s budget each year, your former teammate who now works in a different unit, or your previous boss who is now in a higher-level leadership role. Also think about people outside your organization, such as the person you met at the association meeting last month, former college classmates who work in the same field as you (barring any policies or regulations that prohibit you from reaching out to them), or even the author of a work-related blog that you read on a regular basis. Finally, consider who you know that can help you understand different perspectives because of aspects of their background or experience that differ from your own. These differences might come from having varying demographic backgrounds; living in different climates, time zones, or political systems; or working in different sectors or levels in an organization. It’s important to include differing perspectives when sensing or interpreting new information or creating a response to try, because research demonstrates that diversity in teams—or in our knowledge network—tends to help us reach more innovation solutions or conclusions. Many of us know people with a range of backgrounds when we take a few minutes to really think about it!

Next, try to connect each person in your network to the type of information or expertise they have. Go back and review the different environmental factors in chapter 1. Ask yourself who you know with expertise in each factor. If you don’t know anyone, that’s okay! Consider expanding your network to include someone with that expertise. Or maybe one of your teammates has an extensive network in that area that you can draw from. You might not be able to cover every single area by yourself, but by working together with your team, you should be able to cover all of the environmental factors.

Another technique for building your network is to consider ways to meet new people and to maintain relationships both within and outside your organization. To build relationships with those outside your organization, think about joining and becoming involved in professional associations, reaching out to other experts with questions about an article or presentation they gave, or staying in touch with former colleagues. Within your organization, you could offer to give an informational present at ion to another department’s monthly meeting, participate in a community of practice, or take advantage of organization-wide meetings to meet people from other divisions.

Finally, you can support others as they build their knowledge network. Here are some ideas for you to consider:

  • Reward people for learning and applying what they’ve learned to the job by praising them or recognizing them in a positive way.
  • Build learning into your daily work. Have someone research a relevant topic and then present their research at a team meeting, conference, or professional group meeting.
  • Set up a community of practice. But beware—simply forming a group will do little to move the needle unless you change the underlying information-sharing norms. We’ve seen many communities of practice fizzle out after a few months because their organizational norms say that one should spend time only doing “work,” rather than sharing what they know and learning from what their colleagues know.
  • Rely on your colleagues to reach out to other experts when you need specific expertise or someone to review a deliverable. Doing so can create a learning opportunity both for you and for the person you are asking help from.
  • Facilitate “learning hours,” where team members share their expertise or provide a summary of a recent project, experiment, or topic.
  • Provide project reviews that inform a manager about technical or functional work being performed while giving quality reviews to the project team.
  • Ask a new team member to give a presentation on their previous work or a work-related topic of interest; this is a great way to help newcomers feel that they’re valued and have an impact, while ensuring that team members from all backgrounds have a chance to contribute.
  • Build and maintain a repository of information and lessons learned.
  • Transfer knowledge from employees who are leaving or retiring to your current staff.

Work with your senior leaders to get budget money to invest in these activities, emphasizing that knowledge networks are an investment—not a cost. An expert’s investment of a few hours to prepare a presentation that can be delivered multiple times, for example, pays off many times over.

Defining and analyzing your knowledge network can help you make sure that you and others on your team are paying attention to all of the factors that could affect your unit’s work. The payoff will come when you identify significant factors early enough to rely on the diversity of ideas and creative solutions that feed into pilots and experiments.


An often-overlooked activity that helps promote interpreting information is knowledge curation, which is simply creating an inventory of the information and organizing it meaningfully. We’ve talked a lot about information sharing and interpreting as well as creating knowledge networks, but whether it’s in articles on a certain topic or in relevant takeaways from a discussion with an outside expert it’s not enough just to collect all that knowledge. Many teams collect articles, meeting notes, and reports, but if those items stay on individual team members’ hard drives (or even paper files), that makes it hard for other team members to access those items (while also breaking an information-sharing norm!). Other times, teams provide access to those items on a shared drive or internal website, which is a great first step to getting information to all team members, but to make it easy for others to know the information exists, you need to take one more step forward and curate it.

To curate knowledge, create an inventory and organize the information into meaningful topics. If you are collecting articles on a specific topic, such as artificial intelligence, you might copy the relevant articles into a shared location that all team members can access. Rather than copy the articles into a location with dozens of articles (or more) on other topics, however, create a subfile or sub-folder called “Artificial Intelligence.” That way, others who are sensing on this topic could easily find and place articles and other resources into the same folder.

Additionally, you could create a log or inventory of those articles, which could be a simple table that contains the author, date, source, and a one- or two-sentence summary. That summary information could prevent others from having to read through every article to find the information they’re looking for. A live (or up-to-date) summary of all past meeting decisions can also help if you have notes that contain decisions and action items from years of recurring meetings, so your teammates don’t have to read through it all. (And if you are using a light approach to documenting meetings, that will free up time to create a live summary.)

If you’re entering information into a database, be sure to collect information that is actually needed and in a format that is understandable and useful to the recipients. We’ve seen many instances where considerable resources were used to create a database or other compilation that no one ended up using because the knowledge stored there was either unnecessary or unusable. For example, one organization asked a senior expert to document her expertise before she retired. The expert documented and then filed the information in a way that was useful and meaningful to her—but not to others who needed it after she was gone. This problem could have been avoided by having the senior expert relay the information to her colleagues, such as through a short training session. The colleagues could have then asked questions in order to understand and use the information, documented the knowledge in a format that was useful to them, and then filed the document in a place that they found accessible.

You may need to devote some resources to curating all of the information and knowledge that your team accumulates. Every so often, a team member might need to review and organize the information, which can be a good task for new team members to quickly learn about a relevant topic. Another way to curate information is to assign the role of “knowledge steward” to a team member. Perhaps this role rotates from time to time in order to share the burden and to provide others the opportunity to learn.

Finally, remember not to let knowledge curation take on a life of its own. Yes, you should be keeping information organized and usable for others, and some topics may become less relevant over time and thus may no longer need curation. But you will need to find the right balance between devoting resources to curation and keeping information organized so that it helps the team.


Often, organizations look to technology to solve their knowledge-sharing challenges. This rarely works to solve their knowledge deficits, and teams often end up spending many hours creating and filling a shared drive with unstructured information that ultimately does not get used. As a result, teams can get discouraged about the value of knowledge-sharing efforts, which can hinder agility routines.

That’s not to say that creating a shared repository can’t be an important step to record and share institutional content; but it alone does not achieve understanding and behavior change. Rather, a technology system must be complemented by the organizational learning approaches described earlier in this chapter. That’s because these approaches and tools address the cultural and behavioral issues that are usually the most difficult to change. Wherever implicit and tacit knowledge need to be shared, interactive and iterative forums for sharing that knowledge are needed for personal development and mastery. The shared drive can be a valuable tool in these efforts, but it is not a solution in and of itself.


Many of us are familiar with the coworker who hoards information. Sometimes people do that because they want to feel valued—and they believe that if they share what they know with others, it might diminish their value and they might lose their jobs. But the truth is that one person is unlikely to have all of the information needed in a turbulent situation.

When faced with an employee like this, have a one-on-one conversation with them to explain that information sharing is the norm. Also explain the reasons behind needing to share information. Ask the employee to think about a situation when they needed some information that a coworker declined to share. How did that impact their ability to decide or get something done? You might also probe with questions to understand why the employee doesn’t feel psychologically safe enough to share information. You might be able to coach the employee to the point where they feel safe doing so.

Although you might not immediately change the person’s mind, you can persist in your efforts to get the team member to adopt new norms. If the employee starts to see that it’s really okay to share information and that hoarding information prevents agility, then, ideally, they will start to share information. Pay close attention to any progress in their behavior so that the first time the employee shares something, you will be ready to encourage that behavior. If the employee continues to hold back information, you might need to dig deeper into the psychological safety factors that are still hindering them.

Feeling Barb’s uneasiness with sharing those two events, Blair quickly explains that she isn’t interested in playing “Gotcha!” or the blame game; rather, she is focused on making the team as productive as possible. Blair explains that she expects Barb, and any other team member, to talk openly and share work-relevant information—and not to gossip. Using the situation as a learning opportunity, Blair asks Barb, “Did any of your conversations with the team detract from getting work done?” Barb shakes her head, adding, “Of course not! Each conversation only took a few minutes. I didn’t interrupt anyone while they were working. I just took advantage of seeing them in the hallway or messaging them at the end of the workday.” Blair replies with, “Great—that’s exactly what I expect you to do! Don’t worry about what other supervisors think. They’re free to run their teams how they want. What I want is for you to keep taking the initiative to learn more about what our customers need. As for Vincent, customers who need the standard process aren’t going away completely. We need his expertise, and now I know that he will be more comfortable supporting that process.”

Blair continues, “What’s your next step? Do you have enough information to start testing a new process that would supplement, not replace, how we currently do things?”

“I feel certain that we’re going to see more programs with quick-turnaround needs,” Barb says, “but I don’t know what options are out there. I don’t know if we need new software or a different workflow. I can talk to a couple of former team members at different agencies if that’s okay.” Blair nods. “Yes, please talk to them. And let’s talk to a few people who are on the cutting edge—I’ll send you contact information for an expert at the Government Contracting Institute (GCI) who I met at last month’s conference as well as a university professor who teaches acquisition.”

A few days later, Barb updates Blair. “Wow, those conversations with the professor and GCI expert were eye opening! I still need to learn a bit more though. I also will need help applying their insights to our work.”

At the next team meeting, Blair asks everyone to create their own knowledge network map. Each team member briefly describes their network, holding their maps up to the screen for others to see. At the end of the meeting, Blair asks them to post their maps on the team’s virtual drive.

They discover two key factors that were keeping them from designing a pilot of a more incremental contracting process:

First, only Barry has connections with acquisition software vendors. He started his career in IT and still has some great connections. Blair asks Barry to pull in Barb and Ryan when he starts talking to his contacts, recognizing that Ryan is one of the newest and quietest team members. Blair knows from her one-on-one conversation with Ryan that he’d appreciate being involved.

Second, they discover that they don’t really know anyone with policy expertise to help them make sure their new approach would comply with laws and regulations. After brain-storming a bit more, they decide that Blair would reach out to Ms. Barton to explore filling in that part of their knowledge network. Ms. Barton would be able to put Blair in touch with the agency’s policy experts.

Blair then starts to plan a few Friday-afternoon knowledge-sharing sessions so that Barry can share what he learns from his network and she can share what she learns from the policy experts. And she might even invite the other supervisor and his team!

Over the next several weeks, Blair continues to devote part of the weekly meeting to knowledge sharing. After talking about information sharing, Ryan and Barry write up a set of eight “information expectation” norms, which the team votes on with a quick fist-to-five. There are a few fours, but that is good enough for the norms to be accepted. And holding up their hands to vote makes yet another virtual meeting a little more bearable.

They also have a couple of quick wins. Ryan uses some information that Vincent shared, which helps Ryan get an urgent request for information completed. Their accomplishment is noticed and greatly appreciated by the program director. And their early successes seem to have made the team even more excited about sharing information.

Getting to this point has taken longer than Blair wanted, and sometimes it feels like they’re talking about things that aren’t immediately important. However, she realizes that the time they spend in these conversations has the additional benefit of creating stronger relationships among the team. They also are gaining a better understanding of each team member’s specific expertise and starting to rely on each other as resources for problem-solving in a way they haven’t before. Even quiet members like Ryan are starting to seem more comfortable.

She wants to document what they are learning and proposes a weekly learning log. But the team pushes back hard on that idea. The team feels that they are all involved in the conversations, so spending extra time documenting what they discuss doesn’t make sense. And as a result of their stronger connections and the new norm of not hoarding information, if anyone misses the weekly meeting, someone catches them up. The team wants to spend time learning from each other instead of creating lengthy manuals.

Blair agrees with that decision, for now. She knows that it won’t take long for the team to realize that they need some amount of documentation. At some point in the near future, someone will likely forget key information previously shared or a new team member will join and need a quick way to get up to speed, and they might see the need. But she also wonders if there is a better way to document the intricacies of their work besides writing it in a manual. “Information is conveyed in so many different ways today—podcasts, videos, online decision aids,” she thinks. “Those formats might make knowledge easier to learn.” But she is happy with the team’s progress for now! So, she decides to apply her current energy to writing a short learning blog for the agency’s next all-employee newsletter. She looks forward to sharing her team’s recent knowledge-sharing success with the rest of the agency.

1. Jennifer Myers contributed to this chapter.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.