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.
If you need heads-down time, block it off on your calendar. That's the easiest and first thing one should do if there is open space on their calendar and they are complaining about constantly being interrupted. Of course, this doesn't help when the person interrupting you is sitting on the other side of your cube's wall....
Did they tell you to bring all of your desk items with you in a box?
...and it's the coder's best friend.
I never have understood why managers love meetings. I mean, it kills productivity, usually ends up being boring or unrelated and in general a waste of time.
Taxation is legalized theft, no more, no less.
...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.
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
Ironically enough, I have a meeting to attend in 3 minutes.
Please, oh please, tell me it's about firing your web developer!
Comment of the year
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.
In my experience having to go through a meeting that requires a lot of explaining and problem-solving can render me more or less useless for the rest of the day, programming-wise. In some way that I don't know how to explain the meetings eat up the very concentration that I need for programming. Perhaps it takes so much out of a programmer when you try to understand someone instead of something you can logically deduce.
I dunno. It's still a mystery to me what one meeting can do to you sometimes.
The lyf so short, the craft so long to lerne
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?
I find, as do others I work with, that the little one-off, "micro meetings" held around the office every day are very useful. Instead of getting the X people needed to make a decision into a scheduled room, grab them and stand in front of a white board (or whatever) in an ad-hoc fashion. Or, as we do, we all turn around in our chairs, discuss what needs doing, and get back to work in a matter of seconds/minutes, instead of scheduling a full meeting.
I feel like when a meeting is scheduled, the time leading up to the meeting is seldom useful (oh, meeting in 15 minutes, better start slowing down/not start any more work), then the time after the meeting loses some function as there is the inevitable discussion of what we talked about, the creation of minutes, followup emails, etc. On a somewhat similar note, booking a meeting for a 1/2 hour instead of an hour forces people to work faster, and cuts down some of the wasted chit chat time.
We just moved into a new office here, and it has a large number of meeting rooms, which is great. But, even better, there are quite a few "break out" areas, with chairs and a white board, but no door, and no reservations. So when you need to get a couple peoples ideas, you steal a breakout room, and whiteboard what you need. Use your mobile to take a picture of the whiteboard, erase, and move on to the next task. Plus, these meetings tend to be over quicker.
Another trick I've learned .. if you get invited to a meeting, and you don't really feel like you need to be there, just decline it. If the meeting organizer really wants you there, they'll invite you agian, or call up/email and say "oh, we'd really like you there". but it saves you from sitting through a meeting where you just zone out and waste an hour.
Overall, there is great value in meetings, but only if they are kept to the time required to resolve whatever you're there for, and only if they pertain to everyone there. It's pointless to invite 2 different groups to a meeting, so one has to listen to the other talk and be bored, then switch. Focus on goals, invite only the people who need to be there, and get back to work.
We emerge from our mother's womb an unformatted diskette; our culture formats us. - Douglas Coupland
Awhile back, we got a new head of our department. He decided that he needed to see how everyone used their day so he required everyone to fill out a form to track our time. I joked that my time tracker would look like this:
8:00am - 8:15am - Checked/Answered E-mail
8:15am - 8:30am - Entered time tracking for 8:00am - 8:15am
8:30am - 8:45am - Entered time tracking for 8:15am - 8:30am
8:45am - 9:00am - Entered time tracking for 8:30am - 8:45am
9:00am - 9:15am - Entered time tracking for 8:45am - 9:00am
etc.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
"Does he weigh as much as a duck?"
BURN HIM!!!
I've railed on about MBA types and the guys in suits but for the most part I've never had a manager that tried to hold me to an hourly schedule. They have to have an hourly schedule to cover all the meetings and people but they don't hold the makers to it.
This is my sig.
Anyone else notice that the first 10 or 15 comments to this story all got 'troll' mods, regardless of content? Weird.
Nerd rage is the funniest rage.
I schedule 'programming time' into outlook.
Oh yeah, that's also why you force team meetings at the beginning of the day. You schedule them later, they disrupt the flow. And only idiot managers think you can schedule programmer progress by the hour.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
Sounds like Scrum.
The lyf so short, the craft so long to lerne
I think this applies to any trade where a discrete task or work package cannot be completed in an hour's time whether it be drafting a document, doing analysis, generating drawings, or redoing a house's plumbing. If the task at hand doesn't have a good ending criteria that can be reached within an hour's time, any significant interruption is going to increase cost as the worker has to regather their thoughts and figure out where they were.
While I like the idea of pooling meetings into a single block, this sometimes doesn't work especially when the worker support's a cross functional team. They may have program management calling meetings from one direction, functional management from another, and then their own team's huddles, peer reviews, etc.
Unfortunately, managers love the term "granularity" and have been using it as a cudgel. They've locked on to "Agile" programming and SCRUM project management as methods for driving this granularity into the development and test processes. They want tasks broken down to 15 minute increments and balk when any task takes more than a couple of hours to complete. All this so that they can achieve "visibility" and "predictability" for a given project, i.e. they get more status reports with pretty charts and graphs. I really despise the term "burn down" which springs from the whole thing as well.
Now, I may sound bitter about this but, I do understand that for all parties involved in a project, especially a large scale project; there needs to be an understanding of where team is at, where it's headed, and where the bottlenecks are located. This is not any easy problem to solve; it involves lots of guess work and dependency graphs that would make Euler weep. I suppose that's what makes it all the more irritating when managers think they have yet-another-silver-bullet for project management that they misuse causing more Maker frustration and possibly increasing the chance for failure rather than ameliorating it.
Sorry, end of rant.
This is a beautiful, well-written essay. One of the best linked from Slashdot in my memory.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
There are very good reasons to have meetings, and meetings can be useful when done well. Just google for stuff about "effective meetings".
:).
:)
You could have meetings to introduce people to each other, meetings to get information, meetings to decide on stuff, meetings for brainstorming, make important announcements - for instance if Mr CEO is going to lay off lots of staff, I feel it's rather bad form to just send an email.
The main problem with meetings is when the people involved don't know what the meeting is for- one might think it's for brainstorming, another might think it's for deciding (build a consensus on direction to go). So the meeting could go on for hours without achieving anything useful. The people involved need to know the agenda and reason for a meeting, especially the person chairing the meeting
Now once you get that done right, there's still room for greater efficiency.
With conventional meetings you use up Y hours of X people, though most of the actual participant "brain usage time" is only a few minutes. This is analogous to a program running for X hours of "real time" but only using 5 minutes of CPU time. Conventional meetings have the problem of wasting 2 hours of 10 people's time.
So if I were a boss, I might "encourage" my employees to use instant messaging for certain types of meetings where possible. That way I can have them in multiple meetings at the same time (bwahaha!).
The chatlogs could then be archived (automatically? ) to somewhere where I can quickly see what they've been up to (and for official record). I don't care if they're doing other stuff during those meetings - as long as they can still contribute usefully (I'd prefer to hire people who can read and understand things fast).
Thing is you can't have such meetings throughout the day + every day, since many things require full concentration. If people can't drive properly while chatting over the cellphone, I'm sure they can't do certain work related tasks while being in a meeting. So meeting times where possible should be restricted to certain parts of the day, or to certain days.
I doubt attending a meeting requires that much concentration, you could probably idle a fair bit even if you're in 3 "instant messaging" meetings at the same time.
You could even go for a coffee/toilet break, or take an important phone call without wasting everyone's time when you "return" (with conventional meetings there's often the repeating the past X minutes) - you just scroll up to see what you've missed. You do need to say that you've gone "AFK" though, so that the rest don't waste time trying to ask you questions that require immediate response.
Rather than just zoning out and trying not to fall asleep, create yourself a list of problems that you can think about and take notes on your thoughts during the meeting. Not only does it look like you are diligently writing down pertinent meeting information but, you don't break your concentration flow.
The one pre-requisite for this is that you have to have someone in the meeting who actually *does* take notes and is responsible for the minutes. If you are asked to write up the minutes after the meeting, your boss is not going to be pleased when they read:
- 8:00: Meeting started
- 8:05: Manager talked
- 9:00: Meeting ended
Go Go Gadget Tacos!
I schedule meetings for late in the day.
I let my guys work the schedule they want but hold them to project deliverables and have regular status checkups.
I prefer iterative project management over waterfall methodology.
Left to themselves, programmers will grossly over/under estimate the time it takes for a project.
Based on this, over time I build a factor of an individual programmers over/under estimation and apply it to their estimates.
It works amazingly well.
Work should be timeboxed too. Produce a working deliverable by time "X". If some feature can't be finished in that time- then it goes to the next timebox. All "risk" features which must work for the project to work must be addressed before easy work is started.
Risks are mostly new technologies that the vendor assures you will work but may not.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Sometimes, there's a slow day, and I'll have the time to tackle something more complex (the half-day or all-day tasks that were mentioned). Then there are all kinds of time slices I may have to fill, 30 minutes to lunch, the hour until a meeting, ten minutes until I have to catch the bus. I just keep a todo list with tasks ordered by estimated complexity. This includes e-mail responses, reading that article you always wanted to read, updating the internal Wiki, writing documentation, do Jira task housekeeping, checking out stuff from the repository and so on. I forget those things easily so I keep a list.
Meetings usually don't come as a surprise, and there aren't too many (good project management makes sure that is the case). Having them at the beginning or end of the day (as suggested) is the obvious thing to do. Then there are surprise items where you have to drop everything and take care of them, so it's not always the fault of meetings (don't you ever get "hot issues" from customers that support couldn't handle and that have to be solved right now?). Plus, there's multitasking. Obviously you won't stare at the screen waiting for make veryclean to finish. In a nutshell, prepare for a day that may contain unexpected tasks of uncertain lengths. If you didn't need time management until now, consider yourself lucky.
Your chart might show UI team completing their tasks in 45 days, and the video-codec team esitmating they need 75 days. You can transfer the UI developers into video codec team and ship the product in 60 days. Programming skills are not interchangeable. Till people recognize that you can call the specs, user stories and meetings scrums, but in the end, it is not going to change anything.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Use technology to solve the Dilbert situations in your organization. Use speech-to-text software that is in every new copy of MS Word. Or something better. Have everyone at the meeting forward their personal speech-to-text template file (what you created when you read The Wizard of Oz to your PC) to the meeting's secretary. Then use these templates to create a transcript of the meeting into a text file. E-mail the text file to anyone at the company who couldn't be at the meeting because they were doing useful and profitable work for the company. Have them e-mail their comments about the meeting's topics to the other people at the meeting.
If all this is too much or too complicated, then stop having so many useless meetings. You guys are the technocratic elite: so start using technology to solve your nitwit manager problems. Any intelligent person can read much faster than they can speak or listen.
There is no real reason that all meetings have to be face-to-face and in real time. Jeez, guys, enter the 21st century. Or better yet, stop caring about meetings so much. Zone out while still looking attentive and consider a meeting to be a half-hour vacation. Don't forget, the economy is collapsing. It's only a matter of time before it collapses your company. If you make money for your company through your work, there is a slightly less chance that you will be in the early waves of layoffs. Use meeting time to think about how to use your programming skills to increase local food production and neighborhood security. Or just dream of fondling your pretty co-worker's breasts. Nod your head occasionally to give the impression that you agree with the moron who is presently making sound come out of his mouth. Pretend that you're Nicole Kidman in 'The Interpreter' and are in the UN and translating the speaker's words into Kuu or Bongo language. Do something creative;anything.
Just remember, if it's not written down and sent to you as a memo or e-mail, it's not serious or important.
But just because they have to happen doesn't mean that I can't generally schedule them to my advantage.
I tend to group my meetings so that they're in a single block when I can. That way they don't run long ("Sorry. Have a 10:30. Gotta go.") and I can then keep the rest of the day free for actual work.
For those days when it isn't possible that's when I do my documentation since there's no way I can get back into a project and do anything useful with an hour.
Back in the days our calendar system would auto-accept any meeting invites. It was a while ago. But that meant you got put into all kinds of meetings without actually being able to request a different time up front. My boss had the best solution, which we all try to do now based on other responses. He blocked out 80% of his day into two events: "HFMTDW". If you needed to get into the blocks you asked and he would free up the time for you.
"HFMTDW" = "Hiding From Meetings to do Work"
I loved that boss. Too bad being the manager of our division drove him into a nervous breakdown after 18 months.
fixed that for ya
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/
This is probably true in other situations as well; but in academia one of the issues I run into is that I've got about 50 managers - one real manager plus 50 faculty. So this manager's schedule vs. maker's schedule gets multiplied by that many times, and compounded by the assumption (by each faculty) that their project is the only important one, and I'm just twiddling my thumbs waiting for them to give me more work.
Oh, and coincidentally (NOT ironically!), a few seconds ago I just experienced the "I sent you an email request three minutes ago and decided to come right down to see if you got it yet and if the work is done" school of management. So there are LOTS of exciting ways "managers" can bring my workday to a grinding halt...
#DeleteChrome
The most important thing for a good meeting, in my experience, is to have someone actually firmly running the meeting.
There are precious few people (in my experience) who can do that.
But if you have an agenda and someone keeping the meeting on track, you can get a lot of meeting-work (communication, decision making, brainstorming, whatever the purpose is) done very quickly.
Unfortunately, the people calling and running meetings aren't usually competent to do this. So they flail around and let the meeting get totally off topic.
The preferred solution is to not have a problem.
Linked to wikipedia -> # 2009. Software Engineering: An Idea Whose Time Has Come and Gone?. IEEE Software, Viewpoints. July/August 2009. pages 94-95.
The lyf so short, the craft so long to lerne
Ok, no *good* Project Manager plans in hours. A day is the minimum and usually weeks work best.
That's really strange. I can only assume the problem comes from unskilled management unused to dealing with skilled workers completing a complex task.
I work in industrial engineering, and all my labour estimates are set within a half-day's time, and that wisdom came from the management types around me who stopped me when I was scheduling things to take an hour or two.
Maybe things are different in an office environment, but it seems to me these programming companies are
It's been a long time.
Some of us have to use Lotus Notes, you insensitive clod!!!
yeah.... *snif* it's pretty terrible...
The World Wide Web is dying. Soon, we shall have only the Internet.
If you can keep to a schedule while programming, you must be making another scalable application to add an amount to a bank balance.
I visited Google last year, hosted by a mid-level executive. I asked him: Yes but, how can your engineers work on their 20% time projects without being hopelessly stressed out? Every software project I've ever worked on or seen has been behind schedule. Doesn't that apply to your engineers' main project too?
He said: "We don't really have schedules. We work on things til they're good enough."
Everyone I tell this to says:
"Yeah but that's because they have money to burn."
To which I reply: "That's a correlation, but we don't know which way the cause-effect arrow goes."
Where are we going and why are we in a handbasket?
doh.
...in transitioning from systems & coding to PHB: I now have to keep a schedule with the rest of the world. I used to be able to come in at 11AM or Noon, leave at 3, come back at 6 and work till midnight if I wanted. If I wanted to see a movie at 2PM on a tuesday afternoon, I went to the movie. But our entire development team in that time consisted of me, myself, and I. Now I have 2 full-time developers and 2 more contract developers that I have to coordinate with. I still have some flexibly, but generally I need to be in the office by 9 or 10AM to answer emails and to go through the support tickets, assign tasks, etc.. The coders usually show up sometime between 11AM and 1PM and then work for a couple hours, head home, then do their real work usually between 10PM - 4AM. The time they are in the office is usually spent asking questions, or we're doing testing to see if things work in the production mock up.
I don't care when or how the work gets done, just so long as assigned tasks get finished in a reasonable amount of time. And if they are having problems, let me know. Other than that, our developers have a free hand.
I don't get to schoomze. That's the other co-founder and CEO's job. Granted he owns another business that is the primary source of his income and that takes a lot of his time. We generally meet 3 hours a week total, make sure we're on the same page, and he does the sales negotiations with clients and corporate paperwork (like payroll and taxes). Meanwhile I have the title of COO and over see the day to day operations of the company.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Dismissiveness, making excuses and belittling are easier than learning. Painting in broad strokes, wrapped in patronizing pity. i've read the same boiler plate apologism many times.
"Oh you poor little atheists/liberals/environmentalists/vegan/$groupThatPeopleDismissAsSmug."
If your post has any truth to it, teachers and instructors of all kinds and levels are 'truly pitiable creatures'.
No, it's mostly that people don't like learning they're wrong or have made a mistake. Instead of learning, they name call and pout (and sometimes they pout eloquently). If someone corrected my bowling technique or process for solving an equation or understanding of some subject, i try to be adult about it and learn. Or i could choose ignorance, or worse be dismissive of the other person.
It's like the guy with the BMW and hot wife. A loser sees him on the street and assumes the guy must be unhappy or that he has ulcers or something... ANYTHING to avoid admitting the truth of his envy and self loathing. It's the jock who makes fun of the nerd who earns better grades. The nerd making fun of the jock for being a meat head who can run faster, lift more and is banging the head cheerleader.
*yawn*
Utilizing the synergization of benchmark e-solutions to pre-workaround action items!
According to Graham, programming is exactly like painting so you don't have to plan anything. What is there to discuss in a meeting? Your clients can only interfere with your artistic vision, they can't understand what they want until they've viewed your complete masterpiece.
During my brief 10 years as a programmer, I've seen time and time again that a well planned meeting with an agenda almost always eliminates more work than it takes to have the meeting. It's important to spend time prior to the meeting to plan what needs to be talked about. If interrupting your work is an issue, then you need to have your meetings at a time when you're already forced to lose focus, so as before you begin work or bordering lunch.
I admit, it has been several years since I've tried speech-to-text software. How successful have you been with it, successful enough to have recouped the time spent with the setup within 3 months?
"What luck for the rulers that men do not think." - Adolph Hitler
I tend to like the brief, developer-only meetings. As a developer, everything else seems to be unnecessarily long and irritating.
If your post has any truth to it, teachers and instructors of all kinds and levels are 'truly pitiable creatures'.
Totally agree. Been saying that for years.
-1 Uncomfortable Truth
Oh, and when you tell me how I can achieve immortality and have limitless time to learn everything there is that can be known, that's when I'll stop resenting your time-wasting pedantic outbursts...
-1 Uncomfortable Truth