Meeting protocols

Posted by noamelf on August 10, 2019

Engineering teams have a few types of meetings that repeat themselves: weekly, 1:1s, design review, etc. I found that for each type of these meetings having a concrete protocol, firm recurring schedule (where applicable), meeting record, and the meeting doc shared in advance between the members have great benefits, mostly:

  • Individual expression - team members know they’ll get an appropriate stage for their ideas/complaints/feelings so they can express them to me and the other team members in a (hopefully) proactive way.
  • Higher participation - the protocol and schedule are known in advance, so members have time to prepare and articulate what they want to say.
  • Taking turns - since everyone is used to the way the meeting works, it’s possible to delegate the job of running the meetings between different team members - making it more a cooperative effort then the team lead role.
  • Visibility of decision-making process - running the team and making the decisions is not being made in the head of the team lead, but is a visible, recorded process.

Meeting protocols

Image by Manfred Steger from Pixabay

Below are my teams’ meeting protocols:

Team meetings (weekly)

Meeting preparation

Each team member is requested to prepare for the meeting:

  • Tickets grooming
    • Review last week progress and move tasks to their respective status columns.
    • Update ticket descriptions/PRs etc.
    • Break big tasks into smaller ones that require up to 2 days of effort.
  • Plans for next week - decide what you plan to work on next week and creates the appropriate tickets for it.
  • Feedback - write up stuff you want to talk about in the meeting in the meeting document.

In the meeting

  • Feedback and updates
    • Review this week content team members brought up (myself included).
    • Company/group/team updates.
  • Review tickets - we review the tickets in the done column and each team member is encouraged to talk about the work been done. From saying a few words to a full-on demo.
  • Milestones and upcoming work - see if we met the milestones we setup earlier, review the upcoming ones, and say what you want to work on.

Design reviews

  • Mission statement - what problem do we want to solve (or feature to add)? why do we need to solve it?
  • High-level overview - what are the components that compose the solution, how do they interact?
  • Drill down - depending on the project, specify how the components work internally.
  • Milestones - how is the project development broken down? what are the estimated delivery dates?
  • Risk management - what can go wrong (building on previous experience)? how can the risk be mitigated?
  • Feedback - time for the participants to offer their views.

1:1s (every 3 weeks)

  • Lookback - how the last 3 weeks have been for you?
  • Colleague feedback - is there something I (the team lead) can do better? Is there anything you want to ask from me?
  • Manager feedback - can you can do more of this and less of that?
  • Summary - any action items?

That’s what I got so far, as I create more of these I’ll add them to this list.