Effective meeting preparation for engineers

Engineers tend to dread meetings, and for good reason: bad ones can be soul crushing. Not only are bad meetings a waste of everyone’s time, it can make the meeting’s organizers look incompetent. Paradoxically, as engineers grow in their career, meetings grow more important. You attend and organize more of them, and as a senior voice in the room, your words can have an outsized impact.

Meetings get a bad rap. Well run ones are an efficiency multiplier, leaving people energized and productive, and a team more cohesive. The right meeting can even turn around an otherwise doomed project.

One of the easiest ways to improve the quality of your meetings is to prepare for them. Without preparation, you’re fighting an uphill battle against context switching; one minute you’re coding and the next you’re in “meeting mode” without clear direction.

Your first priority for any meeting should be to understand its goals for everyone, along with personal goals for yourself. Set aside enough time to write down this information in your “go to” writing tool of choice (e.g. Google Docs, Evernote, a notebook) when preparing for the meeting.

The rest of this post covers one way to do that. My approach is concrete and systematic. It’s not for everyone, but it can pair well with the mental model of many engineers. If you’re struggling with meetings today, I’d recommend giving this workflow a shot.

Meeting goals

The first and usually most important item to capture is the goals for everyone attending the meeting. What does “shared success” look like? That’s what has to happen for virtually everyone, not just one or two people, to feel the meeting was worthwhile.

When in doubt, there’s only a single goal per meeting, but more complex or lengthy meetings may have more. You should be able to summarize each goal in a sentence. And specificity is critical; capture what’s unique about this meeting. That can be difficult when many of your meetings can be recurring, where the goal feels obvious (e.g. you’re starting a sprint). Dig deeper.

The verbiage used to describe most goals boils down to one of four words: learn, clarify, debate, or decide. From those four words we derive four meeting types:

  • “Learn” meetings are synonymous with knowledge transfer; status meetings, stand ups, traditional presentations, and code reviews.
  • “Clarify” meetings are usually brainstorms or architectural discussions; the goal is to sprout new ideas and dig deeper, without a focus on critique.
  • “Debate” meetings discuss the pros and cons of several options, some of which you may eliminate.
  • “Decision” meetings are naturally decision oriented — you’re leaving the meeting selecting a single direction.

Once you’ve figured out the meeting type, write a complete sentence — subject, verb, the target of the verb — to capture the meeting goal. For example:

  • The engineers learn how to validate forms through component X.
  • The team clarifies architectural direction A to the point where we can estimate the engineering weeks to finish it.
  • The product owners and designers debate three different UI layouts for the login page. They finish the meeting with clear advantages and disadvantages of each.
  • The engineers decide if we should pay down UI debt on page X in the upcoming sprint, or punt to the next quarter.

Notice how all four examples are specific and concrete. Every one of them could be applicable to an otherwise uneventful meeting you have every week.

This might feel like a lot of formality for just a sentence or two, but nailing meeting goals are critical. Everything in a meeting revolves around goals: the agenda, your point of view, how long the meeting should be, and who the right participants are.

In rare cases, the goals are more complex than you expected and you’ll extend the meeting time accordingly or split into several meetings. More commonly, you’ll realize there isn’t as much to discuss and trim time. Likewise, it’s common you’ll find those critical to a meeting are now optional or don’t have to attend at all.

And if you’re struggling coming up with any concrete meeting goals, it’s a strong signal to cancel the meeting outright. Before attending, pay close attention to meetings with a learning lens. Is the information flowing in just one direction? Will one person be talking the whole time? Ask yourself if it’s more effective to swap out the meeting for some other asynchronous format like Google Docs, Slack, or email.

Personal goals

After you capture meeting goals in your tool of choice, write another sentence or two capturing what you personally want to get out of the meeting.

For “learn” or “clarify” meetings, personal goals might be a specific question you have or subject matter you want to digest or teach:

  • Highlight impending deadline of feature X with the engineering team.
  • Sidestep performance related questions by highlighting alternative library Y.

For “debate” or “decision” meetings, personal goals usually define your opinion:

  • I’m siding with option A for the rollout plan. Advantages include better server reliability and a less worrisome on call rotation. I know this will take an extra three engineering weeks and bump features but it’s worth the investment.
  • There are more than a few ways this meeting could go but my only strong feelings are about investing in feature X. We should avoid investment here. I suspect the work would add weeks of tech debt over the long run.

Sometimes personal goals have less to do with the subject of the meeting and more with interpersonal dynamics:

  • I’ve been crowding out others’ voices in this meeting, I’ll be more judicious with my comments.
  • Engineer X has been quiet about feature A for weeks now, I’ll proactively try to draw out her opinion more.

Note that personal goals don’t follow the verbiage of meeting goals, and in rare cases are superfluous; your goals may already match everyone else’s.

Setting aside time

Make sure you set aside time for preparation; I’d recommend five minutes for every meeting you have, regardless of its length and your role in it. Actual prep time varies; sometimes you can capture meeting goals in a minute flat. Other times, you might spend far more on complex subject matters. Obviously, if you set up the meeting or are facilitating discussion you will generally dedicate more preparation time than as just a participant.

Five minutes is a good rule of thumb because it’s the shortest realistic space to account for context switching. If you’re deep in thought on another subject, it can take two minutes just to recall the meeting’s basic facts.

Technical details rarely matter most

For a post aimed at engineers, it may seem odd how little we covered technology. But that’s intentional: the most important preparation for any meeting is rarely technical. Instead, your first priority is understanding a meeting’s purpose and satisfying the people in the room. Nobody will care how much you know about the technology if you don’t understand everyone’s goals and aren’t respectful of their time. Put people and purpose ahead of the code and you’ll be in better shape virtually every time.