As a follow-up to my story about Introducing Engineering Design, I share the step-by-step guide I put together for my team when I first introduced this concept to them.
Feel free to use it and modify it as needed for your own team and use cases. I'd love to hear feedback about what worked and what did not work for you!
Updates to our development process
1. A new "In Design" step that tickets go through.
- If a ticket is simple and does not need a design, feel free to skip that step. The goal is for the assignee to consciously make that decision based on common sense.
2. A 30-minute meeting reserved from 10:30-11am EST every day for engineers that need to talk with other engineers, EM, PM, or designer about their ticket under "In Design".
- Not all tickets will require a conversation or this meeting.
- The goal of this meeting is to ensure that we are available to chat with the assignee if they need us, and that the conversation is time-boxed to 30 minutes, which means that some work and thought were put into it.
- I do not expect us to have to attend this meeting every single day, but the idea is to have that time reserved for when we do need it.
Benefits of this design approach
1. Align on the implementation prior to any development so that there are no surprises during PR reviews.
- We should not be presenting code in these meetings — this is not a review meeting. Instead, we should be presenting documentation, engineering specs, diagrams or pseudocode.
2. Make the end-to-end development cycle faster (shorter) by investing time up front so that PR reviews are more efficient.
3. Identify estimate discrepancies early in the development cycle.
4. Opportunity to do knowledge transfer when talking about different implementation approaches.
5. Empower other engineers on the team and bring them along on the ride.
If a design exercise is needed
How to run efficient design meetings
There are 3 approaches that should be used by the proposer to ensure everyone's time is respected and that the meetings are beneficial:
1. The proposer comes to the meeting with a proposal, and asks for thoughts / opinions / breakdown of their idea.
2. The proposer comes to the meeting with multiple options (a la DACI): "I am debating between options A, B, and C, any suggestions?"
3. The proposer is struggling to come up with good implementation ideas and uses the 30-minute meeting as a brainstorming session with their fellow engineers. Even though this is a brainstorming session, the proposer has done some initial homework on the requirements and understands the problem to solve.
Responsibilities of the proposer
1. At the start of the meeting, state the end goals for the change.
- Be as specific as possible
- Provide pseudocode examples of final implementation if it makes sense
- Enumerate all affected packages/services/systems
2. Can the change be performed incrementally?
- If they cannot, why not?
- The change is insoluble and can only function properly as a whole (should be avoided).
- The change is so small that it does not make sense to break it down
3. Break the change into discrete increments.
- Be specific about each increment.
- Eliminate ambiguity where at all possible.
- If the next increment depends on findings from a predecessor, state that up front, so that everyone is on the same page. This should be avoided whenever possible as it introduces uncertainty for anything downstream.
4. Quantify and capture all increments in the issue tracker.
Responsibilities of the team
The team (defined in this section as everyone involved in the design decision process except the proposer) is responsible for the following:
1. Provide timely feedback and a definitive 👍 / 👎 decision on the proposed design by the end of the meeting.
- If the design is not fully understood, or if it is only understood up to a certain incremental stage, then this should be explicitly stated and agreed upon by all team members. The proposer should work on reducing risk and unknowns to make it clearer, clarify the proposal based on the feedback received, and present it again when ready.
2. Consolidate opinions.
- The focus of each design step should be the most immediate subject matter. Peripheral concerns should be addressed in other design meetings, unless the impact is unavoidable.
- There's really no way to quantify this. We all know bikeshedding when we see it.
- If there are competing ways to handle the issue, then the team and proposer should reach consensus on the best way to go forward.
Disagree and commit
Once a decision has been made, I expect that everyone gets onboard. We will reopen the discussion only if there is significant new information.
Photo by İrfan Simsar on Unsplash
