When is yak shaving okay?
And how to think about tradeoffs when it comes to automating manual processes
I was recently reminded of this lovely phrase…
And have been using it in as many conversations as possible, so it felt only fitting to write about it in this week’s newsletter as well.
YAK SHAVING
/ ˈjæk ˈʃeɪvɪŋ / Noun
Programming lingo for the seemingly endless series of small tasks that have to be completed before the next step in a project can move forward.
To bring this to life, here’s a non-technical example (source):
You want to bake an apple pie, so you head to the kitchen.
In the hallway, you notice some paint chipping on the wall.
So you walk to the hardware store for some paint.
On the way, you pass a bakery and stop in for a cupcake.
While eating the cupcake, you feel a pain in your mouth. It’s that cavity that you’ve been putting off.
You pick up your phone to call the dentist to make an appointment, but you see a notification from your friend Cher, who’s having a party.
You don’t want to show up empty-handed, so you stop for a bottle of wine.
(For the nerdier readers, find more examples in this Reddit thread.)
So, when is yak shaving okay?
If the downstream activities that I suddenly “must” do are things that I’d otherwise avoid (that I probably should do), then I usually set myself free to do some yak shaving. For example, at work, the yak shaving might entail fixing a broken SQL query or a slightly broken spreadsheet. It’s likely hobbling along and getting 75% of the job done, or I’ve developed a silly workaround. But it’s probably not in a good state for the long run and ideally, I should patch up the holes.
If the downstream activities that comprise the yak shaving are not along the lines of infrastructure investments or strengthening the foundation, I will generally take into account whether I enjoy these activities, if there’s something I’ll learn (a new skill or a new tool), and if it will truly make the end result of the original task better.
And what does this even have to do with automating manual processes?
Automating manual processes is probably the single most common instance where I find myself highly likely to fall into the yak shaving trap. Whether at work or at home, I often catch the thought: ‘I seem to spend a lot of time doing this repetitive, manual task. Should I automate it or somehow improve the manual process?’
This thought process has become increasingly prevalent with the advent of AI tools. I hear, “This is a great use case for LLMs, let’s try using those!” (I’m also guilty of saying this.) However, the reality is that countless hours are spent on trying out the supposed flow and addressing the bugs and making tweaks. And then, once some sort of minimally viable output is achieved, hours are then spent on QAing the output to make sure it’s actually accurate and usable.
There’s an xkcd comic that captures a lot of the opportunity cost / tradeoff math that we should probably be doing more often:
What are my key takeaways?
Shave yaks if it’s accretive to you / your team (e.g. you learn something, you invest in truly needed infrastructure improvements, etc.)
Before you pursue automation or improvement of a manual process, calculate the time you will save and the breakeven vs the time required
Also, it’s just fun to say “yak shaving” out loud