Today, we are going to talk about yaks. More specifically, shaving yaks.

I am speaking, of course, about metaphorical yaks. Much less messy that way, you understand.

I came across the term “yak shaving” a few days ago. I find it a particularly useful phrase, because it gives me words to describe a concept that I didn’t otherwise have a specific term for. And, of course, it lets me go around talking about yaks, because why not.

You might be wondering what yak shaving actually is, though. Let me give you an example featuring a problem I was trying to solve recently:

A particular windows computer I needed to access was no longer joined to the domain. Normally joining a computer to a domain is easy as long as you have a domain admin account, which I did. Fancy people have cool things like domain admin accounts, obviously.

But there was a problem. Because the computer wasn’t talking to the domain anymore, I couldn’t log in with my domain admin account – or, for that matter, any domain account at all that hadn’t previously logged into it.

The fix for this was to create a new local admin account, which can be done easily if you can boot to a flash drive. Unfortunately, all the flash drives I had on hand were only 4GB, and the Windows 10 media creation tool no longer lets you use flash drives that small to create a windows installer. So, I got some new flash drives. They were shiny.

Next, I used the media creation tool to create a windows installer on the flash drive. Or, at least, I tried to, but it didn’t work. Long story short, running it on a normal domain account profile but with domain admin privileges (it needs to be run with admin rights) errors out, but if you log into the computer as a local (non-domain) account, it works fine. Because… Microsoft.

So, with windows installer in hand, I figured I was on the home stretch. But, of course, no. Because this computer also had a BIOS password, so I couldn’t boot to the flash drive. This is actually an unsolved problem still, so we will end the chain here.

Think about it. What problem am I currently solving?

I need to reset the BIOS password on this computer.

What was the original problem?

I cannot log into this computer.

Look how many steps there are between these two tasks. Every single step is required. You start trying to solve one problem, and end up with all this excess baggage that you must get through before solving the actual problem.

This is yak shaving. Yak shaving is the chain of unexpected, unrelated and prerequisite steps you must complete before finishing a particular task.

Or, as more simply stated by Scott Hanselman:

Yak shaving is what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.

Why is it called yak shaving?

The origins of the term are rather obscure. Apparently it was popularized by somebody at MIT in the 90s who took inspiration from a cartoon on Nickelodeon called The Ren & Stimpy Show. Apparently it was a Christmas special which included some kind of yak shaving ceremony, because why not. And so naturally we now use the term for something completely unrelated.

English is weird.

What yak shaving is not

I think in order to be a useful term, yak shaving must be defined narrowly. For example, yak shaving is not being distracted by unrelated but useful tasks while working on a task. Allow me to elaborate.

Suppose I was writing a blog post, and I saw that my web browser has an update available. That is a useful update, no doubt, and I should apply it. But I don’t need to apply it in order to write the blog post. Those two tasks do not depend on each other.

Alternatively, let’s say you are browsing the web researching a problem, and suddenly remember something else you needed to do and you start working on that. This is a distraction, but it is not yak shaving because these two tasks do not depend on each other.

What yak shaving is

I have already defined what yak shaving is, but I think more examples help solidify the concept. First, let’s start with printers.

Example #1

Printers are definitely in cahoots with the yaks, I am sure of it. Nothing brings work to a grinding halt more often than printers, I swear. They are just so terrible.

A common example I have seen is when you need to print a document, sign it, then scan it. The actual task you are working on is paperwork.

So let’s say you navigate to the document, press the print button, and pray. But it doesn’t print, because why would it. It isn’t like it was designed to do THAT EXACT THING OR ANYTHING. But I digress.

So the printer isn’t working, and you have to fix it. And, because printers are printers, let’s say it takes you half an hour to accomplish this. So you fix the printer and it prints. Great.

Now you sign the document, scan it, and send it off. Easy enough. But think. When you planned out your day and decided what you wanted to accomplish, you also made mental time estimates. You know what wasn’t in those time estimates? Fixing the printer for a half hour. Because fixing the printer was not your actual task. It was just a required subtask in order to complete the original task.

You could argue this one is on the line because it is technically a sequence of actions and not a chain. Also, it has a “depth” of 1. That being said, I think the term yak shaving still applies, because the printer problem was unexpected, mostly unrelated, and most definitely not the problem you were actually trying to solve.

Example #2

One thing I have noticed recently is that the more people are involved in solving a particular problem, the longer it takes. For example, ask any group of 10 people what color you should paint a wall – you aren’t going to get a quick answer to that question (this actually has its own term, bikeshedding).

