I disagree. I think companies that have meetings like this have an immature meeting culture.
Meetings are for low-latency collaboration, not information transfer.
For example, reading a design doc is obviously more efficient asynchronously because everyone has different reading speeds and doesn't need everyone else in the room while they read.
Arguing about tradeoffs in a design doc is usually more efficient in a meeting than an email because the low latency communication and additional signals from live communication make the discussion more efficient. For example, if the design doc says we should do X but you think it should do Y, in an email I maybe have to enumerate all the advantages and disadvantages, but in a meeting, maybe you're convinced after seeing just 20% of my rationale.
> For example, if the design doc says we should do X but you think it should do Y, in an email I maybe have to enumerate all the advantages and disadvantages, but in a meeting, maybe you're convinced after seeing just 20% of my rationale.
This is organizationally inefficient. You should write these reasons down in the design document so that you do not need to rely on both of us still being employed 5 years from now to explain to someone who is evaluating the state of the system on why the decision was made. A design document must include justification, not just the final decision, -- that's obvious from the code.
What you're describing as "immature meeting culture" I would instead describe as "mature documentation culture". Different companies work differently of course, and if you're absolutely optimizing for latency and have relatively small groups of stakeholders, meetings are super efficient since you can make all decisions now. But if you're optimizing for throughput and have larger groups of stakeholders, more asynchronous (or entirely asynchronous), document/slack/email driven approaches.
I think the amazon approach is weird and somewhat childish, but I stand by "meeting is only necessary if the stakeholders haven't approved your design offline/async". For such meetings you can use the amazon approach, or you can assume folks have already reviewed and left open comments, and only address outstanding comments during the meeting.
I agree you should document the decisions and discussions around them. I never said you shouldn't, just that the discussion shouldn't be entirely written. But you can discuss live and summarize the discussion in the doc after.
Relatedly, I don't think full discussions about the design doc should live forever in the design doc. When I was at Google, I hated reading design docs where every line had a convoluted, 20-message comment thread attached to it in the margins. When I owned a doc, I'd drive those comment threads to a resolution, write up a concise summary of the debate in the appendix, then resolve the thread.
> Relatedly, I don't think full discussions about the design doc should live forever in the design doc. When I was at Google, I hated reading design docs where every line had a convoluted, 20-message comment thread attached to it in the margins. When I owned a doc, I'd drive those comment threads to a resolution, write up a concise summary of the debate in the appendix, then resolve the thread.
Yes exactly, you don't need the entire back-and-forth, but the relevant information should be written down somewhere.
> Meetings are for low-latency collaboration, not information transfer.
Ok, but without a doc, collaboration in a meeting can become inefficient in many ways. Folks can talk past each other, bouncing between unclear options and losing clarity on what they are even debating. Only one person can talk at a time, so folks are sitting and waiting for their turn, etc.; Strong personalities can dominate and filibuster.
Writing even a bad doc ahead of time can help to make the meeting’s purpose clear. The author can guide the discussion by laying out and labeling big options and decision points.
While reading the doc, everyone can comment in parallel, so you aren’t serializing the conversation for small things or letting some verbose person waste the time.
Reading during the meeting helps folks manage time outside the meeting. It means: you don’t have to prepare for meeting you don’t own. It avoids “random people” assigning you work beyond what they are asking you for in your calendar. For busy managers this is a huge benefit.
I'm arguing for reading the doc ahead of time, identifying topics about the doc to discuss, then coming to the meeting with a specific agenda.
>Ok, but without a doc, collaboration in a meeting can become inefficient in many ways. Folks can talk past each other, bouncing between unclear options and losing clarity on what they are even debating. Only one person can talk at a time, so folks are sitting and waiting for their turn, etc.; Strong personalities can dominate and filibuster.
I don't understand. These are just problems with meetings in general no matter what you do in advance. What are you arguing for?
>While reading the doc, everyone can comment in parallel, so you aren’t serializing the conversation for small things or letting some verbose person waste the time.
>Reading during the meeting helps folks manage time outside the meeting. It means: you don’t have to prepare for meeting you don’t own. It avoids “random people” assigning you work beyond what they are asking you for in your calendar. For busy managers this is a huge benefit.
I don't understand how this can be possible. It means that letting someone else manage your time is more efficient than managing your own time.
If I need 5 minutes to read a document, how is it helpful for someone to force me to sit for 10 minutes to read it at a specific time? It's obviously more efficient for me to read it in the block that I choose and not waste the extra 5 minutes.
The Amazon way sounds like how you'd manage time for a child, where you can't trust them to manage their time, so you have to schedule time blocks for coloring, recess, and eating lunch.
> I don't understand. These are just problems with meetings in general no matter what you do in advance. What are you arguing for?
That by simply requiring a doc, you have forced the person who called the meeting to think about what they want to achieve, and to prepare their thoughts ahead of time. This makes the agenda clear to everyone and helps to guide the discussion.
> It means that letting someone else manage your time is more efficient than managing your own time.
If we are reading the doc together in the meeting, I only need to accept/decline the meeting and I am good.
If I am expected to pre-read, I have to actively do something to schedule that pre-read time. And the doc has to be ready whenever I decide to read it. Multiply that by 10+ meetings a week for a busy manager, and you have a lot of mundane scheduling work to keep straight.
> If I need 5 minutes to read a document, how is it helpful for someone to force me to sit for 10 minutes to read it at a specific time?
I’ve not found that to be a problem in practice. I can use extra time to think and prioritize my feedback, or catch up on Slack, etc.