Running Meetings Like an Amazonian

https://www.youtube.com/watch?v=FaXocwfDF-E

Crisp doc & a messy meeting

Writing Design Docs like an Amazonian

Meeting guidelines

  • Identify the required attendees. Include subject matter experts for the space, team members, and stakeholders. You haven’t reviewed the design unless all of your required attendees have reviewed it. Prefer a realtime meeting with all attendees present to generate discussion.

  • Add aws-mobile-design-interest@amazon.com  as an optional attendee.

  • Reserve enough time. Allocate 15 minutes at the beginning to review the document, but increase that if your design is particularly dense or long. Any substantive discussion is going to take 30 minutes unless all participants are already familiar with the components of the system.

  • State the goal. Are you asking for feedback on a proposal? A decision amongst multiple proposals? Approval from the API Bar Raisers?

  • Guide the discussion. If this is a system design review, defer API naming to a later discussion.

  • Monitor your progress. If you are requesting a decision amongst alternatives, and you haven’t reached it by 5 minutes before the end of the meeting, schedule a follow-up with the decision makers.

  • Consider a note-taker. Having another person take notes and document follow-up actions frees you to guide the discussion and engage in conversation.

Design Review Meeting

  • The meeting is rushed. The meeting is scheduled for 30 minutes, and 15-20 minutes of the meeting are required to read the doc. Discussion is truncated, and decisions are deferred to a followup meeting.

  • Reserve enough time for reading and discussion

  • Don’t assume your audience has enough context to read through the document quickly

  • Put supplementary material at the end of the document, and add in-document instructions like “STOP READING HERE”

  • The audience is limited. The meeting attendees are all from the implementing team, limiting the diversity of perspectives.

  • Add  aws-mobile-design-interest@amazon.com  to the meeting invite

  • Solicit other teams for interest

  • Ask a senior developer or manager for suggested attendees with subject matter expertise

  • The discussion is unfocused. The discussion veers into API naming, rather than focusing on the system design. (But beware the counterexample of the meeting moderator claiming that a relevant architecture discussion should be deferred to the API naming review.)

  • Remind attendees to focus on use case, architecture, and design decisions

  • Discuss high-level themes first. Add deep-dives to a Parking Lot and revisit at the end

  • Schedule followup meetings to dive deep on important issues