I have a friend who is a developer. He is very stressed out by his manager, who seems addicted to meetings. The volume of meetings is a problem, but what is more of a problem is that they are spaced out evenly throughout the day. Meening that there is sometimes only an hour between one ending and the next starting. Often they are moved or canceled at the last minute.

I and my friend know that this is bad for productivity, but the manager seems to be oblivious.

Does anyone have a definitive easy to understand explanation that shows how damaging to productivity this?

Ideally showing just how destructive it is. Something that looks scientific and has hard figures (even pictures) but doesn't go into too much detail will be good.

  • If your friend knows that this is bad for productivity, but the manager seems to be oblivious - what's the problem? Apr 9, 2013 at 14:26
  • 1
    The problem lies in trying to educate the manager. Apr 9, 2013 at 14:52
  • 2
    You mean besides this graph?
    – Adam Wuerl
    Apr 10, 2013 at 3:47
  • Oh come on. If, as a professional developer, your productivity suffers interruptions, then change your job. You will always be interrupted. Deal with it. The "flow" people are talking about is a myth. May 4, 2013 at 10:29
  • No matter how well scheduled they are, they are all evil, see Meetings Are Legalized Robbery
    – yegor256
    Jul 14, 2015 at 23:02

7 Answers 7


You are really looking at issues associated with multi-tasking. There are a number of questions on PMSE addressing this issue that you could look at. If you want something a bit more dry you could try this paper, but I would suggest that your friend:

  • Document the lost time. This would be the amount of time it takes to prepare for and then physically get to the meeting.
  • Provide alternatives. The extreme solution (no more meetings) is likely not going to work, but what if (for example) meetings were scheduled 15 minutes apart rather than one hour apart? Or could they be shorter? Or is the list of attendees right?

If you want to focus on meetings IMHO what is generally of greater concern is whether or not the meetings add value. You can save a huge amount of time, confusion and rework on your projects if you have well-run, effective meetings. Broadly speaking, a meeting will add value if:

  • Decisions are made; and/or
  • Clear action items are assigned; and/or
  • Important information is shared

While all of these could be addressed e.g. by email, depeding on your needs and bias a meeting could be far more effective.

On the other hand, meetings will lose their value if:

  • There is no clear purpose; and/or
  • There is no clear need; and/or
  • They are dominated by one or two voices; and/or
  • You fail to make decisions/assign action items/share important info
  • +1 for "to prepare for and..." - I generally budget 3 hours for a 1 hour meeting. 1 hour to prepare, 1 hour to participate and 1 hour of post-meeting action items. Also strongly endorse your comment that you have to provide an alternative.
    – MCW
    Apr 9, 2013 at 14:38
  • Sorry, but I think this answer misses the important point. The important point is that software developers are less productive when they are constantly interrupted; it takes time to get back into things and recover all the mental state that you had to page out when you got interrupted. I cannot imagine how I would ever document the amount of lost time due to trying to recover my mental state after a meeting and trying to get back into the flow. How would I measure that? Sounds impossible.
    – D.W.
    Apr 23, 2013 at 6:14
  • @MarkC.Wallace, I don't think preparation or action items are the issue at all. Even if there were no preparation time and no post-meeting action items, a 1-hour meeting in the middle of their work period would be a productivity killer for a software developer, because you are interrupting them while they are in the flow, and it takes a long time to recover from that. This phenomenom is specific to the nature of software development (which requires holding many complex pieces of a puzzle in your head all at once), which is why some managers may be less familiar with it.
    – D.W.
    Apr 23, 2013 at 6:16
  • @D.W., the paper cited in my answer talks about cognitive switching. I disagree with your assertion that the challenges posed by cognitive switching are either unique to software development (I have seen it in action with marketers, sales staff, scientists, pharma QA teams, my family doing chores, etc etc etc) or that preparation for and addressing action items brought up in meetings do not impact productivity.
    – Doug B
    Apr 23, 2013 at 12:07

Developers are most productive when they focus on one thing at a time...

...without interruptions and task switching. Meetings are only one form of interruption. If you have a ScrumMaster, consult with him/her and let them handle this.

If not, there is a thread on Programmers SE that has good discussion on this topic. You should be able to extract what you need from that. And then find a way to present it diplomatically to your manager!

  • I did think of posting on programmers, thanks for the link Apr 10, 2013 at 10:06

You need to explain what is unique about software development: that as a software developer you need uninterrupted time.

Software development requires holding many pieces of a complex puzzle in your head all at once. It's enormously challenging to assemble all those pieces. As a developer, once you've got those pieces together, then you're furiously trying to solve the problem while you can still keep it in your head and have the clear insight. If you interrupt a developer while they're in that state, then you're forcing them to think about something else, which drives all of that out of their head, and they're back to square zero. Even if it's just a 5-minute interruption, when you walk out, it can take them a quarter hour or more to recover where they were and get back into the same mental state.

Have you ever noticed how developers, once they get into the flow, often seem immersed in some fugue where they don't notice the outside world for hours on end? Maybe your favorite developer emerges 6 hours later, looking a bit dazed. Do you know why that happens? It's because of the flow state. Getting into that flow state isn't easy, but once you're in it, you lose track of the outside world.

For this reason, it's not the number of meetings that matter. It's the effect it has on the amount of uninterrupted time that developers have.

