I mean, for the love of God. Do not allow anyone to interrupt your developers as they see fit. Period. Whether itâs about taking a look at the specification document âreal quickâ, fixing this bug âreal quickâ or explaining how to use this API âreal quickâ, your developers will need 10 to 15 minutes to start editing code after resuming work from an interruption, according to a study from Georgia Institute of Technology.
So if one developer gets interrupted 10 times a day x 10 minutes to get back to what they were doing, thatâs 100 minutes, almost 2 hours, lost every day! Multiply this number by the number of developers in your organisation, and you get a picture of the lost productivity just because of âreal quickâ interruptions. And Iâm not even talking about planned interruptions (meetings) and self-interruptions.
I mean, youâve been there. Youâre in the middle of deep work. Someone taps on your shoulder⌠and, itâs gone. So if itâs clear for everyone that interruptions are bad and have a major impact on a tech organisationsâ productivity, why do we keep allowing them?
Why interruptions happen
Put aside the obvious (your developers are nice people and they want to help their colleagues), the modern workspace is actually organised to maximise interruptions. Open spaces where everyone is in the same room are like giant signs inviting to interrupt your colleagues. Phone calls, loud discussions and animated fussball games are no better. And if you think an unplanned interruption is bad, how about a planned one? If you know you have a meeting later today, your whole day is ruined because you unwillingly tailor it to make sure you finish your tasks on time. Paul Graham, the founder of Y Combinator, points out how meetings (a.k.a planned interruptions) can âblow a whole afternoonâ:
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.
What to do about it
When I was still managing my startup, our open space was like a monastery. Not a single sound for the most part of the day so all the makers (product managers, developersâŚ) could focus on deep work. Interruptions were strictly forbidden, and this allowed us to really move the needle on our product. But how were people interacting?
We actually had 2 types of planned interruptions: office hours and time bomb meetings.
Office hours: thatâs something I borrowed from my teaching activity at EPITA engineering school. As a professor there, I have office hours with my students every Tuesday. If they have a question, they can, of course, e-mail it to me but, if they want a face-to-face, they will wait until the following Tuesday. You can do the same in your company. At Basecamp, the project management software company, calendars are private and employees post âoffice hoursâ when theyâre available for meetings.
Time bomb meetings: as an individual contributor, I hated meetings that lasted for hours (especially when no decision was taken at the end). So to make them really effective, each time we had to have a meeting, I brought in a big timer, with a 15-minute countdown. At the end of the 15 minutes, weâre supposed to make a decision.
Another solution is to promote remote work. At some point, 50% of my staff was remote and it was also a great way to protect the developersâ deep work moments. Of course, to make it work, you should enforce a strict Slack policy so that your team wonât get digital taps on their shoulder đ