Category Archives: People Management

Evaluating People By Metrics


Harvard Business Review has an excellent post discussing people evaluation through metrics. This is not a new topic for customer support managers. Operating in a heavily instrumented and measured discipline, it is easy for support management to focus on the measurable performance portions to evaluate their employees and ignore those that are more qualitative.

Over the years I have seen many different metrics for measuring and evaluating employees, from rating on a customer satisfaction scale to number of cases resolved, through a plethora of other metrics. The biggest, and most frequent, challenge was the attempt to evaluate individuals’ performance along the same scale, regardless of their formal role or how they operate. For example, most of us are familiar with the individuals who can process a large number of cases very efficiently, and with others who excel at methodically analyzing the most complex cases, one at a time. Both these individuals may carry similar titles, but evaluating them along the same performance guidelines is futile and frustrating to the employees and their managers.

A far better way to evaluate employees is to evaluate each along their role they play in the team, their strengths and the improvements their managers would like to see. Yes, this requires a greater involvement on the managers’ part as opposed to cookie cutter evaluation criteria, and it definitely makes stack ranking much harder, but I do believe that this system is a much more positive way for managing people and will create a much better functioning organization.

Making The Case For Publishing Knowledge

Employees frequently see knowledge management initiatives as a way to siphon off their knowledge in favor of a cheaper / automated / whatever option (“you want us to document everything we know so that you can fire us and send our jobs to …”).  It is not an easy discussion for managers to win, and to even stand a chance must be presented in a positive rather than negative manner.

The series of charts below came to life in support of this goal. They attempt to open the discussion by presenting the personal benefit for employees to participate in a knowledge management scheme and publish what they know.

The premise behind these charts is that employee pay is determined by their top level skill. However, those same employees spend only a fraction of their time at that performance level and the majority of it at lower levels. This situation is bad for all parties.  Bad for employees since they do not get to exercise their most critical skills frequently enough and therefore can’t expand their abilities and knowledge. It is bad for the company since it is paying for skills it does not fully utilize and will likely be too busy doing other things when needed.

When we ask employees to think about their skills, they usually tend to think about their top skill – “I am a system administrator with 20 years experience”.  This skill determines their pay and organizational status.  When we look at each employee skill we can draw a continuum from zero to maximum skill:

Now, to determine whether the company is receiving the full benefit from what it pays its employees, and whether employees are utilizing their top skills we need to determine what keeps our employees busy and where they spend their time.  We are likely to see a distribution similar to this:

Clearly this is not an ideal situation.  A far more desirable situation would be shifting the organization to spend much more of its time at the top end of their performance level. It is good for the employees as well as the company since this is where they generate most value for the company as well as themselves. The chart, therefore, would shift to look like the green section in the figure below:

This chart shows that some of the lower skilled work (marked in red) is either eliminated through collaboration with engineering, or, more likely, handed off to to entities down the value chain. For example, self service plays well into this scheme, as do reseller training and enablement, further training and empowerment of the call center team, and so on.

What’s your experience in driving cooperation with knowledge management initiatives? What worked? What did not?

Tiers Or No Tiers?

John Ragsdale has an excellent post about the cost differentials between escalated and non-escalated cases across support tiers. The case for eliminating tiers in support has been made by quite a few support industry members, here is one example, by Phil Verghis.

When looking at multi-tier organizations, we should do that from three perspectives, the customers’, the support employees’ and the case that’s being resolved.

From the customers’ perspective multi-tier support does not generate any benefit. In many cases they have to explain the problem to someone with not enough knowledge or experience to handle it, only to have to explain it again to someone more qualified when the case have been escalated. As Phil notes, there is little to no recognition of the customers’ knowledge and experience or the circumstances of the problem.

From the support employees’ perspective, the tiered model presents several challenges. First, it does not allow them to exercise their skills beyond the limits defined for their tier. The model also encourages exclusive thinking, where higher tiers have a disincentive to share knowledge and coach lower tier employees for fear of losing their relative advantage.

From the case perspective, the journey becomes really fascinating:

  1. Case opened, customers describe symptoms to the best of their ability
  2. Tier One researches case, calls customer for additional information, can’t find a solution, needs to escalate
  3. Tier One must qualify the case for escalation, sometimes fill a long form or go through some other process
  4. Case is escalated, Tier One reviews the case with Tier Two
  5. Tier Two begins to research the case, often repeating many of the steps performed by Tier One
  6. If Tier Two is successful resolving the case, fine. If not escalation to Tier Three repeats the entire process

A good way to review this process is through the perspective of Lean methodologies.

So, what can managers do to shorten the case life, reduce the amount of unnecessary work involved in the case, and make their employees and customers happier?

Simple, bring the knowledge to the case, instead of the case to the knowledge.

If we think about it, many of the developments in support, at least those focused on knowledge, are aimed at two goals. First is the accumulation of all knowledge in the extended organization through KCS and user communities, and second is the ‘democratization’ of this knowledge, bringing it as close to the problem as possible. Support organizations should act in a similar manner when managing cases and bring the knowledge, and the person holding it, to the case and the person attempting to resolve it. By doing so the organization gains knowledge transfer that happens better through collaboration than through escalation. It eliminates the cumbersome, overly bureaucratic escalation checklist, and saves its customers the need to repeat the story every time the case is escalated.

There are two prerequisites for such a transformation to take place. First is the need to build a map of the knowledge in the organization, who has it, at what levels, and who are the go-to specialists, and a process to dispatch cases according to this map. Second, and more complicated, is the transition in roles that has to take place. Members of the higher tiers, who until now have been protected by a moat of forms, case handoff processes and chargebacks as well as exclusivity and status will now have to rub shoulders with Tier One employees and proactively guide them through complex cases. The situation becomes more complicated in case the support chain is split along tier lines between, say Sales and R&D, which introduces executive politics into the mix. Indeed, observing multiple support organizations, it is easy to get the impression that multi-tier organizations are born due to either the need to preserve technical knowledge or due to organizational mistrust.

What’s your experience with multi-tier organizations? Does it work for you? Did it fail to deliver? I’d love to know.

PS: As I was writing this entry, Phil added a link to story summarizing the experiences of Red Hat’s support organization going through a tier elimination exercise. It is very interesting and worth reading, including their lessons learned on implementing change.

What Can We Learn From a British Sandwich Chain?

This past Sunday, The New York Times published an interesting and well written story about Pret A Manger, a chain of British sandwich shop with a few stores in the UK and apparently exceptional customer service. As I was reading the story, the parallels to managing enterprise customer support teams were interesting and obvious, especially their focus on people.

Most interesting, at least to me, was the intensive focus on teamwork and attitude. From team interviews to training, measurement and compensation, the entire system is focused towards the overall performance of the store, as opposed to the individual performance of single employees.

Here are some additional points I found interesting:

  1. Regular inspection of the operation, but also that of the competition – easier in retail than it is in enterprise software, but still doable (think about using your IT department, asking customers and your friends and acquaintances)

  2. Understanding customers’ demands and keeping in mind they may change between markets, learning the market and adapting quickly are mandatory

  3. Set up your operation and adapt staffing levels to the changes in volume. This may sound trivial, but if it is, why do we wait in line or put on hold in so many places?

So, where have did you find interesting lessons and inspiration?