Via @keithlam & @scottconnor, found this great essay by Paul Graham, Maker’s Schedule, Manager’s Schedule. The essay describes my challenges with being a manager vs. a maker almost to a T. I was particularly struck by these paragraphs:
For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.
I find 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. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.
This is further complicated by the challenges of trying to be great at your job. I’ve found I can only be either a good manager or a good coder. Every single time I’ve tried to do both (outside of a very small team of similar aptitude/motivation), I perform below my own standards at one of them. Either I cut corners in my code or I ignore my team too long. In the worst case, I do a bit of both. So, at my day job, I make the choice of being a manager.
This is also basically why I work into the night when I am coding. Working after emails die down and Heidi goes to bed offers that unbroken expanse of time to be creative and just get stuff done. This is again in conflict with the manager’s schedule so jobs that require a morning start time (early being, say, 9AM) make it hard to stay up late.
There’s something to be said for the discipline of getting up early and getting to bed early, but building neat things isn’t necessarily a question of that kind of discipline. In fact, Graham gets to this point right at the end:
When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I’d sleep till about 11 am, and come in and work until dinner on what I called “business stuff.” I never thought of it in these terms, but in effect I had two workdays each day, one on the manager’s schedule and one on the maker’s.
While at Fanzter, I did the dinner to 3AM stint pretty much every day. It was my most productive time. It also led to tension as we had morning people in the company and the schedules never quite lined up. I made it work, by coming in earlier (10/10:30 or so until dinner-ish). His pattern of dividing the day is also pretty much how I ended up doing it, and if I had thought about it more, I would’ve even formalized it. As it was, I always felt as if I was doing something wrong. That’s why it was so satisfying to read this. It’s like someone sat down and decided to explain how I work.
I’m going to make Heidi read this, and I’m going to paste this to my wall if I ever do a startup again.
PS. Graham’s Hackers and Painters is still one of my favorite books. It’s a collection of his essays and many are about the same subject as the one above: what makes coders and artists similar and what makes them tick. Some of it is over-the-top almost hubris/presumption, but in general he has some excellent observations. Great read if you liked what you read above. Many of the essays are available on his web site. Hackers and Painters (the essay) is one of my favorites.
