DEV Community 👩‍💻👨‍💻

Warren Parad
Warren Parad

Posted on • Originally published at blog.teaminator.io on

The Required team meetings

The required team meetings

There is no shortage of advice out there on knowing when to call a meeting. And in the remote-first world async communication is now the norm, every meeting we have is up for review. There’s already come great advice on when to call a meeting, so let’s dive into what this actually looks like in practice.

It’s critical to note that any meeting can be effective if run correctly, and running any of these poorly will result in a huge waste of time. If run correctly, these are a great list of meetings to have. That being said, while there can be other meetings, usually having them is an indication that there is likely a critical fault somewhere else. You can’t fix a problem with clarity or transparency by applying the patch of sometimes sharing information late.

Categories of meetings

The discussion here places importance on a few different categories of meetings. I’ll go into details for each of these categories and share the importance of each one. Further meetings not listed here are great ones to challenge their usefulness.

Team meetings

Let start with team meetings. I’m assuming you are working on a team. However this isn’t something that should be glossed over. Many groups of people are called a team, even though there isn’t anything about them that is team oriented. It’s important to realize first if a group of people is a team. That means they share direction, purpose, values, identity, and responsibility. And to achieve that, they share alignment, meaning-meeting frequently is required at the team level. The necessary meetings for the team are:

Weekly team sync (~1 hour)

The weekly sync is where you and your team come together to create and affirm alignment. What are we working, are the priorities still the priorities, are there any changes to what the work is, or new things to consider. Using this time effectively means having the four quadrants answered:

  • What are the top work priorities — These priorities must align to your OKRs or business objectives
  • Are there service support issues — What are, if any, urgent production related issues. Are there reliability metrics trending downwards?
  • The 6 week initiatives — Are these still the same, they give clarity to what happens after the current work
  • Team health — How is the team doing, are there any red flags, callouts, problems that should be immediately discussed
  • [Bonus] — Are there any initiatives that individual team members should volunteer for and take ownership over. Usually there aren’t any of these, but one may come up time to time. Such as fixing a huge portion of documentation or training another team.

I usually recommend starting with service reliability, then navigating to team health, then 6 week alignment, and last to suggesting and voting on priorities. Everyone can suggest, and then use some sort of dot voting to pick only the top One or Two things. The Team Lead has the deciding vote. Everything else should Not be worked on. If the team didn’t prioritize it, then it doesn’t get worked on.

The point of this again is alignment. Team Health, then reliability, then current work priorities is the order. Never start new work when the team or existing services can’t support maintenance. This builds up more fires that need to be fought. You’ll notice here that talk about issues or tickets is strictly not part of this meetings. And with good reason. If the team is aligned on the work, then anyone can prioritize tickets into your “prioritized” or “ready to be worked on” column on your kanban board. In most cases the right tickets are already there.

Prioritization can done by the Team Lead or by another member on the team. You don’t need to spend time hashing out what a ticket means, that’s a separate meeting. If a ticket isn’t already clear when you get to this meeting, then it isn’t ready to be worked on, and that means shouldn’t be discussed here. If you can’t walk away from the meeting knowing which tickets need to be created or prioritized, improve the moderation of the meeting.

If you run out of work during the week, hold another meeting, don’t ever create more initiatives to avoid another meeting, that destroys alignment and creates confusion on priorities.

This structure closely matches the one used in Radical Focus, the premier book on creating and utilizing OKRs.

Bragging Session (~1 hour per month)

Our CEO created this concept to help everyone identify personal wins. Talking and discussing about what you’ve done great is a fantastic way for you and everyone to realize all the hard work that has been put in. The format is that once a month one person will recount all the great work they’ve done. We recommend taking credit for anything and everything. It doesn’t matter if you had help, it doesn’t matter if you weren’t the key player. You contributed to the success, time to talk about it.

Retrospective (~1 hour per month)

Retrospectives are the way to review everything related to your work. Everything is up for review. Discuss what works great that you want to continue and what isn’t working so you can focus on changing it. If the same topic comes up more than one or two retros in a row, it’s a sign you have too many retrospectives.

In person Standups (~1 hour per week)

