How to make developers look forward to your next meeting

Bad meeting

(There is a free checklist at the end you can use for your next meeting)

“The meetings where we have to sit and listen for an hour and then have to give a little input at the end.. Oh boy! 🤯”

  • Me and countless people on Reddit

You have all been there.

The meeting you leave thinking “That’s an hour of my life I am never getting back”.

It’s pretty easy to know when you are in one

  • The meetings have no clear agenda
  • People continuously rehash stuff you already agreed on
  • At the end of the meeting, you know that next week you are going to have to sit through another one and you just can’t bare to do it.

Here’s a common example

---------------------
Subject: Let's talk about DynamoDB
Duration: 2 hours
Required: A lot of people
When: ASAP
-------------------
<no more information>

When I get one of these invitations a few things immediately pop into my head

  • What are they after?
  • How can I contribute?
  • Why am I even needed in this meeting?
  • Is the context switching going to kill the rest of my days productivity?

You know why you hate them?

You hate them because they are all about the person calling for the meeting! They didn’t bother to take your situation into account.

Yes, yes, you’re probably nodding along because you have been in meetings like this.

But you know…

You probably sent out a meeting invitation like this! You probably wasted someone else’s time! You probably ended a meeting with… crickets..

I have done it numerous times.

The silence at the end of the meeting says it all: No one got any value from being in this meeting.

But there is a simple trick to fix this.

To get developers to want to come to your meeting, you need to make it about THEM!

Let me show you how…

Lets rewrite the same meeting invitation in a way that makes people WANT to click “accept”

Subject: DynamoDB or RDS as a database for our new service
Duration: 30 minutes
Required: James, Shannon, Amir
When: In a day or two
-------------------------------
How you can help me:
I am struggling to choose between two different databases for our new service. We are looking at DynamoDB (a NoSQL database) and RDS (a traditional SQL database) as candidates. The main problem we are facing is one of performance and throughput.

Here is what I hope to get out of this meeting
- Understand which database would be a good fit for our context?
- What the next step would be to do the first version.

To better prepare, have a look at these resources that I have read through
- https://aws.amazon.com/dynamodb/
- https://aws.amazon.com/rds/
- https://tutorialsdojo.com/amazon-rds-vs-dynamodb

Why I specifically invited you
- James: I heard you have had experience in DynamoDB from a previous job
- Shannon: You have been here a long time and know why we have previously chosen not to go with a NoSQL database
- Amir: You can tell me how this might impact the performance of the cluster

What is good about the second meeting invitation?

1. You clearly state that you are in need of some help

People are a helpful bunch. Especially developers. Don’t abuse this.

2. You lead with what you hope to get out of the meeting

A meeting without an outcome is a meeting that didn’t need to happen in the first place.

When you don’t start with what you want, you will get exactly what you asked for: nothing.

Putting the goal in mind is the best way to give people a clear focus on the topic you want to discuss.

3. You allow them to do a little research before

In order to come well prepared to the meeting, help them by giving them access to material that is relevant to the meeting.

If you are sharing long articles, make sure to point out which sections are more important so they don’t need to waste time on the wrong part.

4. You call people out by name and add a little context to why you need them

There are three main benefits for doing this

  • When you tell people why they are important, they feel appreciated and are more likely to contribute. They know what’s expected from them in this particular meeting.
  • Other people in the meeting can get a sense of what the meeting might look like and prepare accordingly.
  • If someone can’t make it, they can easily replace themselves with someone with similar competence.
  • If you can’t come up with a reason for someone to be in a meeting, they probably shouldn’t be invited in the first place.

5. You give them time to prepare

If you want people to come prepared to the meeting, you need to give them time to read up and do their research.

But you need to include the time it takes for them to finish whatever important thing they are working on now. Which is not the same as the time it takes to read through an article.

When the meeting start

1. Restate your goal for the meeting

So that everyone are on the same page.

2. Jump straight into the discussion

You have to assume that people have done a little bit of research before the meeting. You put effort into making it easy for them to do that, right?

If they haven’t, they shouldn’t really be in the meeting.

So cut straight to the point.

3. Revisit the goal during the meeting

If you find yourself straying from the topic, write down what you were talking about.

Then get back to the goal.

For your next meeting, use this checklist before you hit “send”

Did you remember to

  • Lead with an outcome?
  • Be clear that you need help?
  • Give them time to prepare?
  • Give them the information they need?
  • Let people know how they specifically can help?

The more you do this, the more developers will enjoy your meetings.

Which makes life easier for you!