Design Reviews: Attendees

Last week, we covered possible goals for a design review process. We'll talk more about the goals for a particular design review next week along with format. For now, though, we need to figure out who to invite to the meeting.

Stepping Back to Goals

I know we talked about goals last week, but I want to cover which goals can benefit from properly choosing the attendees.

Attention and Support from Senior Engineers

I wrote last week about the benefits of having the eyes of more experienced engineers looking at a design. Obviously, principal reviews (or equivalent) were built around this idea. These engineers will form the reviewers group.

Course Correct Early

We also need to make sure that the right people attend the meeting so that course corrections can happen early, and with minimal rework. I'm not just talking about technical direction, either. Product direction, launch timelines, and more can benefit from design reviews. It's always better to change a feature or a target date when you have months before you launch.

Create Ongoing Exposure and Communication

The relationship between the presenter and reviewers, especially after the actual meeting, will help you dictate who is reviewing the work and how many. We do want engineers getting support and mentorship from the more senior engineers, so we might try to get reviewers that will be able to continue advising the engineers doing the work.

Reviewers

Let's start with the people who will provide feedback during the meeting.

If you remember from the first post in this series, having too many reviewers will negate the benefit of the review. DRBs tend to have too many reviewers. Thus, they work for socializing the work, but they tend to fall down when it comes to actionable feedback.

On the other extreme, a single reviewer may not provide enough breadth of knowledge and experience. Single-reviewer reviews can often lead to a principal engineer redesigning part the system in the meeting and throwing it over the wall to the team. This can limit the benefits of the review.

3 is the magic number

In my experience, you cannot go wrong with three reviewers. It strikes a good balance between getting useful feedback and preventing a single view from dominating. You can also get a variety of expertises represented in a panel of three reviewers without creating a lot of chaos in the conversation.

In the ideal situation, your reviewers can trade off with digging into areas of the design. Your conversations should be able to go deep enough to find issues, suggest solutions, and record follow-ups before moving on to the next point. With three reviewers, you can probably do this a few times in a 2-hour meeting^[1].

Is there room for flexibility on this number? Yes, but not much. Once we go through the other attendees, we'll understand those boundaries. For now, I will offer a target of 2-4 reviewers. If you find yourself adding more, you might want to ask these questions:

1. Is this a design review or something else (e.g. readiness review)?
2. Are there other processes to get feedback from some of these reviewers (e.g. security review, UI review, etc.)?
3. Are there distinct sections where this review could be split into two pieces with different reviewers?

Make reviewers external

One last point to make about the reviewers before we go on: they should not come from your team. The ideal review panel comes from other teams (sibling and cousin teams are good options). The most senior people in your team shouldn't need to be reviewing the design in a meeting because they've been seeing it develop. I'll have a great job for the tech leads or principal engineers in your team a little later.

Presenters

First, I want to say that I hate this term. Design reviews have long been seen as somewhat adversarial. One side presents (and, by extension, defends) their design while the other side tries to pick it apart. The best design reviews are conversations. If someone can give me a better idea of a term to use, please let me know.

Presenting Engineer(s)

Obviously, we need to have the engineers who will be "presenting"^[2]. I'd suggest one or two, no more. I've been in 4-person presentations. Q&A for a 4-person presentation is either chaos or just one person. Since a design review is a conversation, more than 2 presenters will just lead to interruptions, talking over each other, and frustration.

Non-Engineer Stakeholders

Along with the engineers who designed the system, we have several other stakeholders involved. Not all teams may have all of these, but I'd suggest any that are available attend the meeting.

1. Engineering Manager: The manager usually owns the schedule, so they should definitely attend.
2. Product Manager: The PM owns the product, and design decisions can affect the product. You may also need the PM to chime in as to why certain requirements exist. It's always good to have that role present.
3. UI/UX Designer: If you have UI/UX, you should probably have the designer there. So many decisions affect the user, it's good to have that safety net when you start making decisions that affect users.

Scribe

Ultimately, the team presenting the design gains value from the review. Therefore, the scribe for the meeting should be a representative from the presenting team.

I'd even go further and say the scribe should be an engineer. Engineers are going to be able to record the feedback more usefully (we hope) than someone less technical.

In my ideal world, the tech lead (if not a presenter) for the team will scribe the design review. This has a bunch of advantages:

1. Tech lead has been guiding and mentoring already, so any feedback has already been considered.
2. It keeps the tech lead from talking over the presenters.
3. Wouldn't the tech lead know exactly what the important parts of the feedback are?

Whatever the case, the scribe should probably be technical and not an essential participant in the conversation. That leaves the rest of the participants to talk without worrying about capturing everything.

Observers

There are lots of reasons to let others observe the process. The rest of the presenting team can often benefit from being able to watch the review. Sometimes, there are other involved teams that want to see how the system develops. Justifications abound.

I want to put constraints on them, though. As we've already talked about, too many reviewers make the meeting less useful. We don't want observers to become reviewers. Observers should only observe.

In fact, in our post-COVID world, I strongly suggest observers be remote. People can be a distraction, even if they aren't talking. We have all been in large, in-person meetings where they start late just because of the number of people who need to get through the door and find a seat. Using video conferencing can ensure less opportunity for distracting or delaying the conversation.

Does this mean that observers cannot provide feedback? No. They just can't provide feedback during the review. I'm a big proponent of open design docs, so they should be allowed to provide feedback on the doc without being an active participant in the review meeting.

The List

We've covered our three groups, so let's look at what we have:

• 3 reviewers
• 1-2 presenters
• EM
• PM
• UI/UX designer
• Scribe
• Observers (0-?? but only passive)

That comes out to 8-9 active attendees as a typical group. Obviously, it can be a little larger or smaller depending on a variety of factors we've discussed. It's hard to look at any business literature without running into multiple articles about optimal meeting size. By most standards, we're on the cusp here, if not over. You can trim it a bit more by saying the EM, PM, UI designer, and scribe are less active, which gets it to 4-5.

In any case, we're in the right neighborhood. Adding more reviewers, presenters, or allowing observers to participate would put us further outside of the recommendations.

Wrapping Up

There you have it. With a little help from a principal or tech lead community, the list of 8-9 attendees practically writes itself. Don't fret over which extra people to invite. Either make them observers or don't invite them.

Now that we've got our list and sent out the invite, we have to actually have the review. Next week, I'll cover how to format, scope, and benefit from the review. Following that, I'll go through some patterns and anti-patterns as well as tips for each active participant. I hope you'll keep reading!