All these posts about using time more productively reminded me of a book I read about 6 years ago called Time Tactics of Very Successful People.

The fact that I ever even read the book is completely random—my wife and I were staying in Chicago with one of her aunts, and I picked it off the shelf one evening for some bedtime reading.  Despite my expectations, it didn’t put me to sleep…in fact, I really learned some good stuff!

One productive time tactic that stuck with me was ensuring that I start the day prepared.  I don’t remember all the details of what the book proposed, but here’s how I took what the author wrote and adapted it:

Everyday, before I stop working for the day, while my mind is still fresh with the things I’m working on, I write a note stating where I left off and listing the 3-5 things I need to work on tomorrow.

As a result, when I start working the next morning, I haven’t forgotten what I was doing, and don’t spend the first 30 minutes of the day getting my barrings straight.  Instead, I can jump right into the day and start getting stuff done.

Yesterday’s post on being more productive in the morning reminded me of Paul Graham’s essay regarding manager versus maker time.

Paul’s simple point is that “doing work” requires a different type of mindset and workflow than “managing other people doing work”.  Most programmers completely agree, so I encourage you to read his essay.

One of the points that complete resonates with me is:

…there’s [a] way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

I couldn’t possibly agree with this more.  I feel like in order to be maximally productive, I have to have at least a 3-hour chunk of completely uninterrupted time.   And, sometimes that doesn’t even work…as Graham writes:

…one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning.

Yes!  Absolutely!

Rereading Graham’s essay is going to cause me to be more careful about scheduling meetings at Cheezburger.

Right now, we only have two types of meetings: an all-team meeting at Monday morning, and several daily standups for smaller project teams.  Typically, those meetings are all held in the morning, and I’m going to work to keep them that way…perhaps designating the afternoon as “maker time”.  Although, that is incongruent with the whole “morning people are more productive” idea, so maybe the key is to move the meetings earlier in the morning.

I’m not sure…what are your thoughts on this?

Contrary to popular belief, I’m a nervous fellow. I like to be on time, I like to get there early, and when I make up my mind to do something, I definitely like to focus on getting it done now.

I’m sure this annoys my team at Cheezburger for a number of reasons which I shall enumerate via metaphor.

One must walk before they run. And, Rome wasn’t built in a day.

It goes without saying that I agree with these sentiments. As I said, I get nervous; time allows opportunity for something to come along and derail the project. A derailed project is wasreful, and if there is anything I dislike more than yellow mustard, it is waste.

There’s an approach to web and software development intended to act as a salve against my worries. I think it could applied to most types of projects, though.

First, just make it work. Even if it’s ugly or klunky or kludgey. I often refer to this as “The Happy Path”; get the basic use cases that satisfy 80% of the users working.

At this point, there will still be a lot of rough edges, but at least you’ll have something functional to show off. Going forward, work on smoothing out the edges.

Next, make it fast. In other words, take out all those rough edges that cause your product to be slow and perform poorly.

Finally, make it pretty. This is the phase where you smooth out all of the user interface and experience issues. This includes the rough edges related to edge cases and look and feel. (One reason to consider why this step is last: what’s the point in smoothing out the UI if the product doesn’t function?)

Often, we follow this process at Cheezburger, and it tends to work in terms of productivity.

And, I worry less, too.

There’s an expression I’ve heard that says there are two types of work: working in your business and working on your business.  What’s the difference?

Working in your business is doing the work of making the business go.  For example, if you have a widget factory, you’re working in your business when you’re making widgets.

Working on your business is doing the work of improving the business.  For example, if you have a widget factory, you’re working on your business when you streamline your processes to produce more widgets at a lower cost.

There’s a Japanese work kaizen which literally means “improvement” but has come to reflect a philosophy of continuous and regular working on the business.

Last week, the CheezTech team made an effort at kaizen—we took an hour out of our busy schedules to talk about how we could improve our development processes and productivity.  The results, both practical and emotional, were remarkable.

