Found this very interesting article by Paul Graham (via facebook and freakonomics blog) about people who build things usually hate meetings, and find it as a big waste of time. At the same time, when you are in the management frame of mine, meetings are the most important thing you do all day. I find this explanation really hits the nail on the head, since I have been on both sides of the fence. This is what Graham says:
One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.
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.
When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.
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. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.
Completely true. When you are a developer, engineer, or architect (either software or real-world), by the time, you get around to understanding the problem at hand, and get the full perspective, its already a few hours, and if you have to head out to meetings at that time, the whole train of thought is lost, and you’ve go to restart again from pretty much the beginning.
Last few months, I have had to be on both schedules, and its a very difficult thing to handle. On the one hand, I develop software that goes into our solution, and on the other hand, I have to follow up with all the other developers, interface with Sales and Operations, and all the other aspects of business. And in most cases, you can’t draw up a schedule and take out chunks of a few hours and concentrate on the development. As a result, in most cases, at one time, I can wear only one hat – either be a developer and ignore everything else, forget about making phone calls, following up with people etc., and concentrate on writing code. At other times, there are complete days where I can’t afford to even open my IDE because I am wearing the managers hat and do all the other things I have been ignoring all the while. It also leads to a complete state of confusion at times when you change hats too frequently – and at those times, you know you’re losing it and its best to forget everything and take a break.
It’s a difficult balancing act – identify what requires your most immediate attention, and change hats frequently, so that collectively the whole organization is most productive, even if you feel that you are not at your most productive level yourself.
However, even though we may hate it, the way most of us (and with us I mean people who are never satisfied, and keep pushing ahead for more) we love it most when we have too much to do, rather than too little. Changing hats rapidly, probably take a hit on personal productivity, re-engineering yourself with the dynamics of the environment around you, basically going crazy, are a part of the job description, something you learn to hate – but do nevertheless – and grow along the way.