How to schedule focus

For nearly a decade, we at Makalu have worked to consistently deliver real, objective value to our customers, and by external measures we’ve been successful. We built a website for Catalog Choice that registered a million users in its first year. We built a game for Google and Virgin America that Ogilvy & Mather pointed to as a reference for modern-day marketing. And we’ve increased signed up conversion, customer retention, and ultimately the bottom line for many more.

We seem to have done well, which is great, except for one thing — we’ve never been able to shake a nagging feeling of dissatisfaction. Although we’re doing good work by external standards, we know deep down that we’re not doing our best work, by our own standards.

Is it something we should just accept, or should we do something about it? In case others in our industry might share in this internal tension, I decided to put our thoughts into an article to share.

Doing great work

Doing really great work requires focus — getting in the zone, and staying there, uninterrupted, until you come to whatever milestone makes sense in the context (a wireframe, a mockup, a prototype iteration, or a blog article.) And, unfortunately, you can’t know in advance exactly how long it will take to get there. You might know it usually takes a day, but sometimes it takes three.

So to create great work, we need uninterrupted focus, for as long as it takes.

Running a services business

Customer engagements (even if you’re your own customer) introduces constraints that work contrary to producing ones best work.

The owner of a services company can, through policy, control some of these constraints. When talking with potential customers, you can communicate that your company’s mission is to do great work, and therefore you avoid certain things. In our case, that would include fixed-price projects, and projects involving severely limiting budgets or time contraints. We’ve done a good job sticking with this policy.

But what we haven’t been able to avoid, is the necessity of working on multiple projects in parallel.

Project concurrency to address idle time

All service projects involve idle time, such as when a customer reviews an iteration, or when a delay is introduced. We could try to forcibly manage flow by contract, but nobody likes that. Both customers and providers appreciate a process that allows projects to follow their natural dynamic, and reasonably accommodate the unforseen. So we accept that (sometimes unpredictable) idle time is part of our way of doing business.

So how can we address the cost impact (and profit loss) of idle time? Our approach has been to operate multiple projects in parallel, for a given team, in an effort to keep our resources busy. It doesn’t eliminate idle time, and it introduces its own challenges, but it’s the best approach we’ve found.

Of course, if we take on too many projects, we’ll end up the source of project delays, and we don’t want that. We’ve found, through experience, that things go well if we take on no more than two projects at a time, per team.

Effort scheduling

So we’re working on two projects, each of which has some current milestone that we’re working towards. How do we schedule our time?

We’ve tended to schedule our time weekly, by day — Monday (Project 1), Tuesday (Project 2), Wednesday (Project 1), Thursday (Project 1 & Project 2), Friday (Project 2) — taking into account, as best possible, the various needs of each project.

(Since we don’t know how long it takes to get to a milestone, and if we insist on providing at least a minimum level of quality, then a consequence of this planning is that we can’t tell Client 1, “We’ll finish XYZ by Monday night.” Instead, we can only say, “We’ll be working all day Monday, Wednesday and half of Thursday, and we think we might get to XYZ.”)

This loading (two projects at once) and planning strategy has worked well during the past few years — we haven’t gotten terribly behind on any project, we’re maintaining a consistently high ratio of chargeable/non-chargeable time, our customers have all been happy, and we’ve remained profitable.

But, there’s that darn elephant in the room.

At the end of the day, we just don’t feel satisfied. We try to soldier on, but it keeps popping up. We keep asking ourselves, “We only have one life to live. Are we really OK with not doing our best?”

A new approach — scheduling in blocks of a week

Analyzing things, we suspect that the focus (essential to great work) lost with daily (and sometimes mid-daily) context switches is just too consequential. Knowing that we’re switching context so frequently seems to create too strong a feeling of urgency, encourages taking shortcuts, and going with known patterns instead of pushing the envelope. It seems to lead to good enough.