This problem is substantially compounded when you are completing a technical task and require other people to make certain technical changes on their end before you can proceed on your end. For example:

Recently, I was tasked with setting up an iPad. Now, setting an iPad up itself is pretty trivial, but there was a slight wrinkle in this case: I wanted to create a new apple id for this iPad which wasn’t tied to anybody’s name or personal account because I have run into several iPads for which the apple ids have been long lost for this exact reason.

So, I created a new email address under our domain and setup the apple id based on it.

Wait, no, I didn’t. That is what I wanted to do. What I actually did was ask some other guy to setup the email for me, because I don’t control the email server. So I wait a day or two.

They got back to me and said I needed to create a group in active directory with a certain naming convention, and then it would automagically sync over to the email server. Piece of cake.

But three days later, nothing had synced. So I send another email to this guy – let’s call him guy #1 –  and wait another day.

He gets back to me and says the syncing must be broken, and that he is waiting for somebody else – let’s call him guy #2 – to provision a new server so the syncing software can be setup on it. Apparently it wasn’t supposed to be on the original server in the first place, and probably never actually worked there. So I am waiting for guy #1, who in turn is waiting for guy #2 to setup this server.

Another day or two goes by, and then I learn that the server setup is being delayed because guy #2 is waiting for guy #3 to make a DNS change and, independently, guy #4 to make a firewall change.

Think about it. What is my problem? I need to setup an iPad. And yet, I am waiting for three or four people (all on different teams, of course) to complete my task. What should have taken fifteen minutes took over two weeks.

Now granted, it didn’t take two weeks of my time. Probably closer to three hours (which doesn’t take long to reach when scheduling meetings with multiple people). But it is still rather frustrating to hit so many roadblocks that weren’t the actual problem I was trying to solve.

Example #3

Yak shaving is also a frequent occurrence when programming. And unlike example #2, it doesn’t even take multiple people to have this problem. Generally speaking, it goes as follows:

First, you try to implement a new feature A.

Then, you realize you can’t implement A unless you change another part of the application that is closer to the core, B.

But if you make change B, you will also break unrelated, non-core component C, because C was made based on the assumption that B would work a specific way and B no longer will work that way once you change it in order to add A.

So in order to add A, you first modify B to give new APIs for C. You then rewrite C using these new APIs. Next, you make the breaking changes in B (that no longer break C due to the new APIs). Finally, you implement A using the new functionality in B that originally would have broken C.

And that is if you are lucky and changing C didn’t break even more things. These kind of problems are inherent in software, and this is why modern software design places such a large emphasis on modularity and loose coupling.

Conclusion

Right now, I don’t really have a conclusion. I wrote this article primarily because I learned the term and realized it describes a common situation I encounter.

In theory yak shaving is bad, because it means you are spending time working on tasks that you didn’t intend to work on and that weren’t priorities. That doesn’t mean the subtasks completed for any particular yak shave weren’t useful, though.

For example, in the first example I listed about trying to login to a domain computer, one of the steps had to do with fixing the media creation tool. This was not a problem I had encountered before, and I learned how to solve it. And more generally, you are almost always going to learn something new while yak shaving, because if you knew how to do all the subtasks already it wouldn’t take you a long time.

Another thing to note is that problems you solve while yak shaving may actually be core problems that would affect other tasks in the future. For example, when I was trying to setup the iPad, my original problem was that I couldn’t create a specific email address. But the problem that affected email would affect any new email I wanted to create.

If I never setup the iPad but later wanted to create a different email account, I would have had the exact same chain of events, but the trigger event would have changed. In other words, this yak had to be shaved. In fact, had I known we had this email problem in the first place, it would have been high priority enough to become a primary task on its own.

So, in this particular case, the subtasks were valuable to complete. The only real problem is how wrong the original time estimate was, and in particular how working longer on this particular task disrupts other scheduled priorities.

Here you go, I made one of those fancy takeaway lists:

• Make sure the yak shave you are embarking on is actually worth it. Sunk cost fallacy still applies with yak shaving. You can quit once you realize it is getting too deep.
• Consider splitting up a particular yak shave into multiple primary tasks, and reorder priorities to see if it is still worth doing. This helps you decide if individual subtasks are valuable (i.e. are they core problems).
• When considering the original task, schedule accordingly. Unfortunately, I don’t have an answer for how to do this, because making accurate estimates is notoriously hard. Start with the general axiom that initial estimates are usually optimistic and you should probably at least double them.

Go shave some yaks. Or ride them off into the sunset, I don’t care.