Slashdot Mirror
Manager's Schedule vs. Maker's Schedule
theodp writes "Ever wonder why you and the boss don't see eye-to-eye on the importance of meetings? Paul Graham explains that there are Maker Schedules (coder) and Manager Schedules (PHB), and the two are very different. With each day neatly cut into one-hour intervals, the Manager Schedule is for bosses and is tailor-made for schmoozing. Unfortunately, it spells disaster for people who make things, like programmers and writers, who 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, says Graham, since that's barely enough time to get started. So if you fall into the Maker camp, adds Graham, you better hope your boss is smart enough to recognize that you need long chunks of time to work in. How's that working out in your world?" Ironically enough, I have a meeting to attend in three minutes.
...but then again, I'm a programmer.
Where I'm at now, our system of measurements is basically just "I'll get it done today or tomorrow" to "It'll be done by the end of the week." There's simply so many potential obstacles and unaccountable variables that any more precision than that is pointless.
Where I used to work, we worked on a "Point System" where 1 Point was equal to about 1 Programmer-Day, and 8 Points were equal to 8 Programmer Days. Ideally, an 8-Pointer should take one programmer 8 days to complete and two programmers 4 days to complete. Of course, that always fell through. A half-pointer (4 hours) might take me anywhere from 10 minutes to two and a half days.
Two reasons: meetings make people feel important and they look like work (without having to do real work). I have found that most information gleaned in meetings can be e-mailed or distributed in some other manner.
With that said, there is a lot that can be learned in the "important" meetings. People give away a lot of information (body language, facial expressions, etc) about certain situations that can be very valuable. That is where I find most of the value in meetings. Plus, it is a good way to build and keep team cohesiveness.
As a lawyer I'm friends with told me years ago. That's what they call it in his industry, at least.
The time wasted switched from or back to a task you hadn't completed yet.
I agree with the article. One meeting can dramatically decrease the productivity for the whole day.
As a result I try to divide my time between all-day (or half day) tasks, and leave other days for things that take 1-2 hours a pop, including meetings.
Using the GTD (Getting Things Done) methods help organize things as well, but that's been covered many times here.
When I was a manager running a project to go live on a large web site, I knew the developers were busy. In the final weeks I limited meetings to a single, end of the day stand-up meeting. That let people report on status and issues, but limited the negative impact on people's productivity.
to work fewer days of longer hours, emphasis on evening hours when no one else is around in the office, for exactly the reasons mentioned in the article
at the very least, thank you very much for the article slashdot/ graham, it has great propaganda value and was just forwarded to my boss 1 minute ago as a follow up petition
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
A programmer's work is vastly different from a manager's, or anyone's where a certain amount of time gets you a predictable level of output. Hear what I'm saying? You might have already designed something in an object-oriented class tree that with slight tweaks to a subclass, meets the spec. You might encounter a strange bug that takes hours to chase down. You don't know all of that when the boss sits you down in a meeting and gives you a spec and asks you for a deadline right there on the fly. That plus micromanagement is the worst. You get jostled too often to get into any kind of groove.
The technical solution? Make your code as reusable and debugged as possible, because you'll never know when you need to write up a solution under adverse conditions.
The real solution? Explain this to your boss in a proactive way.
Anyone know a good book to recommend to the boss who's also the office schmoozehound?
My favorite sign about meetings was actually posted in a shipyard meeting room, it said "There are no problems that cannot be made unsolvable if enough meetings are held to discuss them". Meetings at this shipyard, tended to be short, and were difficult to schedule. Made for really productive meetings.
Meetings should be used to solve problems. Information can be passed by email, or better yet through formal documentation. Status reports can be done by email and should only contain tasks completed on time, tasks not completed or will not be completed on time, and why if there are any of the second. Regular meetings should be held one on one to help employees meet individual goals and discuss any problems in a private way. Beyond that, "meetings" like kick-off events and celebrations for meeting goals can be held to motivate and provide recognition. Though I wouldn't call those meetings in the traditional sense. In an Agile environment, stand up meetings are effective as long as they are short and to the point.
br/
It's mostly a big waste of time, used for people to make themselves look important by puffing themselves up in front of other people.
The only time I've found meetings to be genuinely useful, in my 11 years of corporate existence, is when decisions need to be made with a team's input. Then, it's really important to get everyone in a room together and hash out all the details in real-time, so ideas can be suggested and then immediately commented on, etc. However, in most companies, meetings of this type are quite rare. Decisions are usually made at the top, and have little if any input from the people actually doing the work.
Meetings solely for the purpose of "passing down" information are utterly useless and time-wasting. This crap can be put in an email and read in 5 minutes, instead of wasting 30-60 minutes of everyones' time with a lot of lip-flapping. And a lot of times, this information isn't even necessary or interesting to the people actually doing work: things like financials, etc. I'm an engineer; I don't need details about the company's financials, just a quick summary by email so I know my job is OK for the next quarter.