Standups or Dailies is the practice of sharing the One most critical or important piece of information with the rest of the team. It isn’t a discussion board, and it never is about mentioning tickets. If you are mentioning tickets, you aren’t getting the value out of your standups. Also standups take two forms-async and in person (i.e. face-to-face over the camera). Twice a week for a face-to-face for 30 minutes each is a great opportunity to potentially align, discuss the need to dive deeper into other topics, or bring up something critical. You really want to limit this to one topic per person. If you feel like you have a lot of things, try to figure out what’s the most important for the team, are you blocked?

Async standups

The other three-to-five days of the week, have a daily async standup. Where team members are encouraged to fill out or engage with async written context from other team members. Again, these have the same importance and expectations as in-person standups, but are done async. Of course we recommend our favorite Slack standup app Standup & Prosper which we love because it is totally free and has everything we could ever need. The caveat here is, if you have team members with active times more ~6 hours apart. Your best bet is to have separate teams, and therefore separating the timezones. If there is overhead to collaboration it won’t happen effectively, and you’ll optimize for the wrong solutions.

[Optional] Innovation Day (~8 hours per week / month)

Every couple of months I recommend a full day (~8 hours) dedicated to working on anything that isn’t a priority. Being mindful that work can’t increase the load on the rest of team. Work that generates Pull Requests for outside of innovation time is a clear distraction. In general, leaving 20% of your time as free capacity dedicated to innovation is the right amount. However, not everyone innovates spontaneously. Maybe you already do something different every day, but if you are a person that needs scheduled time, having a single day can be the right approach for you and your team. If used effectively, this time may be indistinguishable from the work that your team is normally doing. But if you aren’t finding opportunities to innovate, improve your tech debt, or fix that really bad but just needed to be fixed bug, this meeting could be for your team.

Career and Team growth meetings

Direct report meetings (~3 hours per week)

Using Dunbar’s number, we know that the maximum number of highly trusted relationships we can have in a given context is ~5. So as a team lead that’s 5 hours with direct reports, and 1 hour with your career manager, making this 3 hours per week. There are lots of details out there on how to hold effective career meetings, the point of them, and strategies for what to focus on. The overall goal is for you to become a better version of yourself. Frequently, that means figuring out what you want to do and how you want to change in the next year+ timeframe.

Skip level meeting (1 hour per month / ~2 hours a week)

As an engineering director or Lead of Leads, you manage the team leads. With Dunbar’s number again, you likely have ~5 teams. While you can support up to 15, you’ll end up with way too many meetings. In the case you have a 5 teams, each with 5 people that’s 20 skip level meetings. Quarterly is usually a great cadence for this, remember this isn’t the only opportunity to get feedback, but it is the one meeting you are explicitly making time just for those that you lead.

360 Feedback (~1 hour per month)

Every month on a rotating basis, one team member gets the opportunity to hear back from their team about their successes and opportunities for improvement. A pattern that works is everyone keeps track of feedback that they should have already shared, and then during the meeting, the team points out topics in the form of Stop, Start, Continue. By grouping these together in a joint session we can see what everyone in the team cares about, and where someone has the opportunity to improve.

Lead-to-Lead meetings (~1 hour per month)

In the case you are Chief in Charge, meeting and driving alignment between yourself and other teams is critical for the organization and company success. Feedback on your own opportunities for growth as well as opportunities for your team to improve should be on your radar. In some cases, these may be direct mentorship, from inside or outside your org/company, in other cases they can be direct alignment to smooth over issues cross-team/cross-org. These apply in orgs at larger scales, for example if there are multiple 5-team orgs in your company/division.

Organization/company wide alignment meetings

There are of course organization wide or company wide meetings that are useful, while time is flexible on these, what’s always important is that in every meeting there should be a clear agenda as well as value for every member in attendance. If there is someone that doesn’t get any value by what is being shared, then the meeting doesn’t make sense. So we should always be concrete with the value participants will get. In this regard, all these meetings are 100% optional. If you come-you participate, if you don’t participate, you don’t get to have an opinion later.

Organization Direction (~1 hour per month)

After the team leads have completed designing the business initiatives (or OKRs if you are using that framework) and they have been signed off by the Engineering Director (who is a proxy for Product, Business, and Technology strategies), then they have to be published and announced. This happens at most four times a year, and during the times when this isn’t happening, review of the objectives and their results is the critical factor here. Are we on track, are we still doing the right thing? Do our OKRs still make sense, or is there is a mistake. This is the opportunity to question the OKRs and identify any problems with the current approach. This meeting should not present new information, because everything should already have been shared, but should seek for feedback and potential discussion on improvements. Think of this as the planning and/or retro at the organization level.

