How to organize a productive developer meeting

Have you ever attended a meeting that lasted over an hour?  

Have you taken part without knowing why you were invited? 

Have you ever participated despite the meeting having nothing to do with your work?

If you answered yes to any of the above questions, you’ve had the bad luck of being invited to unproductive meetings, and you know first-hand how draining they can be.

We want to ensure that the same doesn’t accidentally happen to your developers. 

Read on for some tips and tricks to ensure your developers’ meetings are the most productive they can be.

Last-minute meetings are rarely effective for anyone, including your developers. 

Without adequate time to prepare for a meeting, participants won’t have time to meditate on a topic. This, in turn, impairs their problem-solving abilities.

David Rock has also commented on this. He described what happens when employees feel blindsided, which is often the case with no time to prepare for a meeting:

In other words, your developers will be of little help in these rushed, frantic meetings and likely won’t have anything to contribute.

These situations are precisely what you want to avoid. To do so, the easiest method would be to distribute a meeting agenda to your developers before the meeting. 

That way, they’ll have detailed insight into the discussion topics and can prepare their questions and comments.

If you’re using Google Calendar, you’re in luck! 

The app has introduced a workflow that automatically creates an agenda document in Google Docs and then attaches it to Google Calendar meetings.

You can see the feature in action here:

The agenda document is located in the meeting event, making it easily accessible to all attendees—with it, your developers will have no trouble preparing for the meeting.

To complement this approach, we also suggest introducing guidelines on an organizational level. Take a look at the following framework:

This structure divides the week into free, focus, and buffer days.

Free days are those when developers can spend entirely without worrying about the workplace, such as the weekend.

Conversely, focus days are reserved for deep work that requires intense concentration, such as coding.

Buffer days are centered around shallow work, like responding to emails, file organization, etc. You could also easily include meetings in this category.

As such, it wouldn’t be a bad idea to divide your team’s schedule into focus days and buffer days, with buffer days being the only allowed time slot for meetings. 

Choose two dedicated days of the week as buffer days. 

With this structure, your developers will naturally develop meeting preparation habits. 

For example, knowing that meetings are always on Tuesday and Thursday will naturally inspire them to prepare on the days before (Monday and Wednesday).

If you aren’t sure how to begin the meeting, you can’t go wrong with explaining the meeting’s objective. 

After all, you’ve gathered your developers for a purpose; so you’d do well to clarify that purpose.

It’s perhaps easiest to determine your meeting’s objective by first defining the type of meeting. Take a look at the graph below—it outlines the three most common meeting types.

Think about these three possibilities and what you want to achieve in the meeting. Are you providing information, asking for opinions, or reviewing a situation? 

Depending on your answer, you’ll have your meeting type, and from there, it’s easy to establish an objective.

For example, let’s say that your meeting is an informative one. Here’s an example of an informative meeting objective:

With this clear objective, everyone at the meeting will know precisely why you’re meeting in the first place and can easily contribute to the discussion. 

It’s much easier to participate when you know what the overarching goal is.

If you’ve prepared a meeting agenda (ideally, you would have one), print the meeting objective in big block letters at the top of the page. 

This statement is your homing beacon—what you and the meeting participants are working towards.

If you can’t construct an agenda, write the objective on a whiteboard. It will help the meeting attendees to have a constant visual reminder.

These printed statements are instrumental in case the meeting goes off-topic. 

Continuing from our previous example, it’s entirely possible that the kick-off meeting derails into feature particularities and detailed discussions on possible code architecture.

If that does happen, you’ll have to steer the conversation back on track. A written reminder prompts you to redirect the debate towards its original objective.

Leadership consultant Sally Helgesen also addressed the issue, advising:

Whatever setbacks may crop up, do your best to arrange dealing with them for a later time and always focus on the meeting’s overarching objective.

Not every meeting will require your entire team. If you’re meeting with marketing to explain your software’s latest feature, you’ll only need the principal architects. 

If you’re seeing the designers in order to discuss the new interface, one senior frontend and one senior backend developer should do.

Take a look at this developer’s testimony:

Just as the Sales team’s new contracts don’t mean much to this developer, rarely will any of your Sales meetings require your developers.

Your employees were hired to code, which requires extensive focus and concentration. Meetings break this flow state and are inherently counterproductive to coding. 

Therefore, if you’re going to yank them out of their zone, it should be for a good reason.

Harvard Business Reviews has discussed this topic, offering the following advice:

When selecting the meeting participants, run through the checklist offered above. 

For example, who will be directly affected by the meeting’s result? Why should your Android developers be present if the meeting is about Apple’s newest update?

Who has the most knowledge about the topic? Do you need to invite your three newest hires if the meeting pertains to the company’s very first software?

Who will be a decision maker? If discussing a product roadmap, do any of your developers need to be there? Couldn’t you just distill the conclusions to them? 

Ultimately, your aim when organizing a productive meeting is to make it as small as possible.

In fact, the technical giant Dropbox recommends a maximum of five members for specific meetings. Take a look at their guidelines:

This mantra was implemented after the company’s infamous Armeetingeddon: in 2013, the business deleted all recurring meetings from all their employees’ calendars. 

This radical move came about after countless complaints of too-long, too-frequent, and too-crowded meetings.

Revamping the recurring meetings was the easiest place to begin, as these meetings are often held out of tradition instead of actual need.

Take a page out of Dropbox’s book and closely consider your team’s recurring meetings. Are they really necessary? Do all of your developers need to attend? 

Talk to your team members, see how they feel, and ensure you’re not inviting your employees to recurring meetings for no reason.

