The personal website of Matt Henderson.
23 November 2011
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.
Enjoy this article? — You can find similar content via the category and tag links below.
Questions or comments? — Feel free to email me using the contact form below, or reach out on Twitter.