>Amazon meetings start with the presenter passing out copies... of a prose document... The meeting starts with everyone sitting in silence, reading the document, and adding notes and questions in the margins with red pen.
I've never worked at Amazon, but I've heard this a lot, and it always strikes me as an odd practice. Odder still is that it apparently works and everyone I hear talk about it seems to love it.
You're squandering precious meeting time by having everyone sit and read a document together. They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.
And doing it synchronously means everyone either sits idle until the slowest reader is ready or not everyone gets to finish in time. And "slowest reader" isn't even just about reading speed. Presumably, some people can understand the document more quickly because they have more context.
In design reviews at Google, it was obvious that the majority of attendees came unprepared and were reading the docs for the first time while their teammates were discussing the doc. I suspect that the reason was that Google just didn't have a strong docs culture, and leads/managers quietly tolerated people coming unprepared (and sometimes, they themselves were unprepared).
I've never seen it done in practice, but I don't think it would be hard to have the best of both worlds where people review docs ahead of the review meeting, but there are strong cultural norms around reading docs ahead of time so the meeting is just for discussion, not just for reading or pretending that you've read.
> They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.
Amazon’s practice is a reaction to the fact that nobody actually does this. According to the article I read about this years ago, they realized that “creating a strong culture around reading before the meeting” also isn’t possible because many attendees had a meeting before this one, and couldn’t prepare for that meeting because they had a meeting before that, etc.
On paper you could punch a ton of holes in this: Why not reduce the number of meetings people have to attend? Doesn’t the reading reduce the amount of time available in the meeting to actually make decisions? But it would seem that in practice they found that the meetings people were attending did in fact have value, and that even with the reading time a lot of decisions got made.
So this may just be one of those things where you have to look at the results instead of worrying about what could theoretically be done differently. And it sounds like people really like the results and that the benefits of this approach outweigh the drawbacks, at least at Amazon.
>Amazon’s practice is a reaction to the fact that nobody actually does this.
But isn't that bizarre? I can't think of anything else where we need engineers to do something by a deadline, and we just resign to the fact that they won't do it unless we sit them in a room and babysit them while they do it.
> I can't think of anything else where we need engineers to do something by a deadline, and we just resign to the fact that they won't do it unless we sit them in a room and babysit them while they do it
Pretty much anything, unless you're in the engineer's management chain, or you've given them a direct incentive.
It's always been my experience in bigco that people can ignore almost anything that doesn't come from their management chain up until scheduled meetings get involved. Being uncooperative with meetings (declining invites without alternatives; not attending; not participating) are when escalations and complaints start occurring, and there seems to be a silent consensus that this is the standard - as in, if you complain that someone hasn't answered your emails, the standard response you should expect from anyone, including their manager, is "then schedule a meeting."
So, if you need someone to do something, you schedule a "meeting" to block time on their calendar in which they will pay attention to your thing. That includes anything they need to do to prepare, because anything you don't include in that time block isn't part of the meeting and therefore isn't going to get done.
In my experience there is always more work to be done than there is time. That means people have to start prioritizing things, managers breathing down necks over specific things is a priority signal, just like meetings. Reading something doesn't give you much actual production output to show for, so it just doesn't get prioritized.
Then you should schedule two meetings: one in a reading room, at any time that fits each individual calendar, and then later the real one in a meeting room with everyone's involved, at the same time.
We all know the costs of context switching. Why would you unnecessarily introduce two new context switches? Is it because you don't like being told when to read?
The rule is not so much for the benefit of the kind of junior IC engineer who has time in his schedule to work on code, but for busy leaders whose experience of the world is otherwise 100% verbal.
They just do not allocate time to read documents for engineers.
Isn't that how corporate work is usually done? We call the room an office and the babysitter a manager or lead.
> But isn't that bizarre? I can't think of anything else where we need engineers to do something by a deadline, and we just resign to the fact that they won't do it unless we sit them in a room and babysit them while they do it.
This is practically the point of meetings. Meetings exist as a forcing function to achieve communication that likely could have happened asynchronously but for some reason didn't.
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.
If your solution to a problem involves changing human nature, you're on the wrong track.
I've been in companies that do this. I like it more than alternatives.
The default for most meetings everywhere I've seen is to present information during the meeting, verbally or in powerpoint. For example, standups often devolve to people sharing their updates. This is much worse than having people write down updates and taking a few minutes to read them at the beginning.
Also note that these documents usually take about 5 minutes to read, even for slow readers. Meetings with much longer documents are pretty rare in my experience - feedback on long documents is usually done separately.
It would theoretically be better for people to read the documents ahead of time. But the benefit is pretty small IMO, and the cost is large – it fails if even a single person hasn't read the document.
I worked at a company where we copied this from Amazon for a specific type of meeting (bi-weekly review). But we also had the other "normal" type of meeting.
People never read the documents before the meeting in those "normal" meetings.
The challenge with your suggestion is that people will half-ass the doc reading before the meeting - we tried doing this for the "normal" meetings. It was obvious the people skimmed the doc before the meeting. You're also now relying on the manager (if there even IS one for everyone in the meeting!) to care about this.
So, in practice, giving people dedicated 10 minutes at the start of the meeting works far better.
Besides, in most "normal" meetings, the main presenter often ends up discussing background / context for 10 minutes interspersed throughout the meeting anyway. In the "pre-read" meetings, you're just compress that to the first 10 minutes while increasing the amount of information transferred.
> They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.
There's no difference in the amount of time spent whether it's read in or out of the meeting. At least spending the time in the meeting to read it, people are more focused on the topic at hand and the time will be better spent. Besides, I'd bet the fraction of those docs that are ready sufficiently ahead of the meeting are in the single digits.
>There's no difference in the amount of time spent whether it's read in or out of the meeting.
I address this point directly in the comment you're responding to.
They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.
To highlight two ways to go about this, we can assign homework, or assign, for lack of a better word, meetingwork. We don't always know how much free time our colleagues have outside of the time we've scheduled for a meeting. At least by enforcing meetingwork org-wide, it is ensured that everyone has at least some time to read the docs and they're fresh in their mind, even on short notice.
You're right about "reading speed", but I think the common alternatives are no one knows how prepared anyone is vs a few people might not be fully prepared.
> You're squandering precious meeting time by having everyone sit and read a document together. They could easily do the same thing ahead of the meeting, and you'd have much shorter meetings.
People don’t read ahead of meetings, and that results in wasting time discussing things already covered by docs.
Why does it matter when they read it? If they need more time for the meeting they can schedule more time. Only downside is that finding meeting slots becomes more difficult, but the total time spent doesn't change.
In addition to the reasons already listed (slowest reader etc) it's also good, at leasdt for some, to let new information sink in before discussing it.
I suspect these are not real issues. Most people smart enough to be an engineer read fast enough to finish 6 pages in 15 minutes(and your doc is bad if they can't), and discussing it fresh is probably better since you forget less.
you squander sooo much more time whenever people are not on the same page, or if people are worried you didn’t cover their corner case.
In my experience if it doesn't happen in a meeting it doesn't happen.