Any software engineer knows the feeling of being "in the flow", or "in the zone". It's when you get a large block of uninterrupted time to just code. These periods are rare, super productive and morale boosting.
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. Peopleware
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?
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 blocks (4 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 blocks of flow per week.
For a 40 hour week, we could theoretically schedule 10 four hour flow sessions or 20 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 "net work 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 20 hours of coding time, but only 10 of those hours are "in the flow".
These are mostly common knowledge.
Notice that these are entirely on the individual engineer to manage. What can we do as managers to help?
As managers, the most effective way to maximize the number of blocks 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 2 flow hours a day, or 10 flow hours a week, and our goal is 20 flow hours per week.
Also, remember we are assuming a maximum of five effective hours per day.
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 1 four hour block per week and 4 two hour blocks a week, for a total of 12 flow hours.
If you hold all meetings on one or two days a week, and leave the entire rest of the calendar free, you would have 3 or 4 four hour blocks per week. Assume that the one or two days you actually have meetings are complete write-offs. That results in a total of 12 to 15 flow hours.
You could block off 3-4 hours every day for interruption free working time. This could take the form of never scheduling meetings before lunch, or between 1pm and 5pm, 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 5 three or four hour blocks a week. Any non-free time can be assumed to involve interruptions. Let's estimate 15 to 20 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 3-4 hour block 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 20 hours of coding that engineers are typically getting, but a 100% increase in the number of coding hours "in the flow".