An Introduction to Engineering Design Reviews
An engineering design review, or EDR, is intended to protect one of the most precious assets a team has: time.
EDRs are a way to proactively get ahead of both documentation and system design to ensure that we are building well-thought-out systems that everyone understands. The more people understand the inner workings of each system as well as the overall interactions between components and systems, the more we can benefit from streamlined discussions, pair programming, and helping each out.
It means that we can leverage our partners to help the team through evangelism, structure, and inter-org communication. Clarifying requirements by forcing a conversation to fully understand them before estimating, surfacing existing work from other groups that can be leveraged, and producing digestible documentation of our chaotic, but efficient, thought processes is critical.
And, perhaps, most importantly, we can leverage our collective brainpower to identify deficiencies that may have been missed/overlooked by an individual to discover improvements and share alternative approaches to the design to result in better system design.
There are many ways to perform an EDR, but based on research from the learnings of tech giants, herein is a generic process that can easily be customized for your specific use cases. The EDR process must be focused on optimizing an engineer’s time so that the most critical design points are discussed as efficiently as possible.
When is an EDR necessary?
Doing EDRs unnecessarily generates busy work and doesn’t help anyone. A balance needs to be struck on how big or small, how significant or insignificant of a change is being discussed, and when an EDR is necessary.
As a rough guide, an EDR should be considered when…
- A new project, service, or component is being created
- An external data contract change is proposed for an established service interface
- A significant change to an existing design or deployment
- A substantial shift in the requirements or acceptance criteria
Process overview
- Write an engineering design document — not necessarily in a silo, can even collaborate with the entire team on it, but the purpose is to have it written down. The design document should include background, design goals and details, some visual diagrams, and any tradeoffs that may have been made.
- The design document is distributed to the team at least a couple of days in advance to allow sufficient time for review and mulling.
- Any questions that come up during individual review should be added to the questions document to be addressed during the review.
- The review meeting is to cover the questions and review the design, and this consists of two passes: the first, a quick big picture review, the second, a slower, more thorough review of the details.
- Identify the next steps (Are we ready to build? Do we need another revision? Do we have insufficient information?)
Participants
The objective is to keep the room around 8 active participants, beyond that there are too many voices in the room. Anyone interested should be welcome to attend; however, only those who have read the supporting documents before the meeting should be active participants.
That makes reading the supporting material ahead of time rather important, mostly to ensure that all the participants enter the room with the same base understanding, and we can skip straight to a discussion.
Those that have other pressing priorities but who want to be in attendance, but will be working on other things, should save everyone from their oxygen consumption and not attend.
Publishing EDRs
Equally as important as having the conversation, the EDR itself should be published somewhere for the team to refer back to. This also helps new team members onboard quickly by being able to read up on the history of the team’s decisions (including the WHY something was done a certain way).
If you want to take a more detailed look at how an EDR should work (along with a template), check out my “ The Inner Workings of Engineering Design Reviews” blog post.
Originally published at https://lorenzo.aiello.family on March 8, 2020.
