Activity is not Progress (or, 'Did you really need to shave that yak')

Anyone who is accountable for any sufficiently-complex objective is constantly having their focus being pulled away from that larger goal by a thousand different fiddly tasks. Christened as yak shaving some time ago by a fellow at the MIT media lab, the concept has become a favorite shorthand in various programming and software development circles. I only heard of it this year, but it's helped to coalesce my thinking about focused work and the relationship between activity and progress.

In particular, I think it's helpful to occasionally check one's activity using what I'd call "root objective analysis".

Many people in technical fields are familiar with root cause analysis, where a problem or failure is analyzed in such a way as to determine its root cause. There are lots of flavors of root cause analysis, with Five Whys being popular among programmers due to the Joel Effect and probably some loose association between Five Whys and the lean development/startup methodologies that are all the rage these days.

In contrast, root objective analysis runs in the "opposite direction", so to speak: for any given activity, you trace the likely causal link between that activity you're engaged in, and the progress you want to make. In short: "Is what you're doing right now getting you closer to your end goal?"¹ If you do this right, or at all, you'll go down fewer dead-ends, waste less time, and prioritize the yaks you do shave so that you get to your desired end state sooner rather than later.

There's obviously a lot of fuzziness in any kind of speculative analysis like this; if there weren't, then project management would always bring jobs in on time and within budget. However, if your work often leads you far afield of your "main line" of focus, then asking yourself the question above from time to time may help you to ensure that every yak shaving you engage in is necessary, as opposed to a distraction caused by confusing activity for progress.

Yak shaving close to home

A yak shaving that is near and dear to my heart is the fable of the software developer and the PDF documents (not surprising, since we talk to a lot of developers who have worked with lots of PDF documents). There are many variations, but the most extreme goes something like this:

1. Joe the developer needs to get some chunk of data into his company's database (maybe it's financial data, maybe he's working with excerpts of academic journal articles – such details are mostly irrelevant)
2. The data is only available in PDF documents, and there's a lot of them. Thousands, perhaps millions of chunks of data in as many different PDF documents.
3. Joe's first thought is that he needs to build a function to extract text from these PDFs so that he can get at the data he needs.  But, after...
   • reading the 1,000+ page PDF specification,
   • adding support for the 8 different versions of the spec,
   • adding support for a half-dozen encryption protocols, and
   • adding support for extracting Chinese (or Japanese, or Korean, or Icelandic with its lovely ð ("eth") character) along with the embedded fonts that go along with it
4. ...Joe now has spent nearly a year building a one-off PDF text extraction library that (again, depending on the version of the fable) fails on 24% of the documents his company needs to access, and still doesn't run fast enough to finish in the batch window he has to work with.

Seriously, scouts-honor, I've heard this story at least 5 times…and each time right before or right after the developer/company in question purchased PDFTextStream to replace their homebrew PDF library. That, my friends, is activity without progress, yak shaving at its most epic.

1 Careful and clueful readers will recognize this as little more than a distilled version of OODA, the granddaddy of all decision-making formalisms.