I hope it is OK to write a letter to you as I am not a programmer, but I enjoy your columns (very funny and informative!) and I see you sometimes discuss 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 is 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
Questions about how work is valued can definitely go beyond the scope of a short column, given there are whole areas of politics, economics, and the social sciences devoted to these questions. It is also the case that wars—both cold and hot—have been fought over this topic, 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 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 mentioned here, 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 difficult and challenging tasks, to learn from what you have 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.
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?
The Digital Library is published by the Association for Computing Machinery. Copyright © 2020 ACM, Inc.
No entries found