The Tribal Knowledge project.
Late last year I was given the charge to manage a project to document troubleshooting processes that exist only in the minds of a handful of tech support gurus. It will help the support group to train new support people more effectively, and it will take the pressure off the gurus, who currently spend a lot of time solving the same problems over and over.
We put the project aside at the start of the year, because things were getting busy. After the really busy period, we met in February and agreed to cut down the scope of the pilot phase. People were still too busy to meet regularly to create the half-dozen flowcharts we envisioned as the pilot phase of the project; a lot had been postponed during the big thrash in January. We would do just three flowcharts. We met again a couple weeks later and cut the pilot phase to the smallest possible effort: a single troubleshooting flowchart, to be shared and evaluated, tweaked and published on the BlobCo collaboration site. I could almost hear an imaginary sportscaster exclaim, "Oh, that was a nasty stumble - let's see if they can recover."
A very skilled tech support person volunteered to build the flowchart, and emailed it out for comments a few days later. Someone provided constructive technical review comments. The flowchart owner got very busy and didn't have time to make the changes. I urged her to post it in its unfinished form and let others collaborate on completing it.
Imaginary sportscaster: "And we've got a player down on the field - it looked like she was going to recover from that stumble, but she's down."
What went wrong?
The concepts of working laterally, collaborating, and doing stuff because it's the next step in the plan instead of because the boss said "Do it" are central to this project. They're also markers of a mind-set that was once strongly discouraged at BlobCo. I could see from early on that the organization was recovering from a nasty bout of 1980s-style command-and-control, but I didn't realize how deeply it had scarred people. Everybody is too busy with their regular work to participate in this subversive, risky project, because "too busy" is the perfect reason — it's true, and it shows that people's priorities are right: We can't do this strictly internal project because we've got customers who need our help.
Because it takes us a long time to help each customer.
Because we've never documented and shared our troubleshooting knowledge, so we have to go ask somebody instead of looking up a troubleshooting flowchart in some central place.
We are like lumberjacks too busy cutting down trees to stop and sharpen our axes.
I asked the VP sponsoring the project to help me figure out how to get it back on track. He proposed a way: Authority would be exercised. People would be given assignments. There would be rewards at the end.
This didn't feel right.
Six of the couple dozen participants showed up at the next meeting. Several people had mysteriously taken the day off. I was frustrated. But the passive resistance and my frustration both validated my sense that we were taking the wrong approach. My sponsor bowed out and told me I needed to enlist a new project sponsor, suggesting two people who were well-placed to do this.
Time to seek out a Jedi master. I talked to Cat Herder.
"You've got too many people on this project. You need to drop the ones who aren't passionate about it," said Cat Herder, who went on to give advice that resonated strongly with my original sense that the project can only succeed if people WANT to participate. In just a few minutes, I heard several ideas about how to foster the creative, collaborative environment that will set people up for success; and we roughed out a plan for reshaping the Tribal Knowledge project and getting it moving again.
I am listening.
You have to fall down before you understand what it means to get up, and it helps if someone offers you a steadying hand.
I may have just connected with the next great teacher in my life.