Anecdotally most people in software industry hates meetings, because meeting is a soul-sucking dementor. Jokes aside, I think it's fair to say that people feel meeting is taking too much time, and the process is often painful.
In this post, I'll try to provide a few rules of thumb that I believe can make meeting less painful and more efficient.
How many times you attend a meeting without a goal in mind?
Me: Dozens of them
The why is the first question you should answer before stepping into a meeting room, if you can't tell why are we
having a meeting, there is something missing in your communication process, and you should fix it ASAP.
In many cases, a few people know the goal clearly, if we proceed the meeting without communicating it to the rest of team, one or more of the following might happens.
- People realize they don't know and start asking question to figure it out.
- The rest of the team thought they know it well enough and using the wrong information to make decision.
- People who feel it's not clear and tend to follow other's opinion.
In first case, you lost time, but still can reach the goal eventually, for #2 and #3 it get worse, you will get false sense of validation/invalidation on decision as people agree (or disagree) without enough information.
A quick remedy for this problem is to simply reiterate the goal in a straightforward before meeting start. This will likely be a responsibility of meeting initiator. If you call for a meeting, you should make it clear why to have one.
This extra step only cost you a few minutes, but the benefit is huge. It's important to discover what people don't know as soon as possible (It's like catching bug in software).
A common theme in meeting is discussion, software development is largely about making decision, quite often
individuals can make decision on things they own, but sometimes a decision happens to have big implication and thus
warrant a meeting among the team or between several teams.
It is important to conduct discussion in an efficient way, which unsurprisingly are not the case for many organizations.
From my experience, one big problem in technical meeting is that people tends to open up related question before a discussion point is concluded. I believe this has to do with human's nature to discuss things that they find familiar.
For example when we are trying to reach agreement on domain model, engineer might unconciously start question about implementation, like how does things map into relational model of our favorite RDBMS.
From a programmer's perspective, it's like thinking on different level of abstractions, and ignore the details beneath it to speed up decision making.
Note that, such derail is sometime a necessary evil, sometimes high level decision depends on some very specific details on low level component, for example when deciding what latency a service should guarantee , we must consider technical feasibility to make informed decision.
To avoid this problem, we have to scope the level of details during discussion, several techniques can be used
- Assign someone to control the direction of discussion, try to resolve discussion point 1 by 1
- State explicit throughout the process (like a sport commentator)
- repeat the discussion point (preferably in question form) before start
- make sub-conclusion whenever an agreement/disagreement is reached
- make conclusion to close the discussion before proceed to next point
- Derailment is only allowed if justification is provided, eg. we need to discuss project budget first as it affect our decision of team resource distribution.
Note: The sub-conclusion can be really simple, just reiterate on every significant progress in the meeting, eg. Seems like no one thinks option B is going to work, so we are left with option A and C, let's focus A first to see if it fits our usecase
You'd be surprised how effective point #2 is when put into practice, despite it's simplicity. By explicitly stating the progress of meeting, you'll be able to grab people's attention, give the team a sense of progress by having fast feedback loop (We all love feedback loop!).
We've talked about having clear goals and limit the discussion, it's natural to think of agenda now given it will facilitate both points we've discussed.
Agenda should be derived from goal(s) of the meeting, and be arranged in a logical way that eventually leads to the goal. (this sounds recursive, bear with me).
For example, if we are trying to decide what protocol to be used for multiple microservices, the agenda might look like this
* Problem to be solve, with requirements
* Proposals
* Benefit cost analysis of each proposals
* Discussion and decisions
By trying to come out with an agenda, you will discover more details before having a meeting, things like analysis and proposal really should be prepared before the meeting, people only care about the result of the analysis, not the progress. It is easier for people to prepare before meeting with a clear agenda.
The agenda definition can be driven by meeting initiator and collaborated with the team, this allow the rest of the team to add missing points in advance.
Things like these may sounds obvious but still it was neglected quite often and we pay some price which can be avoided.
Another common problem of meeting is that it involves the wrong person, sometimes we include more people than necessary, sometimes we left out important people that can provide crucial information, sometimes both.
People are sometimes lazy to think about who to invite, and decided just invite the whole team. Such strategy might work, but it is not very efficient, people specialize for a reason, and letting people focus on their expertise is more productive.
On the other hand, it's also easy to left out important people, especially when they are in different team, and we needs to make a decision involving cross team effort.
Choosing the correct person is only possible if you have a clear understanding on what to discuss and more importantly what NOT to discussed (see #1 and #2). This rule, when executed properly, will save your organization substantial amount of time.
To summarize, a fantastic meeting usually consists
- Clear Goal
- Well defined agenda
- Close to zero derailment
- People with the right information
I hope you find this post useful. Feedbacks are welcome, feel free to drop me a message =)