Design Reviews: Patterns and Anti-patterns
A couple weeks ago, we addressed the preparation and general structure of the design review. Still, there's a gap when you think about how people should approach the review and behave during the review.
It's all too common to experience frustration, anxiety, and hopelessness during reviews, especially when you're dealing with principal engineers or software architects. Design reviews don't have to be like that. They can be better, which is really what this whole series is about.
So, let's jump into some of the patterns and I've seen in good design reviews.
Patterns
Just like software design patterns, these patterns provide examples that have been shown to work. They may not all work for you, but I'd suggest you definitely avoid the anti-patterns, even if you don't accept all the patterns.
Collaborative
I know I've harped on this in some of the other posts. It really deserves another mention, though. It can be easy in some software engineering cultures to slip into an antagonistic posture. The reviewers spend time poking holes while the presenters try to defend their work.
There are no winners or losers in a design review.
Reviewers should be pointing out weaknesses in the design for the purpose of mitigating or solving them. Design reviews exist to make designs better, not to demoralize engineers.
To that end, reviewers need to point out the strengths in the design as well as the weaknesses. I have seen designs face harsh criticism in reviews only to see the engineers go back and rework the entire thing, removing important good pieces of the design. I know some cultures like to focus on ripping apart the bad pieces, but people can also learn when they get things right. Tell people when they've done good work. Tell they why you think it's good. Make sure they don't break the good stuff to repair the issues.
Start and end on schedule
There have been so many articles about companies putting price tags on meetings and canceling large swaths of recurring meetings. I'm not going to make a value judgement about that. Still, design reviews tend to be long meetings with very senior people. The time commitment is large and shouldn't be taken lightly.
When I say it should start on time, I mean the conversation should start at the scheduled time. I'm going to poke at my former employer, Amazon, for a bit here. There's a big pattern of spending the first 15+ minutes of a meeting reading the doc. I do not see how they continue to justify this behavior. Everyone should have read the supporting material beforehand because it should have been sent out well in advance (at least a couple days).
As for ending on time, even good design reviews can get stressful. There will be follow-ups. Make sure you give everyone's time the respect it deserves. Finish on time and make sure everyone knows the next steps.
Know what happens next
Speaking of next steps, everyone should know what's happening next at the end of the review. The scribe can provide a lot of value here. I think the follow-up work falls into 3 categories:
- Things that will be reworked
- Things that will be investigated
- Conversations that need to continue
Anti-Patterns
Let's talk about some things that make design reviews less useful or even destructive.
Doing a ____ review in your design review
You can put almost anything in the blank here. It could be "UI", "product", "security", "readiness", etc. If you go back to look at the goals, you can see that we want to focus on improving a software system.
It's very easy to drift into reviewing other things. For example, I've seen reviews that started picking at security issues. You can easily spend 2 hours talking about the particular nuances of the security of the system, but is that a good use of the time? Most companies have some type of security review process. Those specialized processes around user experience, security, and product are typically run by experts in the subject matter.
It can be so tempting to, say, spend an entire Amazon Smile design review picking at the product concept (true story), but no one came out of that meeting thinking that the solution to the problem improved in any way.
Scattered Topics
Limiting the number of participants helps keep the conversation on track. Still, you don't want to jump all over the place. Again, you have to understand that the review isn't long enough to cover everything. Some things will have to be discussed later. Start a topic, drive it to a reasonable stopping point, and then go on to another topic. Some people like to keep a parking lot of topics visible during the meeting. You can also have the scribe keep track of that. Either way, try to have meaningful discussion and gain useful insight rather than trying to touch on every single thing.
Empire Building/Undermining the Product
The last anti-pattern is a doozy. I've definitely seen principal engineers enter a review intent on stopping a system or making sure it gets built in their org. I don't know much more to say than: Don't do this!
There are channels and mechanisms for ensuring that duplicate systems aren't built or that bad products aren't launched. The engineers wanting a design review rarely have a lot of control over that. For that matter, the principal engineers doing the review rarely have control over the budgets and structure of their own orgs, either.
I have seen this happen before. I have never seen it "work" (i.e. actually tank or move the project). Everyone feels bad coming out of it (or they should).
Wrapping Up
This list is not exhaustive, by any means. I could go on and on. I might add more posts later to discuss some other tricky patterns and anti-patterns. For now, I leave you with three of each.
That leaves just one wrap up post to finish this design review series. The final post will include a brief summary as well as cheat sheets for all the participants in a review. What should you do before? What should you do during the review? What happens afterward? That's going to take a little more time, so expect that in two weeks (September 28, 2023).
Next week's post will be a little about my job search. I've accepted an offer for a new job starting in October. I've had several questions about the process I took, how I felt about it (not good, in general), and any tips I can provide. Instead of responding to each person individually, I'm going to try to distill my ideas here.
Until next week...