To understand why developers and designers hate meetings and interruptions, you have to understand the difference between a maker’s and a manager’s schedule (as Paul Graham observed in his famous essay on time management).
People who create things (designers, writers, developers) operate under a maker’s schedule, which is completely different from a manager’s.
Manager’s schedule is neatly divided into 1-hour blocks. They have appointments throughout the day, which can be changed on the fly. They timebox every task and can block of anywhere from half an hour to several hours for a task. Changing the schedule is easy for them, plus they don’t sacrifice any productivity while doing it.
Makers don’t have this luxury. They can’t divide their work into discrete 1-hour units; they need at least half a day of continuous work to get anything done.
Makers carry an overhead cost when they start working. For example, before a developer can start coding, they need at least half an hour to navigate around code and plan what they need to do. Once interrupted, they need time to get all those things back in their short term memory before they can start working.
Makers need continuous time periods of concentrated work. Managers don’t - they can switch between tasks and modes without any cost. Plus, because managers operate under a schedule, they can always protect themselves from interruptions by saying they’re busy and point to their schedule to prove it.
That’s why meetings are a disaster for makers, especially if they’re in the middle of the day. If you work from 9:00-17:00, and have a meeting from 12:00-14:00 (plus lunch), by the time you get to work, you’ll only have maybe two hours of continuous work - and that is if no one interrupts you. That’s barely enough to even get started. That’s why people finish their day without getting anything done.
Since managers have more power in organizations, they make everyone submit to their way of scheduling. Business people also have the privilege to have speculative meetings because they can afford them. A designer will have more trouble agreeing to “a cup of coffee” as the only way to get things done is to have a large, contiguous chunk of time to do it.
- Let your team have flexible work hours or work from home. For example, most freelance developers code at night because no one can interrupt them and they can get things done while the world is quiet.
- Schedule meetings at the very start of the day. This way, people don’t have to switch gears in the middle of work and can work without keeping one eye on the clock for when’s the meeting.
- Limit work to 40 hours/week, not 8 hours/day. If the person is in the zone, the worst thing they can do is leave the zone because the time’s up. Plus, if they have one hour left, instead of waiting it out, they’ll go home and use that hour better next day.
Productive people also know when to work on what. There are some tasks that require a lot of work and focus, and others that are comfortingly routine. Sometimes, you just don’t have the willpower to start working on a large feature or complex problem. Debugging is perfect in times like those because it’s so straightforward.
The program is supposed to do x, but instead does y. You have to find out why. The problem is constrained and you know you’re going to win at the end. This makes debugging relaxing and low-level activity when compared to starting something big.
Other low-level tasks include: checking email, responding to messages, admin stuff, catching up on news, updating tasks, checking results, etc.