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.
That's not ironic, that's just coincidental!
And that was pedantic.
...and it's the coder's best friend.
As a computer programmer with an MBA (please don't burn me at the stake -- I'm a coder, not a manager, and have no desire to be a manager), I understand both sides of the story, and it isn't pretty. Meetings are crucial, but they need to follow these general rules:
(a.) As much as possible, have a single "meeting day". This article explains why -- programming is not a "stop-and-pick-up-where-you-left-off" profession. So, in other words, as much as possible, ensure all "administrative overhead" tasks, such as meetings, are blocked together.
(b.) Meetings must be limited to information that *everyone* *needs* to know.
If you follow these rules, meetings are a Good Thing.
Problem is, no one follows those rules, because following them is much more easily said than done.
The Institute of Incomplete Research has determined that 9 of out 10
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.
I'm both a coder and a manager. When I first started, the meetings drove me bonkers. After wasting enough time, I decided to ditch them altogether with my boss's approval so I could finish a big project.
I learned my lesson quickly. After each meeting that I skipped, my boss would show up in my office (effectively destroying the block of time I was saving), and then he'd tell me about 5 more projects brought up in the meeting that were automatically approved. More work was actually created because I wasn't there to shoot down off-track and silly ideas in these meetings.
I started showing up at meetings pronto to "keep the company on track with IT and software projects". It was worth it to waste 8 hours a week in meetings to avoid months upon months on projects initiated by people who had no clue how technology works.
When this happend at a place I worked at long ago, I wrote an application to generate plausible sounding time log entries - worked like a charm! Once a week I updated a list of phrases it needed to keep it sounding currnet, ran it, and was done. Bosses never figured it out.
There is no God, and Dirac is his prophet.
You couldn't just put a dummy there with a voicebox repeating "No", "No way" and "We can't do that"?
Or was the one in your company already employed as a SAP programmer?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Managers are usually not oriented towards your work.
They are usually acting as a worker bee for someone way above them.
Also, when I moved from programmer into management, I was amazed at the amount of sausage making that we protect the developers from.
Projects that are high priority- yet canceled without ever wasting your time.
Plus a lot of coordination and orchestration.
A good manager frees their developers to get work done and shields them from a lot of inane executive requests.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.