Adam @ Bitscribe

Through most of my career as an entrepreneur, my mornings have always been devoted to checking email. This has always seemed like a good way to dive into the day. But recently, I’ve come to the conclusion that this behavior is actually quite poor for productivity. Not because there’s anything wrong with checking email - it certainly needs to be done at some point (or many points) each day. No, the reason why I prefer to do things differently now is that I think a morning email-check starts you off at the wrong level of detail.

Email tends to be very zoomed in. Little notes, FYIs, and requests related to stuff you’ve already done, or may do in the future. But one of the biggest impediments to productivity is getting too caught up in the details, and thus missing out on the big picture.

There are always an infinite number of details, and you can run yourself ragged trying to keep up with them all. It’s easy to do so, because all of these details tend to be so demanding. They sit on a todo list looking terribly not-done, or worse yet, they come in attached to subtly demanding emails from your coworkers, clients, or partners.

The start of the day is a perfect time to look at the big picture. You’re rested, and your head is clear, since it’s been 12 hours or so since you last thought about work. The whole day is ahead of you, full of promise and potential. Now’s the time to ask: what is the absolute most valuable way I could spend the next eight hours?

I’ve been amazed at the insights this produces. I’m more productive - not from doing more work, but from working on things that matter more. Humans tend to get caught up in the details so easily. Once caught up, we rarely stop to question the comparative value of this here vs. anything else you could be doing with your time and energy. But the opportunity cost of that energy may be huge. Morning is a great time to stop and think about this; it’s the one time of day that you’re not already wrapped up in something.

Not surprisingly, I’m not the first to have this insight. Getting Things Done recommends setting aside two hours each week to look at the “50,000 foot view”, or the really big picture. This is one of those “But I don’t have time for that!” → “You don’t have time not to” things. My complaint with the specific method suggested by GTD - doing this review late on a Friday - is that you don’t want to think about the big picture much then. The events of the week are still fresh in your brain, demanding your attention. I find it much more effective to think about this at a time when I’m more distant from the details.

The concept of a repository is a simple one on the surface, but it has surprisingly deep and subtle ramifications. Putting data in a repository encourages or even enforces unification, normalization, and consistency.

Source repositories were the first type of repository I encountered. I started using them for their archival capabilities, but as soon as I did I got a surprising side-effect: normalization of my project directory and file layouts. Almost overnight, my source trees turned from sprawling, unpredictable jungles of files into well-organized and consistently-named file hierarchies.

But it’s not just source. How about media? Many people have a movie “collection,” which is usually a pile of DVDs, VHS tapes, and maybe even laserdiscs which are not organized in any particular fashion. Some have covers, some don’t. Some are copies, some are store-bought copies. It’s a mess, but most people don’t think of it that way. It’s just the default, because that’s the way collections tend to be.

Repositories, on the other hand, tend toward the opposite. It’s actively difficult and in some cases impossible to have a repository that disorganized. iTunes is a great example of a media repository. Not to say that it can’t be a mess, it certainly can. But you have to sort of work at it. By default things are pretty well-organized.

This piece makes a strong argument for keeping hours worked per week low in order to enhance productivity. Low, as in less than 40.

“The sociologist Arlie Hochschild in one of her books mentions an IT copany that were in big financial trouble. Rather than lay some people off they switched to a 30-hour work week and a corresponding pay cut, and experienced no reduction in production. They did the exact same amount of work in 30 hours a week as in 40.”

My own anecdotal evidence confirms this: often I find that I get more work done when my time is limited. I know I’ve got to leave at 7pm on a particular day, so I get straight to it, no messing around. Without such a time constraint I may spend the morning tinkering with a new technoloy tool or writing a post for my blog. (er…)

In reality I think that 6 hours per day is the maximum real productivity that can be achieved, at least on a sustainable basis. Nicely enough, this period fits neatly into an 8 hour day (counting some time for lunch, breaks, socializing at the water cooler, etc). Most people probably get only about 2 solid hours of productivity spread out across the per day, even when they spend 8, 9, 10, or more hours at the office. What the heck is the point of that?

The attitude that more hours = more productivity is almost dogmatic in the IT industry. A related attitude, but possibly even worse, is that employees prove their loyalty to the company by spending more than 40 hours a week parked behind their desk. In the past I’ve been accused of not being a “team player” for refusing to come in to work on the weekends on a regular basis. (This even after I specified at the time of my hire that I wouldn’t do the weekend thing.)

I do developer interviews from time to time, and when I do one thing I always mention is “we don’t believe in working more than 40 hours a week here.” Confusion inevitably spreads over the applicant’s face, as they think: What is this strange concept? Is it a trick of some sort? This is a software company, surely I will be expected to participate in coding death marches as any given release date approaches…

Nope, it’s for real. We actually want to be productive and make high-quality software. It’s hard to do the first and nearly impossible to do the last by constantly straining your development team to the limit with excessive overtime.

I think the more subtle reason that this approach works better is that most people work better at a steady pace, rather than spending half the time fooling around and the other half in a desparate burst to deliver the product on time. Slow and steady wins the race and so forth.
The nature of the traditional long-cycle approach to software development is to creates a sort of peak-and-trough pattern. At the start of the project you think “I’ve got plenty of time, I can spend three weeks tinkering with this particularly interesting bit of code that isn’t that important to the project overall.” More likely you don’t think any such thing conciously, but it is what it happening. Then this is much enhanced your residual burnout from the last product’s release death march, so you want to take it easy for a while.

Then as the release date gets close enough to be a reality - say, three to six months away - you start to really buckle down and think about what it’s going to take to get it finished. You realize just how much is left to do and the entire team goes into code-like-hell overdrive. The quality of the code produced and the social lives of the team all go straight into the wastebasket. All you can think about is hitting that finish line.

Using evolutionary design with short iteration cycles breaks out of this pattern. Release cycles that are 2 - 6 weeks long don’t give enough time to relax at the beginning - the deadline is always right around the corner. At the same time your goals for the iteration are simple and within reach, with realistic time estimates as well. (I think it’s pretty much impossible to do accurate time estimates for projects that will take more than a few months.) So this approach tends to cause people to work at a steady rate, consistently producing week after week. There are never any coding marathons and subquent burnout - which in turn reduces the quantity of maintenance work on the next iteration, since the code produced is of a higher quality.

Spend less time at the office, but then that time more productive. It works - really.