Software developers stereotypically hate meetings. Personally, I do not dislike meetings. In fact, I quite enjoy interacting in meetings. What I dislike is when meetings disrupt my day, slicing it into small increments, such that I have no time for extended, focused work. I have tried to voice this concern to non-developer colleagues a few times, only to be met with a response like: "Really? An hour a week is too much to ask?" This person's calculation is that there are 40 hours in a workweek, so asking me to spend 1/40 of my time in a meeting is hardly burdensome. Framed in this manner, it is hard to argue with that equation.

These two different ways of thinking about meetings come from the juxtaposition between the maker's schedule and the manager's schedule, described in Paul Graham's popular essay:

One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

When you use time that way, it's merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you're done.

Most powerful people are on the manager's schedule. It's the schedule of command. But there's another way of using time that's common among people who make things, like programmers and writers. They 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. That's barely enough time to get started.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.

The True Cost of a Meeting

Have you ever had a day broken up by one or two meetings where you don't seem to accomplish much else? You maybe stared at something for a bit, or even refactored a few lines of code, but you didn't make any substantial progress. Those days are frustrating, aren't they? You've probably also had the experience where every so often you find a day with uninterrupted time—maybe your colleagues are on vacation or at a conference, or maybe you are on an airplane—and you seem to get a whole week's worth of work done in one day.

A half-hour meeting doesn't just cost 30 minutes. You aren't going to start something significant if you only have 30 minutes or an hour until your next meeting. You'll putter at something or read some documentation, but you won't tackle something that requires deep thought and focused concentration for an extended period of time.

When Ray Ozzie was programming, he had a Four-Hour Rule:

Do not write code unless you can at least have 4 hours of contiguous time where you will not be interrupted, otherwise you end up introducing more bugs than the code you are writing.

Paul Graham describes these natural, half-day increments as well:

For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you're a maker, think of your own case. Don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Viewed in this light, the challenge becomes maximizing the number of opportunities where you can anticipate four hours of uninterrupted time to accomplish a significant task. So a 30 minute meeting mid-afternoon doesn't cost 30 minutes, it could end up costing half a day or more—half a day or more where challenging work will not even be attempted.

Creative insight can't be summoned on demand. Great software is not necessarily created between 9:00 a.m. and 5:00 p.m. It is certainly not created in between a 10:30 a.m. meeting and lunch. Software is created in enormous focused bursts. The goal must be to provide for the greatest number of these opportunities within a workweek.

The Daily Stand-Up

Most "Agile" teams have some form of daily stand-up meeting—the point of standing is to keep the meeting short—where each team member answers three questions: What did you accomplish yesterday? What are you going to work on today? Are there any obstacles impeding your progress?

I'll examine the utility of these meetings shortly, but first, consider the cost. Most stand-up meetings occur mid-morning. The meeting would ideally come at the beginning of the day, but getting a team of people to agree when to begin the day is difficult. Some people like to start early, others a little later. People have different commuting schedules. People might be in different time zones. As a consequence, the mid-morning meeting is a compromise, having the meeting near the start of the day, but not so early that it results in conflicts.

If we view the workweek as having ten, four-hour, uninterrupted increments where challenging work can be accomplished, the mid-morning, daily stand-up meeting just eliminated half of those.

Think about that: half. That is extremely expensive. Bisect a few afternoons with planning, review, or design meetings, and now there are only one or two opportunities in an entire week where developers can anticipate uninterrupted time. I believe this is why developers often work into the evening—it is the only opportunity to anticipate uninterrupted time in which to accomplish challenging work. No wonder development seems slow and product quality is poor.

I think this is argument enough for ditching the daily stand-up meeting in favour of other means of coordination. Some might argue that the benefits of the daily stand-up meeting outweigh the costs, but this hasn't been my experience. Let's examine the three questions each person is supposed to address in the meeting.

With regard to what I accomplished yesterday, we are in constant collaboration, as a team, on what it means for something to be done. The status of my work is visible and it can't be done without the team being involved. We are communicating via curated chat, pair-programming, code reviewing, writing tests for each other, evaluating changes via continuous integration, and so on. I either know exactly what a teammate accomplished yesterday, or I have a pretty good idea. Reiterating this in a meeting is of little or no value.

In terms of what I'm going to do today, we have a workflow system that describes the work that is in progress. I can see, via various means of asynchronous communication, the code that needs to be reviewed, or the tests that need to be written. We've likely already coordinated via chat to decide what we want to accomplish today. Again, reiterating this in a meeting is of little or no value. Add to this the dissatisfaction of optimistically describing what I expect to work on, only to be interrupted by higher priority items, accomplishing nothing of what I originally intended.

