Maker’s vs. Manager’s Schedule

By Jake • August 17th, 2009 • View Comments

This blog is full of work-hacking lately.

Along those lines, Paul passed along an interesting post by Paul Graham that discusses the differences between schedules of makers and managers and how to account for them when scheduling meetings.

Photo by NikiSublime from Flickr used under Creative Commons

Photo by NikiSublime from Flickr used under Creative Commons

In short, one reason makers (i.e. developers or anyone whose work requires uninterrupted blocks of time to focus on a task) hate meetings is because they break up work flow. Anyone who’s written code or written anything, for that matter, will agree that to do it well, you need uninterrupted time to apply yourself to the task.

Managers, on the other hand, are usually accustomed to scheduled blocks of time, typically in one-hour increments, since their jobs require a lot more meetings and communication. Like it or not, managers meet; this is a big part of what they do.

Graham makes some good points that mirror my own experience.

For instance, I like to do deep thinking in the morning when my brain is more fresh and uncluttered, and therefore, a morning meeting can derail a full day’s worth of work by breaking up tasks that can’t be finished in single hour increments between meetings. After lunch, I’m much worse at concentrating, as my biorhythms slow down and food-coma ensues.

Not the best time to think critically about product design.

The problem with scheduling makers and managers is that the managers are generally the power brokers; they have less free time available, so their schedules take precedence. Developers’ calendars may show more free time, but the cost of interrupting coding time could be more expensive than asking the managers to rearrange a few appointments.

It’s very difficult to leave a piece of incomplete code and pick it right up after an interruption. Time is lost remembering where you left off, and you may end up repeating work or creating regressions that could have been avoided if you hadn’t stepped away from your code.

If only interruptions could be quantified in an easy-to-consume metric, e.g. the weekly status meeting is creating 2.74 regressions each week due to interruption, or the meeting you schedule last week cost 1.3 hours in redundant work.

That would change the power balance pretty quickly, since after all, managers are concerned about the bottom line.

Interruptions and multi-tasking are bad for deep thought tasks like writing code.

Development teams often struggle with meetings, since they’re made up of both makers and managers, and some positions, like product manager, don’t fit either mold completely, requiring both blocks of time for tasks (e.g. designing product, testing) and meetings (e.g. status meetings). Plus, development is highly collaborative, and no one wants to be left out of design meetings.

Design meetings are actually a pretty interesting example of the problem. These meetings should be large blocks of time (possibly full days) and should include all the people working on the product, even managers. Design meetings need to include deep-thinking and thus, need to be long.

However, booking meetings more than an hour in length is a good way to get people agitated, and it’s usually impossible to block that much time on a manager’s schedule.

So, what happens? You cram as much as possible into an hour and then schedule another hour later, thereby creating a disconnect. Next time you meet, you have to recall where you were and try to cram the rest into the 50-45 minutes after the recap. Rinse and repeat.

Eventually, these meetings turn into email threads, and inevitably more time is spent on recapping and including new people on the thread.

Total up the amount of time spent by the team, and you probably should have cleared a full day from the start.

When I worked with larger teams, I sometimes lost entire days to meetings. The more I had booked in a row, the more time it took to get back into the flow of work. Working on virtual teams in different time zones was the worst, since it inevitably ate the fringe hours (early morning, late evening) that would usually go to tasks requiring concentration when people in my office weren’t in the office.

It was depressing for me to look at full week and see 80% of it spent in meetings. Unfortunately, I don’t get paid to sit in meetings. Over the years, I’ve adjusted my job and schedule to be much less meeting heavy.

So, we’re going to try to follow Graham’s advice and work around the blocks of coding time Rich and Anthony need. This should be pretty easy for us, being a small team and all, but I wonder how it would work in a larger team. Seems like the onus is on the manager to account for the best times to meet developers.

What do you think about scheduling meetings to account for the makers? Do you have trouble picking up work that’s been interrupted by meetings? Feel like your job is endless meetings? Maybe you have an ingenious solution to this problem?

