Monday, May 21, 2012

Search or Derive

I was helping my son study for his Standards of Learning tests (known affectionately as SOLs - who thought that was a good idea?) He was a bit concerned because the study was around using Celsius instead of Fahrenheit. So, we went through different ways you could navigate the problems. Here are three of them:
  • You could go with intuition - you could think in Celsius. Having lived in Europe - this is fairly easy for me - single digits is cool; 20° is comfortable; 30° is hot; 45° drink plenty of water and take steps to avoid heat prostration. If the temperature is below zero wear a coat.
  • You could use derive a heuristic to get the temperature in Fahrenheit - double the temperature in Celsius and add 30° will get you close enough for temperatures in weather reports. You can derive the exact conversion formula if you know the freezing point and the boiling point of water in each scale. (The formula for the conversion is  F° = 9/5C° + 32°)
  • You could look up an answer on the Internet.
We did not use the third method. So, thinking about Knowledge Centered Support:
  • On every contact there is a decision point - do I search for an answer or do I derive an answer? 
When your body of knowledge is stable, your inquiries predictable, and your search tools are effective a decision is easy - search and only start deriving when you can't find the answer. When all three of these are present the decision becomes different - deriving may actually be the better approach. I know this first hand from supporting Macintosh products. 

At that time, Macintosh computers were losing market share. The Macintosh teams had a couple of teams of ten to twenty agents. There were dozens of windows teams. The knowledge base was predominantly windows solutions. (Apple snobs would point to the superiority of the Macintosh Operating System.) I didn't search much for solutions - I derived them. I had a mental check list of things I could do to isolate and diagnose a problem, and more than likely find a solution. In rare instances - mostly printing issues, I knew I could find a solution in the knowledge base and I would search. For the most part, I knew in 95% of my calls, I could derive a solution 100% of the time. At best, I could find a solution 30% of the time - the content was limited, the search engine was tricky, and I couldn't contribute to the knowledge base, and  there was no way to flag content gaps.1 I really had only two choices: derive the answer or find a subject matter expert to ask.

Effective agents derived answers. The others struggled. Ironically, there was a woman who was struggling that I admired. She had derived her own rudimentary form of KCS - each time she encountered a call where she didn't know the answer, she would ask for help and carefully write the answer on an index card that she kept in a rolodex. She drove the subject matter experts nuts, because she was always asking for help - but she never asked the same question twice. If the answer was in her rolodex she used it.

If you are in an environment where agents or engineers need to derive answers because of the body of knowledge what should you do to encourage knowledge sharing? My best guesses at this time are:
  1. Acknowledge the value of deriving answers - your new solutions are going to be derived. Reinforce the rewards for contributing creatively derived responses.
  2. Remove obstacles to searching effectively, make sure your agents and engineers can easily give feedback, and communicate back the changes that are being made.
Is there anything I've missed?

1 To be fair there was one feedback method - an annual survey sent out by the database administrator. I was very open with my critiques of the knowledge base. When I met the database administrator he recognized my name. Fortunately he didn't take the critique personally.


No comments:

Post a Comment