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.
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.