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.

Gardening Tips
A good library is like a garden.
Kode Vicious
https://queue.acm.org/detail.cfm?id=1870147

GitOps: A Path to More Self-service IT
IaC + PR = GitOps
Thomas A. Limoncelli
https://queue.acm.org/detail.cfm?id=3237207

System Administration Soft Skills
How can system administrators reduce stress and conflict in the workplace?
Christina Lear
https://queue.acm.org/detail.cfm?id=1922541

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.

Originally published in Queue vol. 17, no. 6—
Comment on this article in the ACM Digital Library

More related articles:

Adam Oliner, Archana Ganapathi, Wei Xu - Advances and Challenges in Log Analysis
Computer-system logs provide a glimpse into the states of a running system. Instrumentation occasionally generates short messages that are collected in a system-specific log. The content and format of logs can vary widely from one system to another and even among components within a system. A printer driver might generate messages indicating that it had trouble communicating with the printer, while a Web server might record which pages were requested and when.

Mark Burgess - Testable System Administration
The methods of system administration have changed little in the past 20 years. While core IT technologies have improved in a multitude of ways, for many if not most organizations system administration is still based on production-line build logistics (aka provisioning) and reactive incident handling. As we progress into an information age, humans will need to work less like the machines they use and embrace knowledge-based approaches. That means exploiting simple (hands-free) automation that leaves us unencumbered to discover patterns and make decisions.

Christina Lear - System Administration Soft Skills
System administration can be both stressful and rewarding. Stress generally comes from outside factors such as conflict between SAs (system administrators) and their colleagues, a lack of resources, a high-interrupt environment, conflicting priorities, and SAs being held responsible for failures outside their control. What can SAs and their managers do to alleviate the stress? There are some well-known interpersonal and time-management techniques that can help, but these can be forgotten in times of crisis or just through force of habit.

Thomas A. Limoncelli - A Plea to Software Vendors from Sysadmins - 10 Do’s and Don’ts
A friend of mine is a grease monkey: the kind of auto enthusiast who rebuilds engines for fun on a Saturday night. He explained to me that certain brands of automobiles were designed in ways to make the mechanic’s job easier. Others, however, were designed as if the company had a pact with the aspirin industry to make sure there are plenty of mechanics with headaches. He said those car companies hate mechanics. I understood completely because, as a system administrator, I can tell when software vendors hate me. It shows in their products.

Kode Vicious - @kode_vicious

Master of Tickets

Valuing the quality, not the quantity, of work

Related articles