Finally, waiting for a once-daily stand-up meeting is a terrible way to deal with impediments. Impediments need to be dealt with as they arise. If the impediment is critical—like a production issue—it needs to be surfaced immediately. If it is not critical, there should be asynchronous means of communication—like email, curated chat, code review, etc.—to address the impediment.

Some people will point out that a stand-up meeting should be very efficient and that if you have nothing to report beyond what has already been communicated through other workflows, it is fine to just say: "Nothing to report". On a high-functioning team, there isn't usually much to report, so how silly is it to disrupt our mornings just so that we can hear that our teammates have nothing to report?

Most often, it is the managers who derive benefit from the daily stand-up meeting and argue its merits. The stand-up meeting was originally designed for the engineering team to coordinate among themselves. It was not a meeting for managers. If managers were present, they would not be active participants, unless called on to answer questions. Over time, the daily stand-up meeting evolved, turning into a daily status-meeting for managers to stay up-to-date and control the work of the team. Ironically, for some managers, their schedule is often so busy they cannot regularly attend the stand-up meeting, so they ask people directly for status updates later in the day, adding another interruption.

Thinking, Fast and Slow

The harm caused by the daily stand-up meeting goes beyond just the interruption. The daily stand-up meeting encourages snap decisions on critical matters, short-term thinking, and often invites opinions from people who do not have an in-depth understanding of the issues at hand. Erik Dietrich points out that these meetings can become dominated by extroverts and devolve into opinions, speculation, gossip, and non sequitur, only to have the well-reasoned analysis presented to the people that need to be involved in making a decision outside of the meeting anyway.

Daniel Kahneman in his book Thinking, Fast and Slow, describes our two complementary modes of thought. System 1 thinking is fast, automatic, instinctive, and emotional. System 2 thinking is slow, effortful, deliberative, and logical. The daily stand-up meeting, given its length and unpredictable nature, tends to involve mostly System 1 thinking. If System 2 thinking is engaged, the meeting tends to become too long and is deemed off-topic.

When we rely on our System 1 thinking to make decisions, our arguments, even if correct, may not be well-reasoned or well-communicated in the eyes of others, especially people who think differently from us, or approach the issue from a different perspective. This can rub people the wrong way and lead to serious interpersonal issues.

I usually try and minimize what I say in a stand-up meeting. When I need to make a decision or provide information, I would much rather have time to reflect, engaging System 2 thinking, and form a reasoned answer. I prefer to do this in writing, as it helps me structure my thoughts and provide a more complete and consistent argument. Having the reasoning captured in written form, so that it can be reviewed at a later date, by myself or others, is also valuable. As an aside, I'm intrigued by the idea of using shared journals to help demonstrate the thinking behind decisions and improve communication.

The one time I find a daily coordination meeting effective is when we are dealing with an urgent issue. A daily, or even twice-daily, coordination meeting in these situations can be very useful for keeping everyone on the same page—especially for coordinating between the development team and the rest of the business—and maintaining forward momentum. However, in this situation, we are not doing software development—we are basically just firefighting. If your development team requires daily coordination of this nature, you have more fundamental issues related to quality, trust, and focus, that must be addressed first, if you actually want to do software development.

Conclusion

As Paul Graham describes, the maker's schedule and the manager's schedule work fine by themselves. The problems arise when the two, incompatible schedules meet. Managers are in a position to make others work on their schedule, but should refrain from doing so with the understanding that the people working for them need significant intervals of uninterrupted time to work in. Indi Young, in her book Practical Empathy, elaborates:

Developing empathy in a leadership position means developing an understanding of how each person on your team reasons and what drives his decisions. It means knowing what will upset his concentration and what will energize his mind.

We have lost sight of the bigger picture. The daily stand-up meeting has become a ritual, rather than a practice. I think Uncle Bob Martin identifies what has happened to the daily stand-up meeting:

It's possible for a team to be so entrenched in practice that, over time, they forget the values expressed by those practices. This is a common failing of bureaucracies and religions. They become so strongly defined by their practices, that the practices become rituals, the original values are forgotten, and the rituals become the values.

Let's experiment with eliminating the daily stand-up meeting—embracing other means of communication and coordination—and focus on creating whitespace where makers can anticipate uninterrupted time to deliver valuable work. In the end, I think we will find that people will derive more enjoyment and satisfaction from their work and that there will be a noticeable long-term improvement in productivity, creativity, and quality.