Case Study: I have a project but no visible team knowledge – "Accelerating Capability"

The following is a case study that demonstrates one of many approaches taken to craft knowledge sharing culture.

 

I'd been working with Nick, the team leader, for some time and trust had already been well established between us. Trust was helped greatly by his manager's encouragement that we both work together whenever we could to accelerate knowledge sharing within Nick's team.

 

We'd already done the 'OK let's try Nick's ('the manager's') way' where we'd built a shiny high-tech gathering spot for the team knowledge for 'instant global use' to magically to appear but never materialised. I didn't protest at the time, what I felt was a doomed effort for a range of reasons – one of them being Nick's enthusiasm to try. Thankfully, our trust survived that first wheel spinning experience. (Persistence and patience is an essential ingredient when building knowledge sharing culture and sometimes people just need to feel out what they think is 'the silver bullet' to punch through the (sometimes) inevitable 'wheel spinning' period.)

In fact, the trust between Nick and myself had strengthened I think because Nick was now 'at the coal face' aware of some of the realities in crafting knowledge sharing culture. He, like me years earlier, had to learn the hard lesson that technology can't come first when doing this softer stuff. 'Somehow' there needed to be a genuine trust in and between the team members – those who either held the knowledge or wanted the knowledge – to deliver the outcomes Nick, and Nick's managers wanted.

I'd built an alternative to the high tech gathering spot and primary launching point for his local team's knowledge in a few hours some weeks before that was being used and proving increasingly useful which I think had helped Nick trust me to keep going. I'd also dusted off a substantial amount of team knowledge that had been made visible in various forms, including hand written 'gems' from the past he and others had forgotten about. These were now reliably at the whole team's fingertips, that Nick was 'talking up' more and more.

In one of our regular catchups, I floated the theory that high-speed trial and error (or 'high speed heuristics' – one of my favourite terms) was another essential ingredient in crafting well-functioning knowledge sharing cultures and, if he was willing, we could begin work to finding a way that worked for his unique team to make team knowledge visible faster.

He agreed, and because trust was sound between us, I was able to share my vision of what I thought would be a quick and effective way of going from 'nothing yet visible' to 'visible, useful and used team knowledge' on a specific project area Nick's team had to deliver in a few weeks.

The plan was simple enough to get the ball rolling.

  • Someone would 'name it' (the name was the area of endeavour where the team knowledge was needed),
  • Someone would take a stab at the headings and sub-headings, then,
  • As many as possible would nominate questions they felt 'useful if answered' for each heading.

Nick was confident enough to give it a try. (Another essential ingredient in well-functioning knowledge sharing cultures is that leaders are prepared to 'have a go' at new ways of working together to create useful team knowledge that's regarded and used.)

I call this formula THQ. Topic, Heading, Questions.

It worked a treat.

In one day, we'd gone from a standing start with no visible team knowledge on the topic, to team knowledge that was now visible, useful and usable according to the team.

My role, as it often is, was to do all the bits that people doing the actual work don't care to do.

This included creating the environment for all this to happen, arranging things so when the minds did open, what emerged was converted cost effectively to visible team knowledge.

(Starting at 'usable and useful' team knowledge is a game-changer in creating well-functioning knowledge sharing cultures. It gives license to, or perhaps more accurately 'demands', distancing the knowledge sharing process from technology for a period so what really matters can be made visible (with the help of technology) faster.)

The following is how things unfolded:

  • At 9am Nick, Tim and I met. Tim was the newest and least experienced member of the team and Nick's role was the team leader. My role was the knowledge sharing culture enabler. Nick, in dialog with Nick's manager and other client managers had 'named it' (the knowledge gap) so we knew what we were focusing on. What we needed was the skeleton or 'framework' through headings and sub headings. Nick, as the most experienced present, came up with about a dozen and a half headings and sub headings in under twenty minutes.
  • At 9.30am the whole team joined us and we kicked straight into 'on this topic and these headings, what questions would be useful if answered?' (Keeping discussion to heading and sub heading kept things simple and the team was able to use time effectively and efficiently). Thirty minutes later we had over eighty questions. This is one of the times where the enabler, me in this instance, earns their keep. I had to type like the wind to keep up. One question would spark multiple others generating a buzz that motivated us all. Nick and I worked together to remind the team that our goal was visible team knowledge that was actually used and useful. So it was important to only allow questions into the emerging shell document that would be 'useful if answered'. This sometimes required some separate, but often 'most useful', discussion.
  • At 10am everyone went back to work, except Tim who now had a few pages of the best clues he could hope for to accelerate gathering his own knowledge on this very specific topic and pressing business need. Nick carved out a few hours of the same day so Tim, the one who had most to gain from 'having a go' at answering the questions (learning while doing) could reflect and research his 'best effort' responses within the time allowed.
  • At 4pm the whole team regrouped and was asked 'What unanswered, or partially answered, questions can you help Tim on?' 45 minutes later, after a little encouragement to watch the clock, we'd got the bulk of it and everyone left to allow Tim to touch things up.
  • At 5pm Tim presented the 'now visible' team knowledge to Nick for review on the train home. Everyone I spoke to felt highly motivated by what we'd worked together to achieve in a few hours on the same day. Two working hours later, after some email and verbal exchanges, the team knowledge was complete and I arranged things so it was reliably 'at the whole team's fingertips' for anytime, anywhere use. Nick was already planning his next effort.

After this new knowledge job was done I asked Nick what he thought were the important points to remember for future efforts. He shared the following:

  • Don't fuss too much about headings. Headings that were created at the start were as detailed as time the fifteen minutes allowed. And, for engineers, this is a key way to stimulate questions as 'we're not good at focusing if the subject is too big'. If a question didn't fit an existing heading, the right heading was created, and / or adjusted, during the brainstorming session.
  • Don't fuss if a question applies in a few areas. Nick didn't worry if a question applied to a number of different headings as long as it was in there somewhere. Tim would rearrange things later.
  • Tailor the process to the group. Another point Nick felt important was that tailoring the process to how the group's minds worked was important. We achieved this through one on one chats between Nick and myself a week prior.
  • Keep the things informal. Nick's final point he felt important was that this was all done with a few simple email invitations, some informal gatherings and some focused work in between. The whole knowledge gap was addressed in under a few working hours spread over ten days.

Applying this to the metaphor of the fruit tree …

  • Soil The soil is the conversation. The conversation is where trust is built. It starts with trust between team leader and enabler (the person tasked with making all this happen on time and on budget) then trust between those participating.
  • Trunk. The tree trunk was the primary launching point and gathering spot for the new team knowledge. The branches were the headings and subheadings.
  • Fruit. The fruits were the answers 'from all involved' to the questions they'd used as a stepping-stone to find the answers. As Einstein observed … "If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask, for once I know the proper question, I could solve the problem in less than five minutes."

Job complete.