Structured Chaos: Running Inclusive Developer Led Meetings
At Adwerx we have regular developer-led meetings to address issues outside of product feature work. These meetings are a space for proposing changes to code style, incorporating new engineering practices, and addressing other team-wide issues. As you can imagine, software engineers can have strong opinions about these issues, and our discussions can get rather spirited. These meetings haven’t always gone smoothly, with agendas being derailed by loud voices and interruptions, while some attendees would sit quietly wondering what life choices they made to end up in such an unproductive meeting.
I experimented with some changes to the meeting structure — implementing meeting facilitation tools to address the process challenges we were experiencing. We’ve learned some valuable lessons over time that have made the meetings more beneficial and productive for everyone attending.
Make it Predictable
One of the issues with the meeting was that no one knew what they were getting themselves into. The agenda was built at the beginning of the meeting, which allowed people to ambush the team with technically challenging topics with no time to prepare. Ideally, everyone would have an idea of what was being discussed ahead of time so they could prepare some questions or concerns in advance. This was a simple fix: I built the new meeting doc at the end of every meeting and people could add agenda items during the week. I also added a cutoff time so that no items could be added the morning of the meeting.
Additionally, the meeting format itself was unpredictable. Would I have to sit through a 40-minute debate? Would there be a live code presentation? Would anything get decided, and even if any consensus was reached, what did that mean?
The solution for this was creating a meeting charter describing how the meeting would be conducted. This included a playbook on how to run the meeting, what the options for processing agenda items are, what makes a good agenda item, and what happens to action items after the meeting. If something in the charter wasn’t working, anyone could propose an edit as an agenda item and get input and buy-in like any other engineering concern.
Empower Participants
It was important to me that all participants feel that their presence at the meetings has meaning. They are not just passive participants watching a meeting; they are decision makers and their voices matter. It was then doubly important that they didn’t have to fight in order to get that voice heard.
I use a couple of facilitation tools to achieve this:
Reaction Round: All participants in the meeting have a chance to react to the proposal that the agenda item holder brings forward. They voice their thoughts and they can bring up questions they are thinking about, but no one else can speak during the reaction or answer those questions. This is specifically about the reaction a person has to the agenda item. Another benefit is that the reactions go around the room in a predictable way, people can prepare what they are going to say and know when they will have a chance to speak.
Voting: A simple yes/no vote to get a sense for the general impression from the team. It is a fast way to see if further actions like a reaction round are needed.
Inform: A way to let the team know about a new process, tool, or something coming soon that they would like everyone to think about.
And that’s it! The general process is that the facilitator will bring up the agenda item, the agenda item holder will speak about it and what they are looking for, one of these tools will be used, and then the facilitator asks the agenda item holder to create action items.
Create Accountability
You can agree or disagree all you want in a meeting, but if nothing happens based on those conversations, what’s the point? Action items are created as outputs of agenda items and assigned to a volunteer. Then at the beginning of every meeting, all open action items are updated on or completed. Updates of ‘no progress’ are perfectly acceptable! This process keeps the projects top of mind for the action item holder. It’s useful to have a threshold for stale projects, and if no progress has been made for some period of weeks, the team can reevaluate what to do with that project (reassign, drop, keep).
Wrap it up
I hope that these guidelines help you in creating a more equitable meeting structure. I use them here at Adwerx Engineering, and they have become a core part of what makes our engineering team so effective.
