How to bridge the gap between Maker's and Manager's Schedule in four steps

As a developer, the chances are that you see meetings as a necessary evil. Your daily tasks are generally about writing code, or about 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 more advanced features, 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. Here, an empty calendar equals the chance of actually getting things done.

As a manager, on the other hand, you operate on a different schedule. Formal and informal meetings make up the bulk of your day: talking to clients, analysts, sales, developers and other stakeholders.

Although not in your job description, a significant part of your job is about leading and attending meetings. Which holds true whether you're in a traditional management position or a more informal one, such as product owner, project manager and the like.

This is the Manager's Schedule, and a typical time slot is 30 or 60 minutes.

An all too common problem

Most managers are blissfully unaware of their developers' fondness for an empty calendar. Let's say you book a one-hour meeting at 10.30, requiring the whole team to be present since you want everyone's input on a feature.

From a developer standpoint, this typically results in you having to spend 45 minutes in silence before eventually getting a question that could have been answered in a short email instead.
And, being left with 30 minutes to lunch, the chances are that said developer won't even try to pick up where he left off before the meeting; he would barely get started before the next break. Maybe he has some smaller tasks lying around, but he will probably feel that mental resistance that comes with enforced context switching.

Meetings can be a real productivity killer for developers. Especially when you schedule them in the late morning or mid-afternoon. And having one of each on the same day can derail their flow completely, leaving them with a feeling of having accomplished nothing that day.

Three typical side-effects that follow are that people:

start declining meetings
block time in their calendar in advance
participate physically without being mentally present

The four-step solution

What can we do about this? Well, there are four simple steps to take.

Step 1: Eliminate

For every meeting, ask yourself: is this meeting really necessary? Maybe an email- or Slack channel discussion would be enough? If not, does it have to be a formal meeting? Could you just grab a coffee and have an informal chat instead?

Step 2: Refine

Be honest about who are really required and who are just nice to have in the room. Maybe you can rearrange the agenda, so people don't need to sit in longer than necessary? And do you really need all that time?
Also, find out if there's any prep time required for the participants. It's all too easy to assume that a person just knows stuff and that it's all in that person's head.

Step 3: Batching

What if all meetings were scheduled back-to-back? While a full day of consecutive meetings can be mentally taxing, it's way better than having a couple of them each day, with semi-productive late mornings and afternoons as a result. At least for your developers.
Discuss which days and hours are most suitable for meetings with your team and batch as much as possible.

Step 4: Establish a working agreement for meetings

Some suggestions for a meeting WoW:

Every meeting should have a clear purpose and a written agenda. Preferably communicated in good time before the meeting by the person initiating the meeting.
Avoid changing the schedule without good reason. Postponing a meeting by 30 minutes for whatever reason, just because the participating developers are free anyway, is just flippant.
Show up on time and be prepared.
Be mentally present. This means no multitasking or unnecessary fiddling with phones or computers. You are in the room for a reason, so focus and make it count.

In short: respect everybody's time.

Now, please acknowledge that the steps are numbered. Keeping everything as-is and just introduce a WoW for meetings won't increase your popularity very much.

Additional thoughts

And if you want everyone's opinion on something, make sure to moderate the meeting and give everyone equal room in the discussion. The hard truth is that many developers don't really shine in a verbal discussion, especially if there are dominant people on the team that always take over.

Another thing to keep in mind, especially if you have introduced a WoW that bans computers, is that many developers type way faster on their laptop than on paper. They might bring it to take notes, so be sensible and don't assume that they are catching up on Facebook just because they brought their computer.

Good luck with the meetings.