“Our brains have just one scale, and we resize our experiences to fit.”
– Randall Munroe, XKCD
Month: July 2017
Pain, no gain
I suffer from cluster headaches. Every year and a half or so I live through a month or two of daily episodes of excruciating pain that calls for gobs of Excedrin, quite a lot of Sumatriptan, gratitude for the existence of automatic ice makers, and the inescapable sensation that I’m taking dumb pills.
No, I’m not looking for remedies, empathy, or sympathy. Let’s skip directly to pity.
Or skip it altogether. Now that I have your attention, let’s move on to pain’s relevance to your day-to-day working life.
Pain evolved to get our attention when something is wrong that needs fixing. Which is why migraines, cluster headaches and their kindred maladies are so annoying: The only thing that’s wrong is the headache itself.
Still don’t see the relevance?
Biologically speaking, pain is an indicator. It’s like a blinking light on a control panel that tells the brain something isn’t working the way it’s supposed to work. The brain needs this mechanism because the body is way too complicated for the brain to directly monitor all of its components.
So instead animal physiology includes receptors scattered throughout a critter’s anatomy. The brain doesn’t have to monitor. What requires attention calls for attention.
Only it’s easy to ignore a blinking light. Pain is designed to be hard to ignore. Pain says something isn’t working the way it’s supposed to work, so please do something about it RIGHT NOW!
KPIs (key performance indicators) and their metrics-based brethren are, for managers, what pain is for the brain. They’re a way for managers to know something needs attention without their having to directly monitor everything in their organization.
But (here’s the big tie-in! Drum roll please) … KPIs share both the blinking light’s and migraine’s limitations.
They’re blinking lights in the sense that when a KPI is out of bounds, it’s just a number on a report, easy to ignore in the press of making sure work gets out the door when it’s supposed to.
There’s nothing attention-getting about a KPI. It’s just a blinking light. Unless, that is, a manager’s boss decides to inflict some pain … perhaps “discomfort” would be in better taste … when a KPI is out of bounds.
KPIs can also be migraines, though, in the sense that it isn’t uncommon for a KPI to be out of spec without anything at all being actually wrong.
Migraine KPIs can happen for any number of reasons. Among the most important is the reason the first, and arguably best quality improvement methodology was called “statistical process control.”
Many KPIs are, that is, subject to stochastic variability, stochastic being a word every process manager should be able to use correctly in a sentence without first having to look it up on Wikipedia.
Sometimes a KPI is out of range because the effect it’s supposed to measure is the consequence of one or more causal factors that vary more or less randomly. Usually their variance is within a close enough range that the KPI is reasonably reliable.
But, stochasticism being what it is, not always. If the KPI looks bad because of simple random variation, the worst thing a process manager can do is try to fix the underlying problem.
The fixes can and often do push the KPI in question, or a different, causally connected KPI, out of range when process inputs return to normal.
As long as we’re on the subject of pain, you don’t have to have any for something to be wrong with you, which is why most of us have a medical check-up every so often, even when we feel just fine.
KPIs can be like this too. The IT trade is replete with managers who meet every service level they’ve agreed to and as a result think everything is fine when in fact it’s falling apart. Help desks are particularly prone to this phenomenon, because of a phenomenon the users to contact an offending Help Desk know about but the help desk manager doesn’t: Because they’re usually measured on ticket closures, help desk staff close tickets whether or not they’ve actually solved a user’s problem.
It’s the first rule of metrics: You get what you measure. That’s the risk you take.