After listening to the last episode of the DevDiscuss podcast with @ben, @jess, and Andy Goodman, I decided to make a post talking about what I've learned.
By the way, if you want to listen to the full episode, follow this link.
Prepare your agenda
Having a well-prepared agenda is the single best predictor of a successful meeting. The agenda should cover all the things that have to be covered to prepare people to be effective. Besides, it would help if you didn't think about the agenda as a simple list of topics but as a strategic plan for the next hour of your life.
Here are a few tips for a well-prepared agenda:
- Define the objective of the meeting.
- Send invitations to all the participants 24 to 48 hours in advance to discuss who should be there and who doesn't.
- Make a list of topics that should be handled during the meeting.
- For each topic on the list, you may consider including:
- A notation to explain how the topic will be handled. You can use three kinds of interactions:
- Information: Meaning you'll inform about something.
- Discuss: Meaning that youβre going to bring up a topic here, and you'll ask for feedback.
- Action: Meaning that this item will lead to an action (making a decision)
- The name of the person who'll handle or present that topic.
- The estimated duration for the item
- A notation to explain how the topic will be handled. You can use three kinds of interactions:
- You may include a "WW, DW, BW" (Who will do what by when) section at the end of the agenda. There you'll specify the responsible, the responsibility, and the deadline for each task.
Avoid voting; try "Gradients of Agreement."
The thing about voting to make a decision is that there'll always be winners and losers. If you lose, you'll feel like you didn't get what you wanted.
That's why you could consider using a technique called "Gradients of Agreement" to see where everyone is without making a decision. With this technique, each participant can choose between:
- Endorse
- Endorse with reservations
- Abstain
- Disagree, but don't block
- Veto
β οΈ
If you're faced with ambiguous support, meaning the participants are all over the scale in response to a decision, it could be a sign that the problem was poorly defined.
π
If you're faced with meager support, meaning that although some team members are clustered towards endorsement, others are clustered in the low part of the scale (disagree or veto), you may consider slowing down and search for better ideas.
If you want to dig deeper into Gradients of Agreement, check out the following link
Think about the people
There are some basic rules as to what people expect from a meeting:
- They want their time to be used constructively and efficiently.
- They want to know what do they need to do to come prepared.
- They want to be clear about what do you expect from them after the meeting as a follow-up.
Keep it short
Even though there are certain types of meetings that could last for hours, most of the time it's really hard to keep everyone's attention for more than 1 hour. This is especially true for online meetings.
Try to keep your meetings under 1 hour so everyone can contribute in the best possible way.
Listen to understand and don't speak just to be heard.
As a participant of the meeting, try to be a good listener:
- Listen with the intent to understand, not to respond.
- Try to speak up only if you have something to contribute.
- Avoid speaking just to be heard or to leave your mark on the table.
Final thoughts
As a software developer, I attended thousands of meetings during the last ten years. I witnessed awful discussions and productive conversations.
I've met with people that like to use meetings as an excuse to take a break and with people that only call a meeting after an exhaustive preparation.
My experience tells me that meetings can be a game-changer tool if they're used properly. It's up to each organization to follow validated methods and make a clear and complete plan for each meeting to take full advantage of it.
Top comments (4)
Excellent topic for a post!
Thanks Michael!
Great stuff in here. This is one of the stuff that we have to improve on besides our code.
Totally agree! At least for me, it is easy to learn a new technical skill. But when it comes to soft skills like these, it's a whole different thing.