How to reduce meetings and increase developers’ productivity

It’s no secret that most developers despise meetings. 

For the most part, coding is solitary, independent work, and developers work on their own. 

Furthermore, the best code tends to surface after long periods of concentration—developers need to get in the zone to get optimal results.

Meetings, for obvious reasons, impede this mode of working. Not only do they interrupt a developer’s focus, but they also break up the periods of deep work. 

Therefore, fewer meetings equate to greater productivity. In this article, we’ll show you some tips and tricks for reducing the number of meetings and keeping your developers happy.

Have you ever been in a meeting without knowing what its actual objective was? Have you found yourself struggling to follow the topic at hand? 

These are the hallmarks of an unproductive, unclear, and agenda-less meeting.

However, with a meeting agenda, the above two scenarios won’t happen. 

The meeting’s goal should be printed in block letters, the agenda should include an indexed outline covering the entire duration of the meeting. 

In other words, agendas ensure a productive meeting. 

Just look at this graph:

The numbers speak for themselves—the longer you prepare the agenda, the higher the productivity.

Nevertheless, a survey revealed the following dispiriting figures:

This is a worrying statistic, as agendas are proven to increase meeting efficiency. So, how do you break the mold? How do you prepare a meeting agenda?

First of all, let’s look at an example to get a clearer idea of what a quality agenda looks like:

To begin with, there are the obvious details—the date and time. 

Always ensure your meeting agenda states these particulars clearly, so there’s no confusion about when the meeting’s taking place.

Secondly, assign speakers to each topic. As we can see in the image above, there’s an avatar connected to every subject, signaling who is the main point person for that subject. 

With such a structure, conversations will be more streamlined, and you’ll avoid unnecessary long pauses when deciding whose turn it is to speak. 

Instead, everyone will take ownership of the task at hand.

Furthermore, it’s not a bad idea to take this organization one step further and assign time slots for each topic. Take this old-school agenda for inspiration:

For example, if you’re starting the meeting with a general weekly overview, assign 5 minutes to that discussion. 

However, if discussing a more complex issue such as a strategy for dealing with technical debt, allocating some more time is entirely justified, as long as you don’t overdo it.

Decide on a set amount of time beforehand per that topic’s priority, and you’ll ensure you’re not spending too much (or too little) time on specific subjects. 

That way, the meeting won’t go overboard and is bound to be productive.

When scheduling meetings, take a moment to step back and assess their value. It’s frighteningly easy to revert to meetings as the default project activity when that might not always be the case. 

The easiest place to start is with your repeating calendar events. 

Weekly or daily meetings are often attended out of habit more than anything else, a sense of “that’s how we’ve always done it.” 

However, when the time comes for your Tuesday sync, take Wrike founder Andrew Filev’s advice:

Most teams have a Friday recap and a Monday check-in. Think about it—is there a need for both? 

Why not incorporate the Friday recap portion into the start of the Monday check-in and free up time for your developers? And that’s only one example. 

It’s also essential to think about the topic of the meeting. 

Although a meeting about product strategy is significant for business analysts and product owners, and you as the team lead should likely attend, do you need your entire developer team to be there? 

If it’s not a meeting about project requirements, product strategy has no impact on your team’s workload.

Pay attention to the meeting’s purpose, and shield your team from those meetings that, realistically, have nothing to do with them.

Paul Graham put it well:

In other words, even if you and your peers have to attend mandatory meetings, do your best to protect your team from having to sit in on them too.

However, that being said, there is one extremely valuable meeting that you should never skip—the one-on-one meeting. 

These meetings are invaluable for your team, as they build trust, present an opportunity to give honest feedback, and can boost team performance. 

Just consider the success Adobe had with one-on-one meetings:

Taking into account the benefits Adobe experienced with such meetings, it’s hard to ignore their value. 

The atmosphere of discretion inherent to these meetings provides the perfect opportunity to connect with your developers. 

You can discover what motivates them, what their aspirations are, and what difficulties they’re having—and there’s no denying the value of that.

Meetings are, thankfully, no longer the only form of business communication. 

Nowadays, there are countless other ways to touch base with your colleagues instead of face-to-face conversation, such as e-mails, instant messaging, and even project management software. 

Of the above, the one tool your team definitely needs is an instant messaging platform like Slack. 

With this resource, you’ll be able to communicate updates, information, and briefings without interrupting your developers’ workflow. Instead, they can simply read the message whenever it is most convenient.

Implementing dedicated channels per subject or project is also a good idea. 

For example, you could have a space for #newUI, #website-revamp, or even an #onboarding channel for new hires. 

Similarly, in the image below, you can see a #product-feedback channel:

With this channel, there’s no need to organize a meeting to ask for feedback—just use Slack instead.

However, even in those unavoidable circumstances where a meeting is necessary, there are communication tools that still prevent it from dragging on. 

Microsoft Teams has introduced a new feature where participants are alerted five minutes before the end of the meeting that, well, the meeting is almost over.

The notification looks like this:

This feature serves as a gentle nudge to slowly wrap up the meeting. It will be easier for participants to end the session on time and let everyone get on with their day.

One particular unavoidable meeting in software development—especially if you’re Agile—is the daily stand-up. 

Nonetheless, there are tools that can make this mandatory meeting significantly shorter.

LinearB is a workflow automation software that helps teams communicate clearly and transparently and therefore streamline meetings. 

One of its features is clear markers of WIP and To-Do tasks, shown below:

By checking the number of WIP and To-Do assignments and then comparing it to the number of days remaining in your iteration, you can quickly evaluate what’s likely to be finished and what isn’t. 

Furthermore, if there’s too much WIP, it’s easy to see who has the highest workload, and re-distribution should be easier. 

