Maker Time at Brigade

Every software company I’ve ever worked in has had the same complaint from the engineers: “I have too many meetings.” While this may be the case, and it should be addressed if it is, what happens when your meeting schedule is rather lean and you’re still hearing that? At Brigade we trimmed down our meeting structure and streamlined a lot of our standing process to minimize time impact, yet despite recognizing these improvements, we still felt our meeting load was too high.

Instead, rather than taking this at its literal interpretation, consider that this often means something else: “I don’t have enough time to feel productive programming.” Our solution was a typical one for Brigade — try an experiment to see if we could improve the situation.

Maker Time

Paul Graham wrote a great blog post on Maker Time vs. Manager Time. His basic premise is that programming (or any job that requires intense focus to maintain state) requires large blocks of uninterrupted time. It requires long chunks of uninterrupted time to make forward progress. Even a 5 minute meeting can ruin an afternoon by breaking them out of flow.

Comic Credit: Jason Heeris — License: CC BY-NC-ND 2.5 AU

Hypothesis

We theorized that moving all our standing meetings (pointing, sprint planning, 1:1s, etc.) to Mondays and Thursdays would improve the quantity of maker time every week.

Method

After doing some reading on what worked elsewhere and talking to members of the engineering team, our CTO John Thrall got buy-in from our Product and Design teams to try this out as an experiment, and we started moving our meetings to the allotted days. Our meetings had centered around Monday and Thursday anyways, given our sprint start dates, so this meant moving 1:1s and a few other random meetings. In the few cases where we weren’t able to accommodate this schedule, we moved meetings to first thing in the morning, or last thing in the evening. This let us batch projects which required task-switching and prevent costly task-switching away from programming.

Note: this only applied to meetings with engineers. Other parts of the company have continued to operate on their own schedules. Engineering managers, however, have tried to stick as closely as possible to this schedule for our own meetings (although with less success).

Results

Roughly two months* after making the change, we sent out a survey asking two questions and asking participants to rank the following on a scale of 1–5, with 1=“Much Worse” and 5=“Much Better” with 3=“No Change”:

• How has moving standing meetings to Mondays and Thursdays affected your quality of life?
• How has moving to standing meetings on Mondays and Thursdays affected your perceived productivity?

Overall, the results where largely positive. Quality of life was rated as 4.00 with a standard deviation of 0.76 and perceived productivity was rated as 4.13 with a standard deviation of 0.64. No one rated either of these lower than a 3.

(*Note: it would have been better to have surveyed ahead of time and then after the change for potentially better data. Unfortunately, I didn’t plan ahead well enough.)

While 4.00 and 4.13 ratings indicated that we’ve made some significant improvements, there were a few people who felt like we hadn’t improved their quality of life much. In the survey, we asked for additional thoughts or comments and primarily three camps of people with non-positive feedback emerged:

• Team leads: several of our team leads mentioned they were too frequently disrupted during their maker time blocks for this to have made a difference in their days. This is, unfortunately, likely going to be impossible to fix without causing other negative downstream effects. Because their job is, in part, communication and unblocking others, having them available to be interrupted is probably OK.
• People who feel we still have too many meetings: this will always be the case in a company — unless you err too far on the side of too few meetings. People have different levels of knowledge and communication channels, so it’s very costly to make everyone happy. I aim to maximize happiness without detrimental effects on the organization. Listen to these people though, as they often have valuable feedback.
• People who wanted them moved to other times: some team members wanted meetings early in the morning, some wanted none in the morning. Unfortunately, we can’t accommodate both of these given constraints of reality, although I encourage our individual teams to figure out if there’s agreement between their members for timing for any meetings which don’t require coordination with a larger group.

Limitations

As mentioned previously, it would have been nice to survey before and after the change to remove some subjectivity.

In an ideal world, it would have been great to track more objective measures of success in addition to the survey results. Surveys are useful, but can be highly subjective and therefore limit possible accuracy. Finding the right objective measures for programming productivity is difficult though. Perhaps some measure of story points completed, or some measure of the number of communication failures occurring (which would ideally be lessened by meetings).

Conclusion

To double-check these results, I did a quick survey of people’s Google Calendars. This supported the same conclusions: we’re doing pretty well for most engineers. We have a small number (maybe 3) standing weekly meetings for most engineers to coordinate sprint work and an all hands meeting Friday for general company knowledge transfer.

Given the survey results and these results, I would consider the experiment a success, and we plan on continuing to hold ourselves to this as a standard for meeting planning. I encourage others to try this out if you’re noticing too many non-clustered meetings or are hearing regular complaints about focus time from engineers on your team.