You can still have meetings without undue negative effect on a developer's productivity, if the meetings are scheduled very carefully. For instance, if you make Monday "meeting day" and schedule all meetings on Monday, then Monday becomes basically a write-off for software development, but at least the developer still has four other days a week for productive work: 80% productivity. On the other hand, if you schedule two meetings a day, one at 10:30-11:00am every day and another at 2:30-3:00pm every day, that's about the worst torture you could do to a software developer. Sure, it's only 5 hours of meetings a week -- but you've just killed any hope of having a prolonged uninterrupted period where one can focus on software development. That's deadly for productivity.

Finally, I'll note that this phenomenom is somewhat specific to software development. It doesn't apply to most managers or business folks. That may be one reason why many managers are unfamiliar with this issue or why it may not occur to them without prompting.

You know your manager best, so you will know best how to communicate with your manager. What you don't want to do is come off as whining, or trying to avoid meetings because you hate meetings (yes, we all hate meetings, but your manager has probably scheduled them for a reason). Instead, you want to emphasize that your interests are aligned. It's about helping you to be more productive: something your manager probably cares a lot about. Then, if your manager steps up to the plate by helping you get more uninterrupted time, you need to deliver: you need to actually be more productive. If you do it right, everyone walks away happier.

For more, see the following:

  • The Joel Test: 12 Steps to Better Code, 8. Do programmers have quiet working conditions? - Here Joel explains why it is so important for developers to have private offices and quiet places to work without interruptions. It's because interruptions kill productivity, for software developers.

  • Where do These People Get Their (Unoriginal) Ideas? - Joel talks about why it's so important to be able to get into the flow and stay in the flow.

  • Getting Things Done When You're Only a Grunt, Strategy 5 Get Away From Interruptions - Here Joel is giving advice to fellow developers about how to avoid interruptions. (The hidden subtext, which Joel doesn't need to explain, is why avoiding interruptions is so critical to productivity, for software developers.)

  • A Nerd in a Cave - Rands talks about his "nerd cave", which is just a fancy way of saying a comfortable place that helps him get into the flow state and stay there.

  • Meet the Life Hackers - This talks about productivity and the cost of interruptions. It quotes a claim that, when someone is interrupted, it takes 25 minutes to get back to the original task. That's for non-developers; I expect it'll be higher for software developers.

P.S. If you want to get advanced, read Rands in Repose on meetings. But that's an advanced topic, for later.


My company ran a blog post with a bunch of infographics showing how much America meets and how costly it can be (on average, $338 a meeting). If you can quantify meeting attendee's hourly wage, and add it all up for each hour the meeting is, then estimate the actual effectiveness of the meeting (or ineffectiveness), you can come up with some rough and scary numbers. But take a look at the blog post here to get an idea.


Aside from being a distractions, these meetings can basically be "scheduled procrastination". When you're expecting a meeting, it's very hard to get into "the zone". And of course the meeting itself breaks your flow completely. I wrote about this recently in a blog post. Sometimes it's just better to have surprise meetings than scheduled ones.

But of course 1 meeting a day is better than 4. If your manager is susceptible to evidence, try measuring your periods of continuous work and how much you get done during them. For example, you can use a time tracker to track your actual work intervals, and then cross reference those with some measure of productivity. e.g how many commits you've done during each period of work. If you show your manager that uninterrupted work periods yield more commits than interrupted ones (per hour, of course) he might realize that he's slowing you down.

However, I have to wonder (and pardon me for doing so) - have you actually talked to him about it? Sometimes you don't really have to throw data at someone, or prove your point. Sometimes it's just enough to talk it out and convince. You know.. with words. :)


The problem your friend is dealing with can be classified as “interruptions,” and according to these guys, they were cited as one of the most dangerous productivity killers. This article also contains some useful statistics on the matter. I hope that would be enough to divert that oblivious manager of yours from his meeting obsession.

Good luck!


I had a similar issue at a previous company, mostly in the form of separate weekly meetings for each department - art, design, dev, QA, etc. (this was a game development company). It was clearly causing what I refer to as "thrash" due to the context switching, preparing for/ramping down from meetings, and not being able to stay in flow. The worst part was the meetings were at different times and days, so true collaboration opportunities were very limited. On top of that we had ad-hoc meetings, 1-on-1's, and so on which fragmented everyone's time even more. The initial evidence was a lot of internal blockers brought up at standups, a lot of conversations around when team members could coordinate, and a general feeling that our teams weren't going very fast (our feeling, not management's :) ).

Everyone in the org knew of hard data around the consequences of context switching, and we had even done group exercises to illustrate how multi-tasking causes problems, so most of the "proof" needed was simply showing that we were experiencing that thrash. I took a few snapshots of the teams' previous weeks' availability in Outlook, and pointed out to the department heads how rare our "100% team-available" time was throughout a typical sprint. We ended up working together to consolidate the recurring meetings to one day every two weeks. It was daunting to have that many meetings in a row, but we treated it as an experiment. We knew it would be difficult to gather hard data around the changes, but we did note that the teams' velocity increased without any apparent new negative effects. For anecdotal evidence, most team members said they liked it better, felt more productive, and in some cases, found themselves having to create their own break times throughout a day as a sort of "ease-out proxy" for not having meetings. The big-meeting day started out feeling heavy and strange, but eventually it just became more of a "day of knowledge-sharing" and people used any spare time that day catching up on small tasks that could be done in isolation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.