the law of small annoyances

A little neglect may breed mischief ...
for want of a nail, the shoe was lost;
for want of a shoe the horse was lost;
and for want of a horse the rider was lost.

We are all shaped by the things we spend our time on, both in the abstract metaphorical sense of character-building and in a direct physical sense.

I'm reminded of this latter half as I recover from a bout of upper back pain, brought on through a combination of long hours at the keyboard and high-intensity foam sword sparring. As it turns out, both these activities place a lot of strain on the upper body. If only I'd known sooner...

...except, in some sense, I did. A few months ago, I had a couple of therapeutic massage sessions for my upper back. At the time, it was a small feeling: a bit more tension than usual, an occasional cramp when looking down, a slight discomfort when performing certain exercises at the gym.

(As for the massage, many thanks to LEGO for providing this excellent benefit, for which I'm immensely grateful. After working with the public sector in Canada - which, to be clear, was a highly fulfilling experience - I'll never take perks like this for granted again. I could rant for days about how denying public servants reasonable benefits at work in the name of "taxpayer dollar efficiency" is a false economy, but that's a separate article.)

I tolerated the small feeling, and it became a larger feeling, and then an Actual Problem - and here we are. To my credit, I now take more frequent breaks and switch up my body position throughout the day, and I'm adding upper back and core exercise to my strength routines (with help from Nørrebro Fysioterapi). But it shouldn't take Actual Problems to make these changes. I would have been happier and less in pain if I'd taken it seriously when it was "just" a small annoyance.

Small annoyances crop up in many areas of digital product delivery. Many have the potential to become larger (and thoroughly avoidable) annoyances.

Testing, for example. Say your application is hard to test in some way - maybe you've never written end-to-end tests, or component-level UI tests. It's hard to do, so people don't do it. People don't do it, so subtle bugs slip through. Bugs slip through, and some of them turn out to be critical bugs - the kind that should have blocked a release. One of these takes down your application long enough to cost you a key customer, right at a crucial time of year.

Or backups. This is a different class of annoyance, a friction that scales as you grow. You have some hacked-together database backup pipeline. Your application grows larger, your database balloons. Backups become more expensive and time-consuming to maintain, so you don't maintain them, let alone test them. Your database fails. You've never tested the backup, so it doesn't work. Now a database failure becomes a company failure.

The same is true of non-technical annoyances. You have an open office plan, the kind that's in vogue among modern cost-conscious businesses. Several of your engineers find it hard to focus in this environment. They bring this up for a while - and then stop. You think the problem is resolved.

They've also been asking for better devtools, maybe a small budget so they can make their own decisions here. They bring this up for a while - and then stop. You think the problem is resolved.

Next quarter there's an unexpected crunch, and instead of meeting the challenge, half your team quits. Or maybe they don't quit, but they no longer care if the challenge is met. Was it the crunch? Was it the repeated failure to make them feel heard, even in some small way? You'll never know - but I'd bet it's the latter. Small annoyances, unaddressed, compound over time. They build in the mind to take on outsized importance.

Of course, there's a balance. As with all advice, it's possible to take this too far - to find that you no longer tolerate the slightest setback, or to get caught up chasing down every small problem without thought to priority or agency. This, too, is a recipe for disaster.

Especially in large organisations or systems, many things are outside your sphere of influence - and even in smaller organisations, we all operate within larger systems, so don't think you're immune to this effect while operating in lean startup mode.

In a complex digital product - or any creative endeavour, really - there's always more polishing that could be done. A better architecture. A cleaner design. More performant implementation. Refactoring, refactoring, refactoring. The one data model to rule them all, at least for the next six months. The lack of polish can feel like a crucial annoyance - if you're not clear on what you're solving for.

But remember: even if you don't solve every annoyance, there's still value in making it clear the annoyance is heard rather than dismissed, and in clearly communicating the reasons it can't be solved. Maybe rethinking the open office plan means convincing upper management, and helping your organisation build a deeper understanding of what digital work requires - and that's a larger project than you can take on.

Maybe getting solid test coverage isn't the priority right now - you need users, period, and are temporarily willing to tolerate lower coverage to achieve that. (OK, this isn't a great reason, but it is a common reason.)

Still: let people who feel the annoyance know why it can't be addressed. Maybe you'll find some smaller piece of that annoyance you can address.