After twenty years of trying different ways to get organized, I’ve developed something that actually works for me, partly derived from the Kanban and Scrum approaches, which are part of a broader Agile movement in software development. The picture on the right shows what my most recent “workboard” looked like mid-week, to give you an idea of where I’m going with this.
Ultimately everyone’s ideal productivity system is combined and customized from others, then grows and changes with the person and their work. And it seems important that people actually like using their system apart from its content. It doesn’t have to be pleasant, but you have to feel some impulse to consistently go through it, even on your worst days. So this system happens to emphasize things I like: openness, fluidity, a sense of wholeness, cumulative progress, spatial-visual relations and interactions between parts.
Here’s a bit of introduction by way of sharing my experiences with popular or established methods:
Doing Nothing — I love freedom, but an ad hoc approach just isn’t feasible when trying to combine “creative work” with “adult responsibilities” (managing either in an ad hoc fashion is hard enough).
Routine — Some creative people manage to stay organized and productive simply by repeating the same routine. A lot of prolific writers say they wake up and write 500 words every morning before they do anything else, and with that pace a person can write a book or more every year. That’s well and good if you can decide which book to write this year (and that writing a book is what you want to spend the whole year doing). I’d need a system to even get me to that point by helping prioritize and switch between projects in an at-least-somewhat disciplined and productive way.
Rigid Self-Discipline — Self-discipline is always important but there’s also a higher-order ability to know when to be rigid and when to be loose. I’m often at my best when I’m loose, responding to news and ideas that come unexpectedly. Productivity systems and organizations tend to promote the lower-level kind of discipline: “do A for x amount of time in order to get result B.” But A, x, and B often depend on variables that aren’t known or stable. That’s why I’ve been digging into management disciplines like Agile software development that try to capture and manage rather than reduce complex work dynamics.
Calendars — Calendars are event-driven, and my creative work (and my life in general) is deliberately not like that. Some people are appalled by this but we’re just different that way. If my calendar was full I wouldn’t be accomplishing things I want to accomplish. I try to maximize and protect free time to play around and explore and capitalize on opportunities that come up (ideas, current events, etc). There’s also the challenge of dealing with “creative moods” (writer’s block, etc). Some days I feel incredibly focused and inspired; it would be stupid to spend that time reorganizing my bookshelves just because I arbitrarily allocated the time for it. And on bad days, unless there’s an urgent deadline, I’m better off using that time for mindless productive chores (and usually my focus or inspiration returns a few hours later). I don’t need something to dictate exactly when to do what, I need something to help me assess the best use of my time in response to immediate changes.
Lists — Lists are great for a lot of discrete tasks but not nearly as effective for more creative or open-ended types of work. Writing a new list every day just becomes a point of frustration, stress, and distraction for me. I have lists all over my desk and my notebooks — lists of priorities that almost immediately became obsolete, i.e. “this turned out to be a stupid idea… but here’s something better I didn’t know about yesterday, that should go to number one or two on my list… and this turns out to be five different smaller tasks… and these two are connected to that other project…,” and so on. To-do lists are great for the occasional days when I need to get a lot of “housekeeping” tasks done, but I generally minimize situations that require me to do those types of things. Since I really live for the big, ambiguous, risky, exploratory-types of projects, I need a system to help me prioritize and manage them that doesn’t try to reduce them to something linear, sequential, or cut-and-dried.
Kanban — Someone suggested I should try a kanban-based project management tool a few years ago [that’s one example but there are a lot to choose from]. The first barrier was that it felt backwards to me. Kanban comes from a manufacturing background where everyone’s mental model is based on things moving from left to right through a structured process or supply chain, coming in the back door as materials and going out the front door as finished products. Software development works roughly the same way: requirements come in the back, products and features go out the front. But most of the things I really need to organize are either opportunities I’m chasing or challenges and disruptions that come up in front of me — many of which happen at a specific date and time, and I want to see what’s happening between now and then. In my mental model, it’s me that’s moving from left to right, not my work. My “to-do” items come in the front and my “done” items go out back (I can imagine that changing at some point, but for now this is how I’m motivated).
So my solution was to combine the best of all those approaches into something that seems kind of natural and obvious now (I’m sure someone must already be doing this).
The basis of the system is similar to Kanban or Scrum in that it’s based on moving cards or sticky notes around on a big board. But I approach it more like a calendar and changed a few other things to suit my work and my style:
The board’s structure is based on days of the week instead of Committed -> In Progress -> Complete. Breaking work down by weeks and days is almost exactly how I intuitively think about my work, with some rough accounting of goals and progress at the start and end of every day and every week (also as advocated by Steven Covey and other productivity gurus). It also helps distribute work over time, identify risks and dependencies, and group complementary types of work together. Some days I need to hunker down and other days I need to run around town, and those different modes often don’t mix well. As for the distinction between “committed” and “in progress,” it doesn’t really apply to my creative work. The things I really need to organize are either things that are always simmering in the background (like ideas) or things that don’t tend to stay in progress for very long (like errands).
The worker moves from left to right, not the work. Now I can visualize “to-do” items ahead of me and “done” items behind me, which is how I intuitively see it.
Completed tasks move down to the bottom of the board instead of across to the right. I like to retrace my progress from day to day across the bottom row. I find the natural “note density” visualization that emerges is more compelling, more useful, and less effort than the burn-down/burn-up lines that a lot of Agile teams use (but if you like numbers and charts, then have at it). It also helps me retrospectively think about why I got more done on some days than others.
Incomplete tasks get pushed forward (or “front-logged,” if you like) to a subsequent day, which acts as a daily disincentive for letting things slide. It sucks to literally see work pile up on Friday. The simple fact that I’m forced to do something with every task at the end of the day (rather than technically be able to leave them “in progress”) means that I’m more motivated to get them done instead of passing them on to my future self.
There’s a clear distinction between things I want to do and things I need to do. Things I need to do go in the top lane or row. Things I want to do go in a middle row. This lets me happily load up on fun, aspirational, or exploratory things I’m not technically committed to. The more there are (within reason), the more incentivized I am to work faster to make time for them. (I tried this with Kanban/Scrum but it clashed with the one-direction flow of work and the “Committed” vs “In Progress” distinction.)
Below is a generic example of a basic workboard at the start and end of a week. Notice how tasks got pushed or pulled between days (and one ended up back in the backlog) and new tasks were inserted. (With a bit of scrutiny this example looks like poor planning, but it’s just meant to show the basic mechanics without making it look too perfect.)
Note that this itself is a work in progress. It’ll almost certainly evolve (with me and my work) but it’s solid enough to share. Next steps include incorporating project milestones/schedules beyond one week and managing all the ambitious multi-year projects I tend to accumulate.
If you want to stay in the loop as I keep refining this, just send an email to email@example.com.