It’s almost impossible to freeball a meeting. Meetings are complex and detailed discussions that often determine a company’s direction and business decisions. 

Given their importance and intricacy, it would be unproductive to improvise one.

To prevent this, stick to a meeting structure. 

An agenda is your best friend for these situations. It will detail your meeting’s length, date and time, participants, and, most importantly, talking points.

With a meeting agenda, you’ll have a clear overview of everything that needs to be discussed, and there’s much less chance of going off-track or forgetting an issue.

Several online resources can help you devise your first agenda if you’re unsure how. Below is an example agenda for a weekly developer meeting:

This template and countless others are offered on Fellow and several other websites. 

It’s not a bad idea to start with these companies’ agenda suggestions and then customize the templates as they best fit your needs.

However, although this model is designed for a weekly recurring meeting, you’d do well to still amend it when necessary. 

As mentioned previously, recurring meetings are often held out of habit, not because of an actual need.

With that in mind, don’t shoebox every weekly meeting into the same structure if that structure is no longer applicable. 

Although weekly check-ins can be helpful, they must be tailored to the team’s current situation.

Or, in the words of Josh Sawyer:

It might sound counterintuitive, but you might not want to rehash the same structure for every weekly meeting. 

Each phase of the software development lifecycle has different requirements and might need a different approach.

Whatever you do, however, ensure that your agenda is time-boxed. In other words, decide and indicate beforehand how much each time each topic is allotted. 

This helps prevent the conversation from being way led or needlessly prolonged.

Just remember Parkinson’s famous law:

If you haven’t specified how long you want to spend on the technical debt or updating the documentation, those conversations can spiral indefinitely. 

To prevent that, assign specific time restrictions per talking point, and your meeting will be much more productive.

Large meetings can be a lot of work. There are simply too many things to keep track of—ground rules, the agenda’s structure, ensuring everyone has a chance to speak, etc. 

In such situations, it’s well worth appointing a meeting facilitator—their role is to keep all of that under control.

A meeting facilitator can either be you, the team lead and likely agenda-creator, or another team member. 

If the meeting is complex, someone else facilitating would be a great help, as you’ll probably have to participate in the conversation actively.

Ideally, this position would go towards a developer who’s proficient at coordination and time management. 

Furthermore, it’d be wise to choose someone confident, with strong communication skills.

One Reddit user described their developers and their reliance on the SM (Scrum Master):

When presented with these two profiles, aim for the former—the type who doesn’t balk at walking over to the stakeholders’ desks. 

Those are the soft skills needed for a meeting facilitator.

When choosing your meeting facilitator, you must explain their task to them. A facilitator isn’t there to make decisions and participate in the conversation. 

They are there to ensure a smooth discussion for everyone else involved. 

Consider the following Julie Zhuo quote:

This analogy applies to the meeting facilitator role well. 

Their objective isn’t to overrule conversations and have the last word. 

Instead, you need to explain to your team member that their main task is to create a productive meeting environment, to dictate the conversation, not the content.

If none of your developers are up to the task, and you’re unsure of your own expertise, you can also try temporarily bringing in an Agile coach. 

An expert in all things Agile (nowadays the most popular developer methodology), this advisor will best take on the facilitation role and teach you some tips and tricks.

For example, take a look at this service:

With these coaches, you and your team can easily learn facilitation techniques that are sure to increase the meetings’ productivity.

No meeting is an island. 

You hardly want your meetings to turn into solitary monologues. 

Instead, the ideal situation is a two-way discussion, with all your developers actively participating in the meeting. In other words, you’ll have to ask for input from your developers.

This philosophy is even a cornerstone of The Agile Manifesto, as one of the movement’s principal adages states:

Per the manifesto, the relations between employees take precedence over traditional processes. Collaboration and communication are most important.

When asking for input, ensure you’re asking closed, specific inquiries, and avoid general questions.

Imagine someone asking you: “What are your thoughts?” 

This is such a broad, sweeping question that could be concerning so many elements that it’s difficult to articulate any definite answer. There are simply too many possible answers.

Now imagine you’re asked: “Do you receive the support you need from the designers?” or “What factors slow down your workflow?” 

It’s much easier to reply to these pointed inquiries simply because the scope of reference is much smaller. And you’re still receiving valuable feedback.

When asking for input, ensure you’re doing more than just asking—you also have to listen. 

Lara Hogan illustrated this in more detail, explaining what not to do after asking a question:

In other words, after asking a question, direct all your attention to the answer. 

Let go of any preconceptions, and don’t formulate your reply until your employee finishes their train of thought. 

Even if there is silence while you articulate your response, this is still preferred to forecasting your developer’s response while they’re talking.

Another excellent, more interactive method for incorporating your developers’ input is for all of you to take notes in the same document. 

For example, Google Docs is a superb platform for this, as it essentially updates in real time. 

While in a meeting, open up a blank document and simply have your developers record all their thoughts as the discussion ebbs and flows.

Here’s the collaborative editing in action:

With this feature, your team members can quickly give their opinion in an easily accessible location, and you’ll have no problem discovering and referring back to their feedback. 

If poorly organized, meetings can be a frustrating, exhausting experience. However, with the right amount of planning, they can be highly productive for your developers.

Ensure your employees have time to prepare, and only invite indispensable individuals—don’t force anyone to be there.

At the start of the meeting, establish the meeting objective, and then stick to your structure throughout.

You’d also do well to appoint a meeting facilitator (for better control of the meeting’s flow), and always remember to ask your developers for input.

Follow these tips, and you have a foolproof recipe for a productive and successful meeting!