To address this, we’re going to try experimenting with planning things in blocks of a week — i.e. Week 1 (Project 1), Week 2 (Project 2), and so on. We’re hoping that focus blocks in units of weeks will give us enough time to reflect and explore, allowing us to get deep enough to make the work great.

That’s the target, at least. I’m sure it’s going to prove easier said than done. Implementing this will imply both economic and scheduling concessions on the part of our customers. But, if it gets us closer to doing our very best work, maybe it’ll prove worth it — for both us, and our customers.

We’ll see, and I’ll report back.

My system for Getting Things Done

Update: This article was written in 2011. An updated description of my system for Getting Things Done can be found here.

Back in 2004, I wrote a popular article describing my system for “Getting Things Done”. Since then, tools have changed and my needs have changed, and so it was about time for an update.

Today’s system is simpler; it’s based on two tools — OmniFocus, and TaskPaper. Here’s how it works.


Having OmniFocus on the Mac, the iPad and the iPhone, I can capture ideas and actions pretty much any time, anywhere.

On the Mac, a hot-key (command-space) triggers OmniFocus’s quick-input window. Many of the tasks I create on the Mac are associated to incoming emails. By dragging those emails into the quick-input window, a link to the original message is created in the task, allowing me to archive the message in (and helping to maintain inbox-zero zen.)

On the iOS devices (iPhone and iPad), OmniFocus thoughtfully allows you to create a new task, without even having to wait for its cloud-syncing to complete. Fast and efficient.

Most important, the highly-reliable cloud-syncing ensures that my captured tasks are immediately available in OmniFocus on all devices, regardless where they were captured.

Weekly Review.

For both review and planning (discussed next), I use OmniFocus on the iPad. OmniFocus on the iPad has a better UI than its Mac counterpart; but even more importantly, the iPad itself tends to promote focus, which I find essential for reviewing and planning.

For each project in OmniFocus, you can set a frequency for how often you want to review it. For my active projects, this is weekly. But for some projects (especially product ideas or suspended projects), this might be once every three months — long enough so that I’m not mentally interrupted too often, but at the same time, making sure they’re not forgotten.

Once a week, usually on Sundays, I’ll grab the iPad and head down to the local tea shop, order a “Té Moruño” (green tea with fresh mint), and spend about an hour doing my weekly review and planning.

I’ll start in OmniFocus’s Review Mode. In this mode, OmniFocus walks you though each project — one at a time — which is due for review, showing you all the tasks you’ve created. In this mode, I:

  • Think about the state of the project. Is it still active? Has it received enough attention? Should its priority in the overall scope of things change? If necessary, I might change the status of the project from “Active” to “On Hold”, so that its tasks (for the time being) don’t appear anywhere else in OmniFocus. (Or, vice-versa; I might “activate” a project that’s currently on hold.)

  • Manage the tasks. I add new ones that come to mind, and I delete those which may no longer be relevant. Since OmniFocus’s perspectives allow me to filter my tasks (something we’ll look at next), I can define all the tasks I imagine relevant to the project, without worry about task-overload while later working.

  • Manage the start and due dates. Each task can have “start” and “due” dates independently assigned. The meaning of due dates is obvious; start dates somewhat less. For every task that I’ve committed to do, I assign a start date corresponding (roughly) to when I plan to start working on it. This means that all the tasks I’m currently working on have start dates in the past. (In fact, more specifically, I make sure the start date is set to “now”, or in the past, for all tasks I plan to work on in the upcoming week.)

When I’m done reviewing a project, I tap “Mark Reviewed”. OmniFocus closes the project, and then shows me the next project needing review. I continue until there’s no projects left to review.

Weekly Planning.
When I finish the weekly projects review, I move on to planning of the following week — i.e. figuring out when I’m going to work on my active tasks.OmniFocus supports something called perspectives — which are highly configurable filtered views of your tasks. In addition to the default perspectives delivered with OmniFocus, I have two others:
  • Urgent — This contains all tasks that are due, overdue, or coming due soon (within two days), grouped by Context.

  • Active — This contains all tasks that are active — i.e. have a start date defined as now, or in the past. The tasks in this perspective are grouped by Project.


