Turn Engineering Meetings into Reviews

You're in the middle of a productive work session when a new meeting invite pops up in your inbox. If your immediate reaction is a groan rather than a cheer, you're not alone. But here's the thing: it doesn't have to be this way. The problem isn't with meetings themselves, but with how we approach them.

Why traditional meetings suck and drain your soul away

Too often, meetings end up being nothing more than expensive status updates or discussions that could've been handled asynchronously.

Meetings fail us when they lack clear outcomes, the right stakeholders, and the necessary data to drive meaningful decisions. Instead of tackling the heart of the matter, they dance around the periphery.

And when these ineffective meetings are held on a recurring basis, they become an institutionalized time sink.

Good meetings are like code reviews

But all hope is not lost. Having identified what makes a bad meeting makes it easy to understand how we can improve.

A well-designed meeting should:

• Involve the right stakeholders at the right times
• Have clear outcomes and highlight visibility into past outcomes to understand if real progress is being made
• Have pre-work done to collect and analyze the “right” data for the meeting so conversations and decisions can be data informed
• Have status out of the way and pre-work to analyze the problems so the meeting can focus on the real problems, not status
• Involve the right stakeholders in a collaborative process to drive to the right analysis and focus

Sound familiar? It turns out the attributes of a good meeting are just like those of a successful code review.

Turn your meetings into reviews

To turn your meetings into effective reviews, follow these steps:

Invest in collaborative pre-work

First, identify the data you need to make your meeting data-driven. It’s key that this data is at the right level for your meeting.

For example, if you are doing a sprint review, then you'd want pull request data. On the other hand, if you are doing a check-in on all of Engineering, then you'd be more interested in resource allocations and engineering alignment to business goals. These are two different sets of data for two different reviews.

Include the right mix of quantitative and qualitative data to achieve the outcomes you want. Only including either kind is likely not enough. For example, if you're going to have data on incidents it would be helpful to have commentaries on said incidents for full context - e.g. "this was a Severity 1 incident that was downgraded to Severity 2 because...".

Then identify and task the right individuals to collect and interpret the data. Collection can be automated but interpretation is the most important part. You don’t want to focus on what’s going well, you want to focus on the anomalies and the interpretation of your experts of the why behind them.

You'll need to provide the time, space and tools for a collaborative back and forth between the individuals collecting and interpreting the data and the eventual consumers of said data.

Last but not least, clearly define a time before the review for this pre-work to be “ratified” as ready to review.

Involve the right stakeholders

It's important to have the right decision makers in the room - and have them understand the pre-work - so they can dive into the real problems, not waste time on status.

Keep in mind that reviews with the right people are an opportunity to improve. Do you have the right data, at the right level, with the right amount of color to accomplish your outcomes? If not, adjust the next review to include it.

Clearly define the objective

Clearly define the objective for your review. Are you just discussing? Are you creating action items to be completed before the next review?

You can use software tools to make it clear what you’ve captured and committed to. If this is a repetitive review, make sure to highlight past objectives and hold your group accountable to them.

Similarly, you can use tools to score progress on your outcomes in a way that’s clear to all involved.

Build your "tech stack"

Don’t scrimp on the mechanics of the process. Just like the code review process, there are tools you can use to create an effortless and efficient flow, setting the stage for successful alignment and collaboration. You should have tools to:

• Present the data in a structured way
• Facilitate async collaboration (such as commenting and tagging)
• Help with data gathering, surfacing past outcomes, reminding everyone of the timeline of gathering, interpreting and reviewing data
• Nag. Getting all the things done to have a productive review can be a chore. Use automation to do the drudgery. That way, no one shoots the messenger!

Reviews will kill your meetings

Getting groups of people together is one of the most expensive things your organization can do, so start treating it that way. Converting your meeting to review will transform aimless talking to an outcome and data-driven collaboration, allowing you to focus on the right things and discuss meaning instead of status.