Find the comments.


Possibly Related Posts

  • Call me crazy but I like meetings...it takes quite a bit to get me to that point where I hate them. I've only reached that point once.

    I do like meetings to have a point though. An agenda seems too restrictive, but I get why it needs to be done given the audience. I do prefer the ad-hoc meetings as Brian alluded to above (hallways). I also like it when my manager walks around. Maybe I've been fortunate not to have the Office Space guy...

    I would attribute my like of meetings probably to the fact that I am more social than many. I spend enough time sitting in front of the computer...give me some humans please.
  • Yeah, the social aspect is key. I do all my meetings over the phone, which makes them more like chores and less social. Tough to chat up a friend over the phone while you wait for people.

    Being on schedule and over-scheduling time are the biggest problems.
  • 30 min meetings (instead of the default 60): check. Most meetings don't need anywhere near 60 mins and time just gets wasted when it's scheduled.

    Managing by walking around: check. Did that a lot when I had 12 people working for me in the same location. My goal wasn't to interrupt them constantly or "monitor" them, but to be available. An open door policy is fine, but some people are reluctant to interrupt others who seem busy typing on their computer, so wandering around may help here.

    Where any meeting planning strategy starts to fail is when you have a lot of meetings with people in other orgs, who may or may not understand your "meeting etiquette" (or heaven forbid, use the same calendar... or any calendar for that matter). You may want to reserve mornings for coding, they may not. And blocking out chunks of time on the calendar doesn't necessarily work as people tend to give up finding free time slots when it gets too difficult.

    Is there a perfect solution? Don't think so. There are lots of common sense rules that, if everyone were to follow them, would help cut down the number of meetings. Along the lines of only invite those who really need to be there. Don't schedule a meeting just because. Focus on the topic at hand. Be on time, so people don't have to wait. Accept/decline meetings in calendar, so the organizer actually knows whether the key people (well, there shouldn't be any others) will actually attend.
  • Solid tips. Unfortunately, this is learned behavior, and the geographical issues make it nigh impossible, e.g. I was up at 0730 for a meeting with people in India who had stayed late 2000.

    I wonder if setting calendar's default meeting time to 30 minutes would help. There are ways to nudge people in the right direction.
  • I set up my calendar client to show 30 min intervals, which the automatically turns any meetings by default into 30 min affairs.

    Yes, time zone issues can be frustrating.
  • I was thinking more along the lines of defaulting from the server so people would use it as the guide vs. 60 mins :)
  • bex
    great managers do three things to fix this:

    1) Have weekly team meetings at the same time each week. This lets their team schedule their "flow" time (god I hate that word!)

    2) Have tiny "morning meetings" with each member individually. This catches people before work time, and gives them the individual attention they need.

    3) Manage by walking around and listening. This helps catch small issues before they get big, and it doesn't interrupt anybody's schedule.
  • We started doing standups (from extreme/agile programming), limited to about 15 minutes, and they really cut down on meeting interruptions. It's a solid technique for most meetings, I like 30 vs. 60 minute meetings b/c the sense of urgency eliminates a lot of the wasted time.

    I have to say that 3 would be a bit odd. Any uncontrolled interruption breaks the concentration you need to work, and floating around feels a bit like Lumbergh micro-managing and telling me I need to come in on Saturday.

    Open-door office hours allow for the same communication at the employee's request, minus the creepy over-the-shoulder vibe.
  • bex
    #3 doesn't mean wander by an interrupt... it means wander by and see if anybody interrupts YOU.

    The idea is that a lot of decisions are made during brief hallway discussions. If you don't wander around, listen, and look for these interactions, you lose the ability to influence them.
  • OK, that's better. I still think the presence of the boss alone may elicit an interruption by attracting attention. I guess it depends on the manager and how much s/he mixes and mingles.

    There's an air of wanting-something and/or eavesdropping that many managers can't avoid when they wander the halls. I get what you mean though.
blog comments powered by Disqus