TBM 236: The Paper-Cut Tax

Imagine eighty construction workers on a job site. Every couple of weeks, there is a safety issue on the site, and work stops until the issue is resolved. Pausing work delays when the building can start collecting rent. It's easy to put a price tag on the safety issues because there's a clear line between them and lost revenue as a function of time. It's also visceral—the job site is empty.

Now picture a product team suffering from dozens of paper-cuts. They are busy, but a lot of that busyness is low leverage—like juggling fickle priorities and rework, working around dependencies, putting out fires, writing and rewriting proposals, and fiddling with fragile tools. There's no empty job site; it's the opposite: people are in perpetual motion.

You're paying a high paper-cut tax (PCT)—as high, or higher, than the occasional empty job site. But it is far harder to put a price tag on the situation and advocate for fixing those issues.

Why?

It is not exactly correct to say that it is invisible waste, a common observation about waste in knowledge work. The issues are visible and felt on a local level very acutely. But visible and felt doesn't always mean quantifiable and explainable to people who lack the local experience or the domain experience—even when you have "objective data".

The construction foreman can go to pretty much anyone and say, "The job site was empty on Tuesday because of a safety issue, and no work happened," and be understood. If you've ever had to explain product development paper-cuts to someone in finance or without local knowledge of your team, you know how much harder it is. It's a minefield.

With product work, there's always something to do. If you get blocked somewhere, the next task is a browser tab away. There's a workaround for most problems—for example: how many retrospectives or meetings have you been in where people raise "annoying issues," and everyone nods in agreement? Still, weeks later, people are somehow making do with workarounds. Imagine a carpenter breaking a hammer and then three weeks later continuing to use the broken hammer. Only in very rare cases, when a truly critical system goes down, do you see an immediate response.

(Funny aside, I remember Slack going down and someone claiming they got more done that day than any day in the last year—which should tell us a bit about the nuances of product work.)

The next issue—perhaps even more important—is that discussing these challenges can feel like a mix of throwing other people under the bus, "bringing problems, not solutions," and making excuses. Some issues do have a clear root cause, but most don't. Case in point: the challenges of today are often the direct result of very pragmatic decisions in the past. The company wouldn't exist if things stayed stable without surprises or shifts in the landscape. How do you even talk about challenges like that?

Finally, realistically, many people believe that paper-cuts are the norm. In many companies, it IS the norm. People self-identify by wading through the muck. I call this Sisyphean Comfort (don't steal my new whiskey brand name). Some people in tech find a strange comfort in the constant, low-level adversity, perhaps because it feels more manageable than tackling systemic issues. The chaos becomes the new normal for them, and they adapt to it rather than challenge it. And hey, the money is good.

OK. So it's hard. But you can chip away at the problem:

1. Log paper-cuts immediately while they are fresh. Normalize the reporting of minor irritations and remove the stigma. Sometimes, "naming it to tame it" is the first step.

2. Stop demonizing "subjective experience." While hard metrics are useful, subjective experiences offer valuable context. Recognizing the value of individual experiences can foster a more empathetic workplace where people feel their concerns are taken seriously.

3. Create an environment where discussing paper-cuts is not perceived as assigning blame.

4. Clarify opportunity costs without aiming for precision. Even a rough estimate can prove to be extremely helpful.

5. Perhaps share and discuss this post with your team.