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 that will take. 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 when you’re your own customer—introduces constraints that work contrary to producing one’s 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.
All service projects involve idle time, like 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 a part of doing business.
So how can we address the cost impact of idle time? Like most service companies, our approach has been to operate multiple projects in parallel, for a given team, in an effort to minimize downtime. 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 being the source of 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.
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 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 feeling like we’re 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 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, anyway. 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 everybody.