These components save time in the stand-up and make for a more efficient, shorter meeting.

Some developers are morning people, and some are night owls. Some feel energized after a noon meal, and some put off taking their lunch if their coding is going well. 

Everyone’s productivity peaks at different times, and it’s essential to take this into account when arranging meetings.

The Chief Technology Officer of B Generous also highlighted this:

In other words, you’d do well to investigate when your developers are the most productive and schedule meetings accordingly. 

This is easier done in smaller teams, but it’s also worth a shot with larger units.

For example, a common finding is that employees don’t feel particularly motivated in the late afternoon, as they know it’s almost time to finish working. 

It wouldn’t hurt to insert meetings then, since their coding capabilities are diving regardless.

Furthermore, organizing a meeting right after or before lunch is also practical, as your developers will already be on their break. 

You’re not introducing any new interruptions but simply prolonging the original one (lunch) they had likely already incorporated into their day.

This developer team lead explained his process for scheduling meetings on Reddit:

Take this manager’s approach as inspiration, and pinpoint moments in the day when your employees are already not at their desks, such as lunchtime or the morning stand-up. 

Then, take advantage of these instances to hold meetings around the same time.

Furthermore, there are specific periods in the general software development life cycle where meetings shouldn’t include your developers. 

A general rule of thumb is that your developers should attend meetings during the planning phase of a project to become acquainted with the requirements and construct the design.

However, later on, during the actual building and coding portion, meetings should be limited to once a day, and that one meeting should be the daily stand-up. 

This was discussed in a Quora thread:

As this user outlined, all relevant meetings should be held at the beginning of a project – that’s when all decisions should be made and priorities agreed upon. 

Any larger, additional meetings in later stages of the project should be avoided—at that point, your developers should focus only on their coding.

Not every developer will benefit from every single meeting. Some meetings just don’t concern everyone, and being forced to attend would only stall productivity. 

Therefore, consider making your meetings voluntary.

Convictional, a maker of e-commerce software, has implemented this approach. They have a single mandatory meeting once every three weeks, which the entire company attends. 

Aside from this all-hands-on-deck meeting, every other meeting is optional.

The company’s CEO explained their rationale:

With this method, each employee has almost complete control over their calendar and, consequently, their productivity. Why not imitate them? 

Keep only the one meeting mandatory, and make all others voluntary.

You could even take this one step further—allow your employees to leave irrelevant meetings. 

Although walking out of a meeting is considered rude, remaining in an unhelpful meeting remains a waste of time. 

Simply communicate to your developers that getting out of unnecessary meetings isn’t an offense. 

The practice is only considered rude because the company’s culture considers it rude. If your business begins advocating such behavior, your developers will quickly adapt.

Elon Musk himself is a fan of this approach:

As per Tesla CEO’s advice, what is ruder? Staying in an unhelpful meeting or making someone stay in an unhelpful meeting?

If you’re still unsure about this guideline for all meetings, there is one type of voluntary meeting that can do no harm to your company—the coffee chat. 

This informal, relaxed meeting is used to take a break and discuss all things non-work-related. 

However, not everyone will necessarily want to take a break then. What if a developer has finally found their zone or has just returned from another meeting?

GigSmart found a solution to this dilemma. They introduced a 24/7, continuous, and voluntary Zoom meeting called Coffee Talks. 

People can pop in and out whenever they like and will always be able to find someone willing to chat with when they want a break.

The concept is explained in more detail in this video:

With these optional relaxed meetings, your developers aren’t forced to stop working when it doesn’t benefit their productivity and always have an outlet when they need rest.

Perhaps the most surefire and most straightforward method of reducing meetings is simply introducing no meeting days—when all meetings are banned. 

By outlawing meetings on a dedicated workday, developers can rely on (and look forward to) a period with no interruptions. These days are the perfect opportunity to get quality work done.

When implementing these no meeting days, task management becomes much easier, as per this developer’s testimony:

Just as this Reddit user found it easier to allocate their time, the same is bound to happen with your developers, increasing their productivity.

Although easily implemented within your own team, your developers might have issues when colleagues from other departments try to book a meeting with them. 

Of course, ideally, the policy would be company-wide, but this won’t always be possible depending on the size of the organization. 

It’s best to begin with your team and then see if the practice can be extended further.

To avoid meeting requests from external individuals, instruct your team to simply block off the time. 

Most smart calendars allow for this feature, so your developers can be transparent about the policy.

Here’s an example:

With this method, the no meeting strategy is well-protected, and no one can schedule a meeting with your developers.

If you like this approach and want to maximize its benefits, another strategy to consider is scheduling all your meetings in one day. 

That way, four ‘no meeting’ days are automatically created!

Although this might be impossible for you in a managerial position, it’s undoubtedly achievable for your team members. 

The approach is a tad radical, but there’s no harm in trying—encourage your developers to cram their week’s worth of meetings into one day, back-to-back. 

It might seem exhausting initially, but the payoff is incredible. Imagine four days of uninterrupted work. 

The CEO of Modular Robotics took this approach, and these were his results:

The tactic allows for multiple no meeting days. Your developers will have a prolonged period to enjoy uninterrupted working.

The formula is simple—fewer meetings mean more time to focus on coding.

To begin with, when you have to host a meeting, ensure you have a clear agenda and don’t hold it during your team members’ peak periods.

When scheduling a meeting, assess its value to determine if it’s indispensable. Could you use a different communication tool to convey the same information instead?

Last but not least, try making meetings voluntary and commit to upholding a no meeting day.

Follow these tips, and the number of meetings is sure to decrease. With it, your developer’s productivity will increase.