Preface
In this post, I will share the personal/communicational suggestions that I learned over time. Although I am biased towards the BE DR review process (my field for the last 7 years), I believe that most of my suggestions are valid through any stack - I've been mentoring DRs for the last two years under the Tech Lead title. In Autodesk and Cisco (my previous company) the DR process is pretty much the same, and in both companies, the same interpersonal communication issues were raised. I witnessed design reviews that ended up with developers quitting the company and on the other hand, I experienced DRs where input from different parties practically saved the developer's ass.
What is it all about?
DRs are mainly for aligning the suggested solution with the rest of the parties involved (eng. manager, architect, team members), making sure that it's up to company standards for scale, robustness, security, and redundancy. In addition, if there is any input/questions regarding the solution - it will be raised during the meeting.
So what makes it so hard?
Lack of transparency during the design process with different parties & expectations misalignment
Fear of getting back to the drawing board after a long design period
Competing with other developers who want to be heard/see things differently
How it feels
I believe that DRs are one of the hardest parts of delivering a feature, you put your ideas and capabilities into the scrutiny of different personnel that might not be on the same technical or personal page as you are (for instance an architect that has 10X experience than you do, and eng. manager that only wants the feature out yesterday).
For me, I would say it's 50% fear of going back to the drawing board, 30% fear of making a fool out of myself in front of my peers, and 20% making my boss unhappy (% might change from feature to feature and depending on the scope of changes and nature of it).
Making it better
The right way to approach the DR is to truly believe that everyone in the meeting is on your side and has the same objective - delivering a good and robust feature.
How can we bring the different parties to this posture? How can you persuade yourself this is the situation?
Brainstorming & team collaboration
If you want your peers backing - always share your design with them before the DR meeting itself, and give them some space for their input in your design. In this way - everybody gets to be heard. If one of your peers will raise an issue during the DR meeting itself that wasn't raised before - (this might be translated in your mind as - why didn't she say anything about it in the previous meetings), be sure that he hasn't thought about it before.
Normally I schedule the pre-design review meeting with all of the relevan devs in the team at the time I'm starting the work on the design (for a week later or so)
Transparency
To all involved parties - eng. manager/s & architect/s it would be better if they know the core solution you are suggesting before the DR meeting itself. For instance, set up a check-in meeting with your eng. manager once a week to show progress, in this way she will be aligned with the core solution you are suggesting. There is no way you work on a DR for a month without checking in with your eng. manager that will finish on a high note, in every time I saw this happening it ended up badly.
This applies to any involved party, if you feel like it's hard/not possible scheduling check-ins, ask for some advice, and set up a meeting for getting some help.
Asking for help - more than one purpose
Asking for help is not only for gaining technical insights:
Asking for help creates better transparency & alignment, having different stakeholder's input before the DR itself.
Asking for help puts you in a position of strength - you know your upsides and you are confident enough that asking for help will not have an impact on the way you are being perceived.
Conveying the right messages - scripting the meeting
Eventually, most of the DR work is selling your solution:
Before the meeting you can try to understand the people that are going to attend and map their 'love language' - try to anticipate their input/questions. If you find it hard (for instance participants that you don't know that well), you can ask team members who do know them about their professional manner/field.
Script the meeting - know the 'path' you are going to present the idea, and try to map possible obstacles. Try predicting what questions might be raised, and prepare answers.
During the DR itself
Once you created transparency with your eng. manager/architect/peers and all are aware of the core solution, most of the DR meeting will be around the bits and bytes that were left out of the sync meetings. This leaves you to deal with 'light surprises' that are not related to the core solution you are suggesting. Be sure that someone in some context will ask questions that you are not prepared to which is absolutely fine, but during the prep work you must try narrowing it down to small things in order to avoid going back to the drawing board.
Dealing with surprizes
Eventually, there is no way around it - being asked about topics you haven't covered/thought about is inevitable, so the measures that we covered (prep work with your team/boss) will make it easier to cope with this kind of questions, and reduce the odds that you will be tackled during the meeting.
Comments