Revisiting The Phoenix Project

In one of my first posts on this blog, I reviewed a wonderful book called The Phoenix Project. The key lesson I got from the book then was that work in progress is a killer. Work in progress, that is, anything to which you have given time or effort, but which has yet to give you anything back, kills productivity. Another way to think of this is that productivity is hurt by starting some things before we finish others. (Look at it this way: If we always start a new task, and never work on an old task, we will finish nothing. If we always work on our nearest-to-completion task, and empty the queue before starting new things, we will finish everything, but may start new things only slowly. The best way to manage time is in between, but certainly closer to the second.)

The idea that we should finish things is hardly shocking. Joel Spolsky has written about it. It was the topic of a recent episode of .NET Rocks, and John Sonmez recently tweeted:

“Of all the habits you have developed in life, which is most beneficial? Mine is finishing things.”

For this post I am going to take it as given that finishing old tasks before starting new ones is better than starting new ones all the time without finishing anything. What I want to look at instead is why it’s hard. Why is it hard for me to finish things I start? What should I even finish? What should I even start?

MPJ recently did an awesome video about the difficulty of focus. The hard thing people never want to admit is that focusing on something means not focusing on something else. If we want to focus on making the user interface prettier, we are going to spend less time making data retrieval faster. Time allocations are a zero-sum game. To give time you must take time. So what should we give time to, and what should we take time from? That question seems hopelessly broad, so I’m going to try narrowing it to a more manageable focus: What should I start?

In The Phoenix Project, the IT department learns to start meeting deadlines by limiting the release of work. That is, they start to limit the rate at which they take on new projects, and this keeps them from blowing deadlines on projects they’ve already committed too. I seem to already have 43 side projects in flight, so maybe I shouldn’t take on any new ones for a bit. Maybe to start a project, I need to reconcile myself to abandoning an existing project. That would be hard, but the alternative seems to be always having 43 partially completed, messy codebases on my hard drive, which doesn’t really help anyone.

This post has turned into a long-winded and sort of depressing way of reaching this message: Finishing things is important, and it requires not starting new things till the old things are done. Queues are better than stacks for time management.

(Speaking of time management, @SteveAlbers and @jsonmez recommended Kanbanflow. It’s awesome. Check it out.)

Starting things is easier than finishing them, but finishing them is more important. I guess that’s a hard lesson.

Till next time, happy learning


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s