November/December 2019 issue of acmqueue The November/December 2019 issue of acmqueue is out now

Subscribers and ACM Professional members login here

Kode Vicious

System Administration

  Download PDF version of this article PDF

Master of Tickets

Valuing the quality, not the quantity, of work

Dear KV,

I hope it's OK to write a letter to you as I'm not a programmer, but I enjoy your columns (very funny and informative!) and I see that you sometimes talk about topics other than code. I work in IT support, and the company I work for evaluates us based on the number of tickets we close. This seems to be a poor way to judge performance, as it's easy to game the system. For instance, you can take a lot of trivial tickets and close them quickly and look like a rock star. I guess my question is more about how to value work, which is maybe too big a topic for a KV column.

The Tickets That Exploded


Dear Tickets,

Questions about how work is valued can definitely go beyond the scope of a short column, given that there are whole areas of politics, economics and the social sciences devoted to these questions. It is also the case that wars have been fought over this topic, both cold and hot, and still the question is unsettled.

Many silly metrics have been created to measure work, including the rate at which tickets are closed, the number of lines of code a programmer writes in a day, and the number of words an author can compose in an hour. All of these measures have one thing in common: They fail to take into account the quality of the output. If Alice writes 1,000 lines of impossible-to-read, buggy code in a day and Carol writes 100 lines of well-crafted, easy-to-use code in the same time, then who should be rewarded?

Plenty of companies have chosen the easier metric—which is to reward Alice—because she appears to be more productive. This false measure of productivity stems from the nature of industrial work from which modern knowledge work (which includes IT and programming, as well as plenty of other endeavors) sprang. In an industrial system, the steps required to make something like a shirt are broken down (some might say atomized), such that any able-bodied worker could do the single task assigned them for hours on end at a measurable rate.

In such a system, the people were used as machines and were eventually replaced by machines, because what was needed was not knowledge or skill but simply the ability to assemble—based on a predetermined plan—a set of objects, such as sleeves, collars, and buttons, into a larger object, a shirt. Of course, if you have ever shopped for a shirt (you do wear clothes to work, I assume), you know they vary in quality. Cheap clothing is often made by machines and with minimal human intervention, because a machine can be told how to assemble a shirt, just not always a very well-tailored one. The highest-quality, expensive clothing is still made in part by hand, because making something of quality requires not just rote movements, but also intellect and thought.

The very same tug of war has existed in knowledge work since its inception. What management wants is maximum output for minimum input, and input in this case is you, the human, who is doing the work. When management implements silly metrics such as those listed above, you have only a few choices.

The first choice is to game the system such that you can actually do minimum work to get the maximum benefit, usually by taking on trivial tasks that can easily be completed and will show at the end of each month that you accomplished more tasks than anyone else. After a while, that game becomes boring, but in large organizations you can do quite well with it, get promoted to management and then foist your own silly metrics on your new underlings, thereby perpetuating the pain and suffering you once suffered and helping to bring about the downfall of civilization through a vicious cycle of stupidity. I find that this is the most common and unfortunate reaction.

A second choice is to take on hard and challenging tasks, to learn from what you've taken on, and to hone your skills. You can then take those skills to a company that values good work and write a flaming goodbye letter to your former company. You might even mail it to everyone before you leave or just post it on one of the many anonymous company review sites that now litter the Internet.

A third and probably more difficult choice is to convince management to choose useful metrics, ones that take into account not just the rapidity but also the difficulty of the work being undertaken and the quality of the output. The problem is, I fear, that you are in an organization where this sort of discussion cannot take place. Once some companies have a metric, they will hold on to it like a drowning person, even if they find out their perceived float is actually an anchor.

KV favors option two. Learn what you can and then go find a place where your work is valued and where you are not simply being used as a tool.



Related articles

Gardening Tips
A good library is like a garden.
Kode Vicious

GitOps: A Path to More Self-service IT
IaC + PR = GitOps
Thomas A. Limoncelli

System Administration Soft Skills
How can system administrators reduce stress and conflict in the workplace?
Christina Lear


Kode Vicious, known to mere mortals as George V. Neville-Neil, works on networking and operating-system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor's degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. Neville-Neil is the coauthor with Marshall Kirk McKusick and Robert N. M. Watson of The Design and Implementation of the FreeBSD Operating System (second edition). He is an avid bicyclist and traveler who currently lives in New York City.

Copyright © 2019 held by owner/author. Publication rights licensed to ACM.


Originally published in Queue vol. 17, no. 6
see this item in the ACM Digital Library


Follow Kode Vicious on Twitter
and Facebook

Have a question for Kode Vicious? E-mail him at [email protected]. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.


Adam Oliner, Archana Ganapathi, Wei Xu - Advances and Challenges in Log Analysis
Logs contain a wealth of information for help in managing systems.

Mark Burgess - Testable System Administration
Models of indeterminism are changing IT management.

Christina Lear - System Administration Soft Skills
How can system administrators reduce stress and conflict in the workplace?

Thomas A. Limoncelli - A Plea to Software Vendors from Sysadmins - 10 Do's and Don'ts
What can software vendors do to make the lives of sysadmins a little easier?

© 2019 ACM, Inc. All Rights Reserved.