p>To start the planning process, I switch into the Active perspective. This perspective should show me all tasks on which I intend to be working on in the following week.

If I see any task that I don’t want to work on this week, I’ll tap the “+week” or “+month” buttons in OmniFocus, to bump up their start dates into the future (or just reset them completely.) With a change of start date, they disappear from this perspective. Out of sight, out of mind.

At this point, I’ll try to mentally group the week’s tasks into related, largish, chunks of time — like two hours, or four hours, or eight hours.

While “chunking” my tasks, I’ll switch back and forth from OmniFocus into TaskPaper — a text-based outliner on the iPad — into a document called “Weekly Planning”, and start adding chunk tasks to a TaskPaper project called “Weekly Objectives”.

(Don’t confuse TaskPaper “projects” and “tasks”, with projects and tasks used elsewhere in this article; those are just the terminologies used in TaskPaper for its outline elements — parents and children.)

When I’m done, my “Weekly Objectives” project (list) in TaskPaper might look like this:

  • RaceSplitter (8h)
  • Makalu Miscellaneous Tasks (4h)
  • Makalu Management (4h)
  • Makalu Finance (4h)
  • Personal Finance (2h)
  • Catalog Choice (8h)

I won’t schedule a full 40 hours, because I know I’ll need some margin for daily emailing, and the various little things that inevitably pop up over the course of a week.

This TaskPaper document also contains day-of-the-week “projects” — i.e. Monday, Tuesday, Wednesday,…

When I’ve finished chunking about a week’s worth of work into the “Objectives” list, I’ll then conduct a finer-grained planning by distributing those chunks over the days of the week:

  • Monday — Miscellaneous (4h), Management (4h)
  • Tuesday — RaceSplitter (8h)
  • Wednesday — Catalog Choice (8h)

What this achieves is the organization of the week’s planning into blocks of time in which my focus is relatively contained within a common context. And that leads to better productivity.

(As a side note, my TaskPaper documents are kept in Dropbox, so they’re also available everywhere!)

Daily Planning

Each evening, I’ll look at the following day’s chuncked plan in TaskPaper. If it’s Monday in the example above, I see that I’ll be working half the day in “Makalu Miscellaneous” and half in “Makalu Management”.

I’ll then switch to OmniFocus, into the Active perspective (which shows me the active tasks), and I’ll focus only on the tasks in these two projects. From those, I’ll tap to “flag” each task that I intend to complete (or just work on) during the following day.

The list of “flagged” tasks then becomes my next day’s work-list.

Finally, after doing my daily planning, which just takes a few minutes, I’ll quickly switch into the Urgent perspective, just to make sure nothing due, or coming due soon, is slipping through the cracks.

Daily Work

During the day, as I work, I keep the iPad on and displaying the “Flagged” perspective in OmniFocus — i.e. displaying my task list for the day.

These tasks should be roughly within the same project or context as the day’s chuncked plan in TaskPaper. As I work through the day, I check them off — hopefully until the “Flagged” perspective is empty.


This system works really well for me, achieving the following:

  • Based on just two tools, it’s far simpler than my GTD systems of the past. Being simpler, I’m able to better stick with it.
  • Having OmniFocus on all devices, I’m almost never in a situation in which I can’t capture a thought, action or task.
  • When looking at my tasks in OmniFocus’s “perspectives”, I see only what’s relevant, when it’s relevant. This helps to prevent feeling overwhelmed.
  • Using TaskPaper, my week is organized into “blocks”, allowing context-consistent focus, and improved productivity.

The biology of productivity?

I’ve been reading the book, “Why we get fat” by Gary Taubes. If you’re interested in understanding the relationship between eating and getting fat, then you must read the book. It could change your life.

The revelation of the book is that some common dietary beliefs are, as demonstrated by science & biology, complete inverted. And that got me thinking about possible parallels in other areas, such as productivity.

Continue reading The biology of productivity?