At the end of our hour we walked away with three concrete changes to our processes.  And, we committed to meet again in a month to see how we’ve done, and look for other improvements.  The entire team felt great!

Today, several members of our team attended a conference and participated in an experiential session that used game-like activities to teach about teamwork and productivity.  In one of the activities, the group was divided in two teams and each team was asked to move as many baseballs as possible from here-to-there following certain rules.

We did it once, and our efficiency was measured.  Then, we were given exactly two minutes to discuss as a team how we could improve our process before we had to do it again.  Just two minutes of working on our business resulted in an almost 100% improvement in efficiency!

Not only did we learn the importance of taking a time-out to discuss improvements as a team, perhaps the most important lesson had to do with the difficulty of implementing changes “to the process” while “in process”.

During the first attempt, two of the 14 members of the team discovered an opportunity to streamline, but were unable to effectively communicate it to the rest of the team.  Since the whole team was busy working in the business, it unable to divert attention and communicate in order to make improvements on-the-fly.

The lesson here is clear: there is genuine value in taking small amounts of time to step outside of working in the business and gather as a team and discuss how improvements can be made to the business.  Taking this time to step aside is critical because it’s difficult to apply changes in-process.

I’m excited for this new aspect of our teamwork at Cheezburger.  By itself, introducing our monthly meeting is an excellent improvement.  I’ll report back you next month to tell you how it goes.

P.S. For those of you familiar with Agile and Scrum development methodologies, this type of kaizen practice is built into the methodology by way of the “sprint retrospective meeting”.

Customer service e-mail.  I genuinely love answering customer service e-mail.  Seriously, I’m not making this up.  I find real, genuine joy in helping our the fans and users of our web sites.  It makes my heart feel warm and smiley.

But, I’ll tell you, it backs up quickly.  Not to mention, there are a million other things we have to do at Cheezburger.  That’s the thing about building a web site: it’s never over—there are always improvements that can be made.

Honestly, sometimes it’s a little overwhelming and the never-ending-ness of it stresses me out.  Not in a horrible, ulcer-causing way, but in enough of a way to be a constant thread in the background.  Oh brother, how are we ever going to scale this mountain, I think.

What I’m trying to do is not think about it.  Thinking gets me nowhere, but doing results in progress.  To help with that, I keep a list of all the things to do which is important because that reduces the background noise in my head.

Lately, I’ve been focusing on just plugging away at things one item at a time.  They say that when you’re doing actual mountain climbing that you just need to keep on putting on foot in front of the other.  Don’t look up at the hill…just take the next step.  That’s what I’m trying to do.

If you’re a regular reader of this space, you know that I talk a lot about the metaphor of the journey of a thousand miles and a million steps.  I suppose this post is just another variation on that theme.  The lesson in this variation is that the key to avoid becoming overwhelmed by the size of the mountain is to simply focus on the step you’re currently taking, and don’t think about the next one until you’re done with the current and ready.

Unlike others out there in the Interwebs, I still use Google Reader.  Like all Google Reader users, I have a Shared Items page.

I wanted to set it up so that anything I shared was fed directly into my Twitter and FriendFeed streams.  It turns out this was pretty easy on FriendFeed–I could just connect up Google Reader and I was done.

For Google Reader, I used Twitterfeed as an intermediary.  After I created an account with Twitterfeed, I set it up to read my Google Reader Shared Items Atom Feed once per hour.  (Atom is like RSS; find the URL for your Atom feed on the public view of your Google Reader Shared Items page.)

Each new item Twitterfeed finds in my Google Reader Shared Items feed is posted to my Twitter stream.  It turns out that it works pretty nicely.  The only problem I’ve found so far is that the items show up twice in FriendFeed because I have FF configured to pull in all my tweets and Google Reader Shared Items.  (Perhaps I’ll disconnect one of them…not sure which one though.)