How to bridge the gap between maker’s and manager’s schedule in four steps
If you are a developer, chances are that you see meetings as a necessary evil. Your daily tasks are generally about writing code, or participating in peer-to-peer discussions that result in you writing code. And that’s what you like to do.
When you start working on something more serious, you typically need at least half an hour to dig into the problem, and even more to get in the zone. And it’s not unusual that you need several days to get done with a task.
This way of working is called the Maker’s Schedule, and the smallest block of time is half a day. In your world, an empty calendar equals the chance of really getting things done.
Your manager, on the other hand, operates on a different schedule. Most managers’ days are comprised of formal and informal meetings; talking to customers, analysts, sales, developers and other stakeholders. In fact, a significant portion of their unofficial work description is about leading and attending meetings. This holds true whether they are in a traditional management position or a more informal one, such as product owners, project managers and the like.
These people operate on what is known as the Manager’s Schedule, where a typical time slot is 30 or 60 minutes.
Now, the problem is that since they are the ones being in the power position, they also do the meeting summoning. And most of the time they are totally unaware of the typical developer’s fondness for an empty calendar.
An all too common example
An unsuspecting project manager books a one-hour meeting at 10.30 where your presence is required “since it is related to the feature you are working on.” After spending 45 boring minutes in silence, you eventually get a lame question that could have been answered in a short email instead. And after another 15 painful minutes of listening to people who love the sound of their voice, you are finally dismissed.
Being left with 30 minutes to lunch, chances are you won’t even try to pick up where you left off before the meeting; you would barely get started before the next break. Maybe you have some smaller tasks lying around, but you will probably feel that mental resistance that comes with enforced context switching.
Meetings, in general, can be a real productivity killer for developers, especially when they are scheduled in the late morning or mid-afternoon. And having one of each on the same day can totally derail your flow and leaves you with a feeling of having accomplished nothing that day.
The easy way out — just say no
A typical productivity coach recommendation is to say no to meetings not directly related to your work, but that might not always be as easy as it sounds. Many employees and long-term contractors are more or less expected the show up regardless of which when invited, and saying no is a no-no.
Another common solution is to block time in the calendar, something that may or may not be respected by managers. If go for this tactic, just don’t be that person that always blocks out every day and every week in the calendar as “Busy”. You will only come off as difficult and evasive.
The responsible solution
So — instead of indulging in the passive-aggressive act of participating in meetings physically but not mentally, I advocate that we as developers have a responsibility to educate our managers on the effects of this problem.
Step 1: Make them aware of the problem
Explain that your productivity suffers from having meetings scattered all over your schedule; and that you get way more done when you have an entire day of undivided time at your disposal.
Step 2: Eliminate participate-just-in-case meetings
Ask if you really need to participate, and why. Maybe the agenda can be rearranged so you don’t need to sit in just for the sake of it. And if this engagement involves prep time, make your manager aware of it. It’s all too easy to assume that a person just knows stuff and that it is all in that person’s head.
Step 3: Suggest batching
What if all meetings were scheduled back-to-back? While four consecutive meetings between 8.00 and 12.00 on a Monday can be mentally taxing, it is way better than having one each day, with four semi-productive late mornings as a result. Discuss which days and hours are most suitable for meetings with your team peers, and present the group decision to your managers and stakeholders.
Step 4: Establish a working agreement for meetings
First: respect everybody’s time. As a manager, avoid changing the schedule without good reason. Postponing a meeting by 30 minutes to grab a latte on the way into the office, just because the participating developers are free anyway, is just flippant. And as a developer — show up on time and be prepared.
Second: every meeting should have a clear purpose and a written agenda, preferably communicated in good time before the meeting.
Third: be mentally present. No multitasking or unnecessary fiddling with phones or computers. You are in the room for a reason, so focus and make it count.
Meetings are possibly the most misused tool in the toolbox at many companies, and it baffles me that so few people have realized how much money they can waste.
In an era where “work smarter, not harder” is the ubiquitous motto, let’s get ahead of our competition by making the meetings we actually have leaner and more to the point.