Do you like meetings? If you are a software developer, the most likely answer is: “No, I’d rather spend hours fixing other people printers than attend a meeting!”
(This article is part of What I Have Learned As a Software Developer series.)
A meeting is a crucial part of a programmer’s job. Yet, we tend not to like it. We like to create programs. We like to refactor for-loops to map function to make it functional and we like to refactor map function to for-loops to make it run faster. While discussing stuff at a meeting is such a waste of time for us. But why?
Because we don’t understand what is going on in the meeting and how it affects us.
A Bad Meeting
In the past, a meeting in our company would start like this: you are making a tea in the company kitchen while someone taps on your shoulder saying something about a meeting about staging. You take your cup of nice hot sencha, look disgustingly at the guy making a coffee and go to a meeting room where someone is about to start a meeting:
- “So, I was thinking about using AWS for the public staging…” You take a sip of tea.
- “Why would we pay for AWS if we can use our server we bought a year ago?” Yeah, that makes sense.
- “Our servers are not powerful enough.” You noticed a butterfly flying outside.
- “We can buy more memories from our supplier.” Is there a stain on the ceiling?
- “The supplier hasn’t even supplied us with new notebooks yet.” Why do round pizzas come in square boxes?
- “Yes, because there is a shortage of…” And you’re falling asleep.
What was the meeting about? No one knows 🤷. Let’s make it better.
Does It Have to Be a Meeting?
Let’s face it. Half of the meetings could have been an e-mail. I mean, yeah, it’s nice to have a presentation about our financial results every month. But an e-mail saying we have been making the same amount of money as the last six months would be sufficient.
On the other hand: Slack has threads and you can discuss stuff there, I know. It supports GIFs. You can certainly put a lot of memes there. Snarky memes. Clever memes. Oh, you uploaded Nicolas Cage as a custom emoji? Funny. Where were we?
A meeting is a perfect tool if you want people to agree on something. Do you want to start using TypeScript instead of JavaScript? You better tell the others the consequences so they understand it. Otherwise, a colleague comes to you complaining you used TypeScript in an existing project and he thought you would use it in a completely new project.
How to Make Meetings Great Again
Define a Goal
Define a goal of the meeting and write it down so everyone can see it all the time. This is the most important thing to do. Agree on the goal and write it down. On the whiteboard, on the flip chart or use your blood to write it on the wall. It must be somewhere! Once there is a goal that you can see all the time it’s far easier to stay on track.
What was the goal of the meeting I described in the previous chapter? Something like “Find a way how can our customers test our new features”.
Define a Problem
We usually meet if we want to change something because there is a problem. Clearly define a problem and tell everyone the current state of things:
“Currently, our web applications run in two environments. The production environment which our real-life customers use and the staging environment which our developers use for testing features. As of now, we also want our customers to test the new features. Unfortunately, the staging environment is accessible on the private network only, you need to have VPN configured to access it and our customers can’t have it for security reasons. We propose making the staging environment publicly accessible to anyone.”
It states the current state (“the staging environment is not accessible without VPN”), it states the problem (“our customers cannot test new features on the staging environment”) and it proposes a solution (“let’s make the staging environment public”).
Talk
Now you are ready to discuss. If someone brings up the story about the supplier not being able to supply us notebooks, you can point out this is off topic as the goal is written on the white table.
- “The supplier hasn’t even supplied us with new notebooks yet.”
- “Yes, that is a problem, David. Can you schedule another meeting about it, please? We’re discussing testing features by our customers now, can we get back to it?”
See how easy was it? Back to our topic:
“Do you really need to make the staging environment publicly available? Can’t the customer test the feature on the production environment? The feature can be hidden by default and you can enable it just for a specific customer. Would it be a viable solution?”
Such twist! We found another solution that does not require making the staging environment public. Yay!
Write Everything Down
Write down everything important. Did someone suggest releasing a feature to production? Ok, write it down. Someone mentioned it’s not safe because other people could dig into the code and figure out there is a new feature coming? Write it down! The rest of the people do not fear it? Write it down! If there is a sentence on the board
“We don’t care if someone finds out we are silently testing a new feature in the browser”
it’s hard to misinterpret it. Everyone in the room understands it and you’re free to release the hidden feature to production and test it there.
Summarize it
At the end of the meeting make a summary. It’s good if someone who wasn’t talking all the time does it.
“We wanted to invite our customers to test our new features. First, we thought we make the staging environment publicly available but we found a better way. We will release all the new features directly to the production environment but we will make them hidden by default and we make them visible to a few customers only. We don’t care if someone else discovers we are testing the features.”
If you don’t summarize it, someone will misunderstand the result of the meeting. The summarization is like a checksum. And do not ever ask a question “Is everything clear?” If you’re lucky, someone answers “No, it’s not.” If you’re not lucky, they say “Yes, it’s clear.” But how can you know everyone is on the same page? Maybe, Lucas thinks we should test the features in production, and next time he releases it to production but he does not hide it to others, he makes it available for everyone!
Rainbows! Rainbows Everywhere!
I made it sound like it’s a piece of cake. In reality, making a good meeting is really hard. It’s not something you can do once you read an article such as this one. Practice. Invest your time to improve your moderating skills. There are many techniques to know. Do not expect someone else moderates it. Do not say “it’s someone else’s job”. Instead of reading an article “converting whole functions to unreadable one-liners”, take a lesson about moderating meetings. It’s worth it. You won’t make a difference by learning all the theory behind monads. You are going to make a difference by organizing a good meeting.
The least you can do is to ask two questions:
- “Hi, what is the goal of this meeting?” At the beginning of every meeting.
- “Can someone summarize it for me, please?” At the end of the meeting.
Even these two questions will help tremendously. I know it because I did the same thing.
Good luck with your next meeting!
(Pictures are from unsplash.com)