Good Strategy / Bad Strategy by Richard Rumelt.

Recently I read Richard Rumelt's business classic Good Strategy / Bad Strategy which, beside clarifying what strategy actually is and why any organization would benefit from having one, offers many insightful stories and anecdotes on economics. One I found particularly amusing was about Andrew Carnegie, who was arguably the most successful business man of his day, being ranked the richest American for several years at the beginning of the 20th century.

The Principles of Scientific Management by Frederick Winslow Taylor.

In 1890, Carnegie attended a cocktail party in Pittsburgh where he was introduced to a young man named Frederick Taylor. Taylor was one of the first business consultants and would go on to publishing The Principles of Scientific Management in 1911, becoming a widely influential economic thinker. In 1890 though, Carnegie was apparently not impressed by Taylor's ideas, and supposedly wanted to mock him by proposing the following: “Young man, if you can tell me something about management that is worth hearing, I will send you a check for ten thousand dollars.

Mr. Carnegie,” Taylor replied, “I would advise you to make a list of the ten most important things you can do. And then, start doing number one.

History has it that a week later, Taylor received a check for ten thousand dollars from Andrew Carnegie.

My approach to tasks

Unknowingly (and without paying ten thousand dollars for it) I've been following Taylor's advice for quite a long time. My approach is so simple that I refrained from mentioning it in my post about prioritization, but the Carnegie/Taylor story made me rethink that. Here's what I do: I typically start my work day by making a list of 3-5 things I want to accomplish that day, ranked by priority. As the day progresses I tick items off that I finished, change priorities if required, or add new things as they come up. Finally I move any unfinished items to the list for the next day if they still feel important. Simple, right?

Good tasks

Over the years I developed some restrictions to what can and what can't go onto the list. "Solve world hunger", "Read 'War and Peace'", or "Increase sales revenue" for example may be worthwhile pursuits, but they don't make sense on my daily task list. "Fix bug #123", "Write a blog post about making lists", or "Research which third party component we should use for feature XYZ" on the other hand are good candidates. Here are the most important criteria I use to make that distinction:

(1) Is it actionable? I only write down things where making progress is under my control. I may have several workstreams going on in parallel, many of which rely on others to provide input or some other prerequisite, but those tasks are not going to be added to my list. If throughout the day I get word about the blocker being resolved I can always add the next thing I have to do as part of that workstream at top of my list. Unless I know I can actually accomplish something though, it would be superfluous and annoying to stare at the item each time I look at my TODOs. "Remind person X do Y so that I can start with Z" of course might be a valuable item on my list because reminding X is something I can accomplish.

(2) Is it achievable? Every item on the list needs to be so small that I can confidently finish it in a few hours time, at most. If an item is larger that that I need to split it into smaller, achievable chunks, which can be done using a variety of techniques borrowed from the User Story approach to agile software development. For example, a big work item could be split into several stages like "research", "implementation", "testing", and "documentation", each of which might not take longer than a few hours and therefore serve as an achievable personal task.

There are two reasons why I put an emphasis on achievability: First I found it really helpful to sprinkle small victories through my day. Each time I can tick a completed item off my list I get a little rush of satisfaction, so I want to make sure I have a fighting chance of actually accomplishing each of the items. The second reason has to do with focus and attention: Switching between tasks that are in progress is not only annoying, it is also hugely inefficient. Once a task is finished though, switching to the next one is easy. It also opens an additional chance of changing the priorities of the remainder of the items on the list: Is what I thought would be important after I finished this still important? Has anything new come up that needs my attention? Obviously, the smaller the tasks are, the more often such chances for planned interruptions arise.

Radical Focus by Christina Wodtke.

(3) Does it align with my high level goals? Weather you're building a house, training to run a marathon, building a software product, or starting a company, it is too easy to get distracted and lost in the myriad of little things that you could work on, but that don't actually move you in the right direction. Asking myself if each of the tasks for today actually aligns with some bigger, overarching goal helps in two ways: First it necessitates the obvious question "What is the overarching goal I'm working towards?" and second, it channels attention only toward activities that help achieve that goal. A more structured approach based on that principle is called "Objectives and Key Results (OKRs)", which is widely adopted among many companies. A great read about OKRs is Christina Wodke's book Radical Focus.

(4) Is it worth doing? As I said in my post about prioritization, there are almost always more things I could work on that I can work on. That realization may sound trivial, but it took me several years to fully comprehend it and acknowledge its implications. At the beginning of my career I tried to solve that conundrum by working longer and longer hours. Instead of the 38.5 I was contracted for, I would work 40, 45, or 50 hours each week, including nights and weekends. That lead to two things: First, I found that while the quantity of the work I was doing was increasing, the quality was waning. If you work in software, just take an honest look at a piece of code you wrote at 8am after a good nights sleep, and compare it to a bug fix you committed in a frenzy at 10pm after having worked for 14 hours straight. Which do you think will cause less trouble down the road?

Secondly, I was under the assumption that by working more, I would actually stand a chance of reducing the total amount of work to be done. I thought that if only I worked long and hard enough, the number of e-mails in my inbox would go down, the number of stories on our backlog would start to dwindle, and the amount of customers I needed to help would subside. But the truth is, there's always more work to be done, regardless of much of it you finish. The Greek myth of Sisyphus, who was punished by the gods by being forced to roll a huge rock up a steep hill only to see the rock rolling back down again as soon as it neared the top isn't really a myth - it's reality. There's always more books to be read (or written!), more features to be implemented, and more customers to be charmed, acquired, and supported. Often, the more of those things we do, the more they lead to additional work in the future. Therefore, my assumption that by working more now I would have to work less later was not only wrong, it lead me into an unhealthy spiral of an ever increasing workload.

Prioritizing in such an environment doesn't only mean moving items up and down on a TODO list, it also means making the hard decision about what is and what isn't worth doing at all. The beauty of limiting the length of my daily list to 3-5 items total, each of them actionable and achievable, is that it helps me avoid the anxiety caused by an endlessly growing pile of unfinished work. By forcing myself to make that trade off every day, to deliberately not work on certain things, I not only avoid the sisyphean trap that leads so many people to burn out, it also helps me to focus: If there's an unaccomplished task I moved from one day to the next for a week, maybe it's time to just drop it?


Once I have a rough idea for my plan for the day, I do a quick sanity check: Am I confident that I can make significant progress on each of the items today? If not, maybe something will have to be moved to tomorrow. Do I have my priorities right? Maybe fixing that bug that a big customer reported is more important than working on content for our new website because the customer is really angry. Or maybe working on the website is more important because we have a big event coming up. The list approach forces me make that decision deliberately, rather than on a whim.

Finally I'd argue that the list approach helps me to keep commitments to myself and to others. I know the sad feeling of finishing a long workday without seemingly having accomplished anything, despite having been "busy" all day. Reflecting on my task list at the end of the day and seeing some (or hopefully all) items ticked off drastically helped me reduce that feeling of anxiety.

Was Taylors advice to Carnegie worth ten thousand dollars? I think it was, because there's so much more to getting one's priorities straight than we would ordinarily think. Just like I find that writing blog posts like this one help me organize and clarify my thoughts, I find that making a daily task list helps me organize and prioritize my work. Not only does that help me to focus on what's important, it also improves my satisfaction with the (always limited) amount of things I can get done. It strengthens my self-confidence by putting an emphasis on what I can achieve, and allows me to set realistic expectations for others. I think, if that was good enough for Andrew Carnegie, it might just be good enough for me.