Design reviews feel way more vulnerable than they should.
This goes for any sort of presentation of ideas and results, really—whether PDR, CDR, TRR, FRR, or just a small-group review of one person’s analysis. Maybe it’s because presenting to a group, even over video call, hits the same ape-brain anxieties as public speaking?
It’s unfortunate, because design reviews aren’t meant to be a ritual grilling of one engineer.
An article I once read about an aviation incident included an illuminating perspective: a mishap happens when the holes in the Swiss cheese of all the systems involved line up just right.
A mishap doesn’t have to be as serious as aircraft loss (or worse), but it still can result in lost time, wasted funds, and lowered spirits.
As an engineer, I (and my team) have a moral obligation to remove as many of those holes as possible. At the very least, we want to keep them from lining up, or warn others about them so they can avoid accidental overlaps.
I consider it a huge part of my job to prod at designs, analyses, and conclusions to make sure they’re well thought-out. I play devil’s advocate, or argue against an idea even if I actually like it. I ask seemingly silly questions, not because I don’t trust the presenter, but because I know it’s something I might forget to account for and I want to calm my own worry.
This is what design reviews are intended to do: lay out every piece of cheese to know where the holes are.
To a certain extent they’re a presentation of a design or test plan, sure. But it’s also a chance for the team to step out from the trees and see the full forest, and for other stakeholders and subject matter experts to voice their own uncertainties and have them clarified.
You shouldn’t need to prove anything. It’s not a legal defense, or a challenge to someone’s competence. It’s a conversation.