A long time ago (2007 I think) I was in a conversation with one of the technical leaders in a startup that I was working at. The subject of our discussion was process and I was flogging my pet religion: efficiency via automation, infrastructure and tools, all focused on the developers/engineers and ease of use from their perspective.

I argued, no doubt unoriginally, that most process is designed by managers and consciously or subconsciously built to meet the needs of the manager, answer his questions, give him a view of how things stand, etc., and that this was a fatal mistake. The main job of the manager is to collect, analyse and act on this information, and yet, he was designing a process, and mandating the use of tools, that made his task easier by passing the work to the engineers whose real function was radically different.

Not only did this waste the time of developers, but it turned a potential positive — the use of well-integrated tools that could help the engineer — to a negative: the daily wrestling with tools and process,  filling out bureaucratic bits of information, that in no way aided the developer, but generated second-order data for the manager that could have easily been derived from a more productive development infrastructure. There are echoes of this malaise in most IT environments as well, but that’s a topic worthy of its own post.

The person I was speaking with thought otherwise, taking such an environment as unnecessary pampering of techies. He seemed more at ease with the traditional model that put the manager’s tracking, risk assessment, and other activities at the center (and key to the success) of the organisation’s effort. I didn’t win that friendly debate, and these days I try not to get embroiled in religious wars.

However, a recent link on Daring Fireball to a piece by Paul Graham of Y Combinator, had me nodding in agreement, especially with regard to the bluntest[!] tool in the manager’s arsenal: the “meeting”. Here are some good bits (keep in mind that Graham is a programmer  turned VC partner). Graham starts out by differentiating between the “maker’s schedule” and the “manager’s schedule”:

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

And goes on:

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another 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.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

[…]

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.

He ends on a hopeful note:

Since most powerful people operate on the manager’s schedule, they’re in a position to make everyone resonate at their frequency if they want to. But the smarter ones restrain themselves, if they know that some of the people working for them need long chunks of time to work in.

I am not that hopeful.