Minimizing The Impact of Interruptions on Engineers

any software engineer knows the feeling of being "in the flow," or "in the zone." it's when you get a large chunk of uninterrupted time to just code. these periods are rare, super productive and morale boosting.

importance of flow

according to peopleware by tom demarco, "during single-minded work time, people are ideally in a state that psychologists call flow. it is a condition of deep, nearly meditative involvement, a gentle sense of euphoria when one is largely unaware of the passage of time. for anyone involved in engineering, design, development, writing or similar tasks, flow is a must. these are high-momentum tasks that only go well when you’re in flow. unfortunately, it can’t be turned on like a switch, it takes a slow descent into the subject, 15 minutes of more of concentration before the state is locked in. each time you’re interrupted, you require an additional immersion period to get back into flow."

flow is critical to creative endeavors like coding. our goal as engineers and managers should be to maximize this across our teams. because interruptions can disrupt flow, they must be minimized. beyond that, what should our goal be for flow time?

maximize large chunks of flow time

the current state of the industry is that a programmer is likely to get just one two hour session of flow per day [ programmer interrupted ]. that should be our absolute floor. paul graham advocates for half-day chunks (four hours). for context, air traffic controllers are required to take a break every two hours .

in the absence of any research on the maximum duration a software engineer can be in the flow, let's say that our goal should be to maximize the number of two to four-hour chunks of flow per week.

for a forty-hour week, we could theoretically schedule 10 four hour flow sessions or twenty two-hour flow sessions. that's assuming 100% capacity. based on experience, scrum best practice is to assume that engineers get about 5 "effective hours" or "network hours" a day. see: determining how many task hours an agile team can accomplish .

that aligns with surveys which show that 50% of engineering time is taken by non-coding tasks.

note: taken together, this means that an engineer is on average getting about twenty hours of coding time, but only ten of those hours are "in the flow."

strategies to minimize interruptions

these are mostly common knowledge:

• put on headphones.
• don't answer email/slack.
• hold "office hours" to batch up interruptions.
• work from home.
• go sit somewhere by yourself in the office.

notice that these are entirely on the individual engineer to manage. what can we do as managers to help?

strategies to maximize flow chunks

as managers, the most effective way to maximize the number of chunks of flow our teams get is to clear the calendar. in this context, what types of calendar items constitute an interruption? basically, anything. regular meetings, 1:1s, interviews are all obvious interruptions.

here are some common top-down strategies to minimize interruptions. again, our baseline is the industry average two flow hours a day, or ten flow hours a week, and our goal is twenty flow hours per week.

also, remember we are assuming a maximum of five effective hours per day.

no meeting days

the most popular strategy is to have an entire day per week with no meetings, where everyone can be heads-down. you might combine that with giving people permission to not answer email/slack, or work from home.

the great advantage of this tactic is that it's easy to communication and understand. it's also relatively easy to get buy-in to delay a meeting by at most one day.

in the best case scenario, this translates to a one four-hour chunk per week and four two-hour chunks a week, for a total of twelve flow hours.

consolidating meetings to one or two days

if you hold all meetings on one or two days a week and leave the entire rest of the calendar free, you would have three or four four-hour chunks per week. assume that the one or two days you actually have meetings are complete write-offs. that results in a total of twelve to fifteen flow hours.

no-meeting mornings/afternoons

you could block off three to four hours every day for interruption-free working time. this could take the form of never scheduling meetings before lunch, or between 1 pm and 5 pm, etc. in practice, it would be important to align this with times people are actually in the office if you allow flexible work hours.

this would result in five three- or four-hour chunks a week. any non-free time can be assumed to involve interruptions. let's estimate fifteen to twenty flow hours.

given that engineers are going to get at most five effective hours a day, the ideal set up from a flow perspective is to get a three- to four-hour chunk of time blocked off every single day with no interruptions. interestingly, this is 80% as effective as never having any interruptions at all - the equivalent of a 100% meeting free week. it's also the same twenty hours of coding that engineers are typically getting, but a 100% increase in the number of coding hours "in the flow".