Book club or guild (~1 hour per week)

Guilds are a collection of people that meet on a weekly or bi-weekly cadence to improve their understanding of a topic. They don’t come together to solve a problem, they come together to learn. Anyone can join any guild or start one. Common guilds that I have started in my past include Quality , Deployment Automation , Lean software development , Building and using agile , Customer Support strategies , but guilds can be about almost anything. They don’t have a leader, it’s just a group of people deciding to meet.

Lightning Talks (~1 hour per month)

Dedicated time set aside for short 5–20 minute presentations on any topic. They are a great opportunity for cross-org collaboration and knowledge sharing. It doesn’t matter what the topic is, but remember that the goal is value for your audience. Don’t just talk about yourself for twenty minutes :).

Ad-hoc meetings

Ad-hoc meetings are everything that is not recurring, and every one of these should have a strict agenda, a plan on how to have the meeting, and a concrete goal of the meeting. The outcome of every meeting doesn’t need to be action, but it does need to have a followup. If the goal of the meeting is to make a decision, then the decision needs to happen, and time allocated for it. Don’t schedule a second meeting.

  • Establishing a team identity
  • Working through a pull request review real-time
  • Designing a new architecture
  • Identifying new work from support requests, customer feedback, or technical investigation
  • Discuss how to solve a customer problem or new feature and creating the necessary tickets
  • Creating/hashing out/reviewing an internal RFC
  • Establishing new OKRs for the OKR cycle
  • Interviewing and handling candidate debriefs

Almost anything is an ad-hoc meeting, focus squarely on the value, and targeted agenda. These are just examples above. Anything that isn’t listed in the recurring meetings above, shouldn’t be happening on a recurring schedule. There are of course rare exceptions when two teams are working very closely together, but these are rare, and time-bound for instance, getting customer feedback from one large customer on a monthly basis. Time bound this to 6 months. For something longer and ongoing, you’ll want to discuss concrete ways to more effectively get that feedback, there isn’t enough time to meet with everyone all the time.

Meetings we shouldn’t have

There is also great advice out there on indicators that a meeting is problematic. There’s the disfunction of the types of Meeting Creatures present, but also the question if the meeting itself is the right one. We know we shouldn’t have these types of meetings:

  • One person talking most of the time — This is a broadcast, if feedback isn’t an important aspect, this doesn’t need to be real time. Send out an update before hand, and then meet to discuss.
  • Meetings longer than an hour — The human attention span doesn’t last that long, after getting about ~30 minutes of new information, we need to process it. If we are spending more than this time, we aren’t getting to the processing step.
  • Meetings back to back — Same goes for the above, there has to be processing time built in. Take a second, sit down, and process the information before going to the next one. Having some back to back meetings during the day is unavoidable, but if you get done with all your meetings and you only have 1 hour of time remaining to get the processing in, you’re in too many meetings.
  • Recurring meetings that always get cancelled
  • Recurring meetings that people don’t know why they are there — Everyone who came should know why, if people are going to a meeting because they were in invited, you may have a toxic culture. Everyone should come to a meeting because they either have relevant value to provide, for instance decisions that affect them. If someone can’t provide input and get feedback, then they can read or listen to the meeting at 2x speed after it is done.
  • Meetings where people bring laptops, or performing a second activity — If people aren’t paying attention, or don’t think they have anything to gain, this is a sign that the meeting is a bad one.
  • The meetings mentioned above at higher frequencies — For instance it is relatively common to have a retro every week or every other week. Anything more frequent than once every month, means an extra 1 hour per person in the team spent on potentially rehashing already identified problems.

Conclusion

Take a hard look at your current meetings you have to see if there is an opportunity to shuffling them up. If you have multiple backlog grooming sessions, you might have identified a new failure mode that could be addressed. In some cases, people secretly declare meeting bankruptcy and stop going to anything. This also isn’t a great pattern. The first step to change is identifying that you and your team are in control of the meetings you take and how you interact and collaborate with outside experts, like product managers, leadership coaches, vendor account managers, etc… Once the team settles on a shared understanding, broadcast that, get feedback, and adjust.

Originally published at https://blog.teaminator.io.


Top comments (0)

Want to rep DEV and be comfy at the same time?

Check out our classic DEV shirt — available in multiple colors.