My first small business wasn’t actually in the software industry. Back when I was a student, I did contract office jobs in the summer holidays to pay for things while I was studying. I got a feeling that I’d be happier self-employed than someone else’s employee, so after graduation I experimented with registering an Australian Business Number (ABN) and using it to do maths and sciences tuition. I went back to working for other companies eventually, but I learned a lot from the experience, and that know-how was extremely valuable later when I quit my full-time job to start my own little consulting business.

I might write more about that experience some other time, but for now I want to write about what’s been hardest for me to get used to: when you’re self-employed, no one cares how much work you do. What do I mean by that? Every software company environment is different, but most define “work” to be some weighted combination of things like this:

The great thing about these metrics is that they’re easy to measure if all you care about is a number. Unfortunately, they don’t prove productivity. Productive workers tend to do some “work”, but pointy-haired bosses have no way to distinguish between a productive worker and a “worker” who has zero or even negative productivity. This scare quotes “work” is what many people call “busywork”: work that’s meant to keep you busy, as opposed to productive. Busywork is an easier way to be busy than doing productive work, so many work environments effectively reward busywork. In fact, productive work is often effectively punished: a paid-by-the-hour employee who finishes an expected two-week job in one week gets paid half as much and has to find something to justify their job for the second week.

In short, simple metrics for work become victims of Goodhart’s Law:

When a measure becomes a target, it ceases to be a good measure.

Consciously or unconsciously, many employees develop the habit of doing busywork, and this habit can be really hard to break. To show what I mean, let me give a couple of (anonymised) real examples that show how insidious the busywork habit is.

Busywork at Initech

Initech has a very ordinary enterprisey office environment where most employees wear shirts and ties, although some more rebellious employees raise eyebrows by forgoing the tie. Junior employees should avoid raising eyebrows if they want a good career at Initech.

At the (very brief) time I was at Initech, one of the various pieces of in-house software was a report generator. Even though it was a custom tool written to do a very specific, repetitive job, generating the necessary reports always took a few weeks. There were no configuration files for the tool, so each report required manual configuration through a GUI, every time. This included a list of roughly a hundred checkboxes in a scrollable widget that only showed about one and a half rows at once. The scrollbar on this widget was awkward to use, making it difficult to verify that a report run had been configured correctly before starting. If it hadn’t been configured correctly, the results would be junk. The configuration wasn’t saved, so the job had to be restarted from scratch.

Each report generation would take several hours of running queries against a database. No one ever questioned that. It wasn’t possible to run a report generation overnight, or in parallel with other jobs, because the tool generated modal dialog boxes that needed to be clicked every few dozen minutes. The boxes didn’t give the operator any real information or choice, but all processing would freeze dead until that “OK” button was pressed. After the tool had done its work, generating the final report required manually putting pieces together in a spreadsheet.

In the most politically sensitive way I could, I tried suggesting a few small ways this process could be made more efficient and less error-prone, but this just raised those eyebrows. I was told outright that it was very important to include as much manual intervention into things as possible because “computers make mistakes”. The fact that I even thought the process could possibly be improved was taken as proof that I didn’t appreciate just how important the reports were.

Busywork at Initrode

Initrode is a cool company, the kind you might expect to come across on Hacker News. The employees don’t wear ties, and the office even has a games room. Many of the employees escaped from places like Initech, and love to tell horror stories from their past. Initrode isn’t like Initech. Initrode is big on automation and devops and “move fast and break things”. The engineers’ motto was to always automate and never do manual, repetitive tasks.

One manual, repetitive task was tuning server configurations once a quarter. Basically, someone would check the performance graphs and decide that, say, the Foo servers needed to be scaled up by 12% to account for new features added in the previous quarter, plus a bit more for a launch planned in the next quarter. When I tried it, it was a simple job that took under half an hour, including the time to context switch, and find and load the dashboards and configuration files.

Trouble was, the job was too simple, and kind of boring, especially for the bright, sharp people who worked at Initrode. Initrode engineers pointed out that it just wasn’t the company culture to do stuff like that manually, and started talking about how to automate it. What they came up with was a program that would model all their servers. With just a few well-chosen parameters fed into the model, the program would generate all the server configuration files at the push of a button. Automation!

The original proof of concept worked okay most of the time for simple cases, but needed a few fixes to handle more complex cases. But because the plan was to automate everything, the project quickly turned into an inner platform. The configuration files for the model became about as complex as the configuration files it generated.

Every quarter, someone had the job of tuning the model parameters, which (thanks to the fat abstraction layer) took slightly longer than the original task of tuning the server configuration. In practice, that person would also have to tweak the model itself to match changes in the system from the previous quarter. Also, each quarter, there always seemed to be a few (just a few) bugs or new corner cases uncovered in the integration with the underlying cloud platform. What was originally a half-hour job started taking a few days.

After some time (and a bit of resistance from fans) the “automation” was eventually thrown away, but I think the fact that the project lasted as long as it did is a good demonstration of how even enthusiastic, well-meaning people can end up doing busywork.

Fighting Busywork

For some people, busywork pays off. Obviously, if you’re working for yourself, or getting a fixed sum for a project, or working at a very small company, then busywork is potentially disastrous. Even if you’re in an environment that rewards busywork, you might be better off getting things done, putting them on your résumé, and finding somewhere else to work.

But being aware of busywork doesn’t make it easy to break the habit. Instead of trying to be perfect, I prefer to think of it like a business cost. Just like reducing unnecessary costs is a good complement to raising revenue, reducing unproductive work is a good complement to getting more time or learning new skills. Here are some tips I have for cutting the waste: