Chasing Kill Rate Can Kill Your Productivity

I had a client ask me why they shouldn't be using Kill Rate as a daily driver of tech performance. It occurred to me I should turn the question and the answer into a blog, so here you go.

Email from client:

I was talking with Bruce yesterday about how we should be tracking lead time and cycle time instead of “How many tickets did you close today???”.

He mentioned a valid point that I need help with please: How does a tech measure that in the moment, day-by-day?

I guess the thought is, they can look at a ticket closure count and know that they’ve closed “x” number and need to close “x” more. We have our goals for lead and cycle (I believe no more than 3 days lead time and no more than 45 minutes cycle time) but I guess the concern is that’s not as “easy” maybe for a tech to register in their brain as a positive or negative feedback loop?

Help!

My response:

Ok, here goes....

1) Reminder of Terms:
Outcome - The desired end result
Driver - The thing that makes the outcome happen

2) Target best of breed metrics for:
Lead Time = 3 business days (any ticket introduced into the system will on average be closed within 3 business days)
Cycle Time = 45 minutes (any ticket introduced into the system will require on average 45 minutes of tech time to complete)

3) These are front-view driving metrics - i.e. We are constantly striving to lower them by managing the other 5 M's (Metrics + Manpower, Methods, Materials, Machine).
e.g. We improve the skills of the tech, get better techs, get better tools, improve process (five issues that happen most often - figure out how to do it in under 30 minutes, etc.).

4) These two are metrics for driving service delivery - used by managers - shared with the techs so they can think and strive with us.

5) Reminders:
- Agile relies on a highly accountable team of properly skilled individuals.
- We strive to manage the work not the people.

With all that said...

I have no problem using Kill Rate as a motivator (read: gamification) but it cannot be used as a Driving metric. It must be used as an Outcome.

If we push Kill Rate instead of support it, we get techs closing tickets just to make quota. Not always but often when they are having a bad day, when they feel lazy, when they feel the pressure of (leadership) pissing in their ear.

So by all means use it, just not as a daily metric to hit or be hit with.

I refer back to the highly accountable team.

Think about it; techs simply want to fix stuff. If they could cut through the work with ease (the mass majority of the work - the nebulous blob) they'd have really high Kill Rates.

But the reality is they run into rogues, time thieves, etc. that cause them to take longer or to have to escalate, or wait-work-wait, and so on.

Look at (Tech) - Give him nothing but tickets in his zone and he'll have the highest kill rate every single day without knowing what the number is.

If it were not for the rogues (all the tickets that are not straightforward, simple, easy, quick) every tech who works an honest day would have maximum Kill Rate.

So we manage the work (not the people), improve the process, keep tickets at the highest quality (because they move faster when the %CA is high), drink the Agile Kool-Aid, and the outcome is a consistently high Kill Rate.

You've come a long way and you're getting there.