In support of Yak Shaving

I think 'shave those yaks' is good advice only for some yak-shaving situations. I see 'yak-shaving' as a description of a situation where you are nested so deep in subgoals that you've forgotten your original goal, at which point a good heuristic is to wake up and say "this is a lot of yak-shaving!" and think about what is going on that has led to an undesirable situation.

Thinking about my own applications of the term, I think there are 3 different kinds of problems which can lead to yak-shaving: avoidance, lack of mindfulness, and cascading problems/system failures.

1. you are procrastinating or being akratic or falling into perfectionism (closely related to procrastination), by deliberately overcomplicating something or trying to use fancy or shiny new techniques, which of course frequently lead to new subgoals because you aren't familiar with them yet.

   This is fine sometimes (you have to learn those new techniques somewhen) or if it's a kind of 'structured procrastination' (where the yak-shaving is itself valuable eg because it makes a neat blog post or useful software package), but often isn't. The usual akrasia/procrastination equation stuff, except it's being hidden under a gloss of superficial productivity. ("I can't write my novel, I have to clean my desk which requires [solving 15 deeper nested issues] which will take up all the rest of the day; I sure am a hard-working writer.")

   By calling it yak-shaving, you admit you are just faffing around and you then solve your problem the way you knew you should all along; or you can deal with why you are avoiding finishing, or whether you really want to do it at all. If you refuse to acknowledge the yak-shaving, then even if you 'shave the yaks' you'll just find another way to overcomplicate things or a different thing to waste time on or switch to procrastinating on social media etc.

2. you have been following a greedy strategy of taking the obvious option at each decision node; that you have now stacked up so many tasks to complete suggests that the greedy strategy has failed and you have fallen into a local pessima.

   Like with sunk costs, it's time to stop being so mindless, step back, think about it more globally, and ask if there's some better approach. Was there some entirely different strategy which seemed too expensive compared to your current path (which has actually turned out to be far more costly than predicted) and now looks cheap? Or are there any intermediate middle steps which are expensive but cut out a large number of other steps? Or perhaps all the paths are so costly that the top-level goal now no longer looks worth bothering with and you should just drop all the existing tasks and stop shaving the yak entirely.

   Programmers are particularly susceptible to this because the line between useful automation and immensely complicated time-wasting tinkering is a fine one indeed. This can be common in programming where you can say, build up a Rube Goldberg collection of shell scripts and Emacs functions and manual edits to text because you wanted to avoid writing a SQL function (because it would take 20 minutes of consulting the SQL documentation to get it right); but by the time you're consulting the Bash FAQ or resetting IFS variables to deal with a problem half an hour later, it's good to wake up and ask 'am I yak-shaving?' - and then you might realize that the data or problem has turned out to be sufficiently painful (eg lots of special characters or oddity in data formatting) that you can't catch all the special cases and you would've been better off writing the SQL query in the first place. In Godin's example, perhaps one should simply return the yak pillow and hope the neighbor won't notice the missing stuffing, or they will prefer to simply have it back rather than wait for you to fix it whenever, or simply bite the bullet of upsetting them a little; or order the hose on Amazon even if it costs $5 more just to get it done; or, pay the damn toll like anyone else; or finally, is waxing the car worthwhile at all (I mean really, who notices)?

   Here 'yak-shaving' serves as a useful mental trigger which can break you out of the myopic problem-solving loop. This sort of yak-shaving is usually quite bad, and if you don't break out of it soon enough, can lead to considerable exhaustion and waste of time, and lock you into bad long-term decisions. So it's good to periodically ask, if you aren't making progress on a problem of intrinsic interest to you, "so all this work, what's it for anyway? If I were starting over from scratch - knowing what I do now - is this really how I would approach this problem?"

3. what you are doing is the best way to solve the problem overall, it's just that things have been going wrong and you've been running into continual problems, so you find yourself nested many layers deep dealing with the cascade of problems and documentation

   ...all your (encrypted) backups are broken because you can't get the most recent decryption key because your drive is corrupted because you were running the GPU 24/7 (to name a recent example of mine) so you're in a LiveCD trying to mount the drive trying passwords trying...

   In this case, in addition to simply shaving the yak, you need to do root-cause analysis - you are experiencing what might be called muri or the swiss-cheese model of failure - and in addition to figuring out how to solve each proximate problem on the way, figure out why they happened & how to prevent them in the future. In programming, this frequently entails filing bug reports & document patches, formalizing your recovery methods as scripts or programs, adding tests or redundancy or upgrading hardware, and writing post-mortems.

   So the OP interpretation of a stack of nested related problems here is simply a form of this. But here, simply yak shaving may solve the fur problem & allow popping, but it's not enough. It's not enough to simply close those open loops, or have a system for recording open loops. Root-cause analysis is needed. Why did the yak fur fall out of the pillow in the first place and how can it be prevented ever again? Why didn't he have his EZPass in the first place? Why wasn't the hose put on the weekly shopping list (there is a shopping list right?) and replaced long before? And so on. Without attacking problems at the root, you might as well buy a seasonal pass to the zoo, because you are merely applying bandaids to a complex system failing, and if you don't do any root-cause fixes, eventually your problems will seriously stack up and you'll find yourself hit by a so-called 'perfect storm' (actually perfectly foreseeable & inevitable) and then you'll really be sorry.

So 'yak-shaving' is a useful heuristic for keeping planning stacks nested not too deeply by periodically asking whether one is falling prey to one of those 3 failure modes, and need to break out of the yak-shaving by an appropriate countermeasure of either: interrogating the reasons for the akrasia; finding a better approach; or prioritizing fixing the root-causes of needing to yak-shave (rather than focusing on the yak-shaving).

This perspective suggests "don't yak shave" is a classic deepity. The superficial true meaning is "don't waste time on unimportant sub tasks" and the clearly false but immediately actionable meaning is "don't do subtasks". If you've already clearly identified which tasks are on the critical path and which are not, the yak shaving heuristic is useless, and if you haven't, it's harmfully misleading.

Surely, if you find yourself yak-shaving, then it means that things around you are broken. And usually adjusting brokeng things is good.
But what distinguishes yak-shaving from structured procrastination is that yak-shaving is a form of avoidance: yes, the hose is broken, but do you need to buy a new one or you can just temporarily fix it with tape? Do you really need an EZpass from your neighbour or you can just pay the toll? And so on.
If you yak-shave, you're putting unrelevant problems in front of the relevant ones in order to avoid the ugh field projected by the main issue.

We had this problem at work quite a few times. Bosses are reluctant to let me do something which will make things run more smoothly, they want new features instead.

The when things break they're like "What! Why is it broken again?!"

I would have benefitted from about two detailed real-life examples, because while you seem to make sense, I find your reasoning to be slightly too abstract for my puny mind. But cool article. Thanks.

Quite right! Who even came up with "Don't shave yaks"? It sounds like something someone too lazy to shave some damn yaks and get the problem fixed would invent to justify not solving the problem!