It's interesting, after my time at Amazon (8 years) -- I struggled to visualize decisions without a document, because you get so used to reviewing things in that way. However, it's EXTREMELY heavy-handed. People will give you comments on the structure of your document (to "raise the bar") instead of the content of the document, and often you can't get documents reviewed until they are aesthetically in the right place for people to digest them. Ultimately, I think it makes sense when you're at a large organization with high attrition (such that you need to keep track of all of the decisions which are made), but otherwise, it's probably not worth it to do a formal document writing process.
The real benefit of doc writing isn’t for decision making it’s for education. It allows everyone at Amazon to evaluate the author’s ability to refine their “chain of thought”.
The nice side effect is the author taking 10x more time to save 10x L+1 and L+2 leaders (ie more expensive people) from spending that same time trying to understand it.
> The nice side effect is the author taking 10x more time to save 10x L+1 and L+2 leaders (ie more expensive people) from spending that same time trying to understand it.
IMHO this is analogous to most of the economic justification for not being sucky at documentation. When you apply this analysis to the user-facing side, an hour of documentation can save hundreds of hours of user thrashing.
This is something that I would assume is intuitive, but under the capitalist mode of software development, it seems to be an uphill fight to get the economic rationale into management's heads. There are of course exceptions, and they stand out in excellence.
When you shortchange documentation, you're externalizing costs that shared efficiencies say should be internalized. Kind of like dumping sewage in the lake, or driving on leaded gas.
I don’t think that is specific to Amazon. If anything I think the whole paradigm of “over analyzing communications with vacuous update suggestions that don’t matter” is probably the most consistent thread I’ve found in all of corporate America. I’ll never forget early in my career we had huddled around a coworkers computer with our entire team including senior manager writing an email to a VP and the senior manager was making punctuation and the most inane wording updates you can imagine. I once thought there is no way the absurdity of the cost to benefit of that situation would be topped, but how naive I was - turns out generally companies seemingly can’t avoid that kind of atmosphere.
I've seen mixed results with reading the document during the meeting. It can help with people not having read the document. But people read at different paces, and the people who put off or avoid reading before the meeting are doing so because they are slow readers or have poor comprehension or retention. Reading has a high opportunity cost for them, so they avoid it.
Asking them to read during the meeting usually results in a performance, they skim or get through as much as they can until people start saying they are done, and then they don't want to hold things up so they also announce they are done. This can happen with all slow readers, even those who would have high comprehension with multiple passes or at their own speed.
The other issue is the asymmetry of effort, which the author alludes to with "no doc => doesn't happen". Proposals require writing, but criticisms can be made verbally. You would expect a lot of the feedback to actually make the proposal worse because the proposal has been through a few write-edit cycles and the feedback is generated on-the-spot during the meeting within minutes of first reading the proposal.
If critics don't also have to write then feedback becomes a game of politics. If you ask people to give feedback on something without time to think, you will get noise. No one wants to appear bad at reading in front of their peers.
> the people who put off or avoid reading before the meeting are doing so because they are slow readers or have poor comprehension or retention. Reading has a high opportunity cost for them, so they avoid it.
This sounds like a description of people making bad choices at their jobs despite an obvious correct path (don't put off or avoid prereading). If they'd have high comprehension with multiple passes and at their own speed, it's their responsibility to figure that out and take those. Correspondingly they absolutely have the freedom to hunt down the meeting scheduler if the latter hasn't provided the doc enough in advance for this. (There are a lot of ways that I'd say Amazon culture is unaccommodating of difference, but this isn't one)
> Proposals require writing, but criticisms can be made verbally.
IME, anything that a critic doesn't insist get captured (with an action item and typically their name attached to the feedback) is treated as wind in leaves.
> "...slow readers or have poor comprehension or retention..."
Our entire profession is based on working with text intensively, whether code or docs or specs. Anybody with these difficulties that aren't making the effort to compensate for them isn't going to last long, particularly at Amazon or another FAANG.
I don't disagree that reading comprehension is essential to be a good engineer. But empirically, many people with a title like engineer or manager or product somethingrather have poor reading comprehension and blend in just fine.
Any process has to take this into account, you can't design a process that only works when competent people participate and incompetent people don't and then blame the incompetent people when it fails. You have to design a process that works despite some number of incompetent participants.
Document cultures do this because writing shines a bright light on the merit of an idea. My criticism is that the in-meeting read through does not have a similar effect.
The reality is that competition at Amazon is intense.
Amazon corporate is roughly broken down like this:
L4: 45%, L5: 45%, L6: 7%, L7: 2.5%, L8+: 0.5%
Only the first promotion has guardrails (L4 to L5). Typically you’re expected to be able to write at all. From there many people end their careers at L5.
Going from L5 to L6 requires being the best person on your team for multiple years running. Compared with some really smart, focused, and motivated people. You’re also expected to be able to write well, read, and kinda poorly coach other people’s writing.
Going from L6 to L7 is very difficult. One of the biggest differentiators really is scale. If you still need help writing docs - that’ll slow you down and you won’t scale. If you’re slow to read and provide valuable feedback again that will hold back scale (many people compensate by adding more time to their work days).
However, the funny thing is the doc writing culture at Amazon is built by and for L8+ leaders. Everything else was just training and weeding people out.
Going from L7 to L8 is where “in-meeting reads” really start showcasing the differences between leaders. I’ve known smarter people that made better decisions but had their careers stagnate while watching other “80th percentile” decision makers grow because of speed to grok information and deliver valueable feedback 9 of 10 times is more important than the incremental benefit of being right 10 of 10 times.
So I get your concerns about in-meeting reads throughs but just keep in mind who and what it is defacto built for.
> "...you can't design a process that only works when competent people participate and incompetent people don't and then blame the incompetent people when it fails."
That reads like something straight out of a Dilbert comic strip. Yes, employers can require that software engineers not be incompetent; that's what they're paying for. If a process reliably reveals their incompetence, that's actually a huge positive because then appropriate corrective measures can be taken.
To me, reading a document in a meeting that was supposed to be read beforehand is unprofessional. It’s creating a culture that says it’s ok to disrespect other people’s time by not being prepared. Meetings are already quite expensive.
> If you ask people to give feedback on something without time to think, you will get noise.
Insightful. I have also observed that such processes induce more noise as participation (regardless of having a good effect) becomes the thing that managers notice for promotion/ demotion.
It's interesting, after my time at Amazon (8 years) -- I struggled to visualize decisions without a document, because you get so used to reviewing things in that way. However, it's EXTREMELY heavy-handed. People will give you comments on the structure of your document (to "raise the bar") instead of the content of the document, and often you can't get documents reviewed until they are aesthetically in the right place for people to digest them. Ultimately, I think it makes sense when you're at a large organization with high attrition (such that you need to keep track of all of the decisions which are made), but otherwise, it's probably not worth it to do a formal document writing process.
The real benefit of doc writing isn’t for decision making it’s for education. It allows everyone at Amazon to evaluate the author’s ability to refine their “chain of thought”.
The nice side effect is the author taking 10x more time to save 10x L+1 and L+2 leaders (ie more expensive people) from spending that same time trying to understand it.
Yet there are more successful companies than Amazon or as successful that don’t use this approach.
That clearly shows it’s a cultural or quirky thing, otherwise there would be a clear correlation between a company’s success and the doc culture
> The nice side effect is the author taking 10x more time to save 10x L+1 and L+2 leaders (ie more expensive people) from spending that same time trying to understand it.
IMHO this is analogous to most of the economic justification for not being sucky at documentation. When you apply this analysis to the user-facing side, an hour of documentation can save hundreds of hours of user thrashing.
This is something that I would assume is intuitive, but under the capitalist mode of software development, it seems to be an uphill fight to get the economic rationale into management's heads. There are of course exceptions, and they stand out in excellence.
When you shortchange documentation, you're externalizing costs that shared efficiencies say should be internalized. Kind of like dumping sewage in the lake, or driving on leaded gas.
I don’t think that is specific to Amazon. If anything I think the whole paradigm of “over analyzing communications with vacuous update suggestions that don’t matter” is probably the most consistent thread I’ve found in all of corporate America. I’ll never forget early in my career we had huddled around a coworkers computer with our entire team including senior manager writing an email to a VP and the senior manager was making punctuation and the most inane wording updates you can imagine. I once thought there is no way the absurdity of the cost to benefit of that situation would be topped, but how naive I was - turns out generally companies seemingly can’t avoid that kind of atmosphere.
The songs demand a camp fire
I've seen mixed results with reading the document during the meeting. It can help with people not having read the document. But people read at different paces, and the people who put off or avoid reading before the meeting are doing so because they are slow readers or have poor comprehension or retention. Reading has a high opportunity cost for them, so they avoid it.
Asking them to read during the meeting usually results in a performance, they skim or get through as much as they can until people start saying they are done, and then they don't want to hold things up so they also announce they are done. This can happen with all slow readers, even those who would have high comprehension with multiple passes or at their own speed.
The other issue is the asymmetry of effort, which the author alludes to with "no doc => doesn't happen". Proposals require writing, but criticisms can be made verbally. You would expect a lot of the feedback to actually make the proposal worse because the proposal has been through a few write-edit cycles and the feedback is generated on-the-spot during the meeting within minutes of first reading the proposal.
If critics don't also have to write then feedback becomes a game of politics. If you ask people to give feedback on something without time to think, you will get noise. No one wants to appear bad at reading in front of their peers.
> the people who put off or avoid reading before the meeting are doing so because they are slow readers or have poor comprehension or retention. Reading has a high opportunity cost for them, so they avoid it.
This sounds like a description of people making bad choices at their jobs despite an obvious correct path (don't put off or avoid prereading). If they'd have high comprehension with multiple passes and at their own speed, it's their responsibility to figure that out and take those. Correspondingly they absolutely have the freedom to hunt down the meeting scheduler if the latter hasn't provided the doc enough in advance for this. (There are a lot of ways that I'd say Amazon culture is unaccommodating of difference, but this isn't one)
> Proposals require writing, but criticisms can be made verbally.
IME, anything that a critic doesn't insist get captured (with an action item and typically their name attached to the feedback) is treated as wind in leaves.
> "...slow readers or have poor comprehension or retention..."
Our entire profession is based on working with text intensively, whether code or docs or specs. Anybody with these difficulties that aren't making the effort to compensate for them isn't going to last long, particularly at Amazon or another FAANG.
I don't disagree that reading comprehension is essential to be a good engineer. But empirically, many people with a title like engineer or manager or product somethingrather have poor reading comprehension and blend in just fine.
Any process has to take this into account, you can't design a process that only works when competent people participate and incompetent people don't and then blame the incompetent people when it fails. You have to design a process that works despite some number of incompetent participants.
Document cultures do this because writing shines a bright light on the merit of an idea. My criticism is that the in-meeting read through does not have a similar effect.
The reality is that competition at Amazon is intense.
Amazon corporate is roughly broken down like this:
L4: 45%, L5: 45%, L6: 7%, L7: 2.5%, L8+: 0.5%
Only the first promotion has guardrails (L4 to L5). Typically you’re expected to be able to write at all. From there many people end their careers at L5.
Going from L5 to L6 requires being the best person on your team for multiple years running. Compared with some really smart, focused, and motivated people. You’re also expected to be able to write well, read, and kinda poorly coach other people’s writing.
Going from L6 to L7 is very difficult. One of the biggest differentiators really is scale. If you still need help writing docs - that’ll slow you down and you won’t scale. If you’re slow to read and provide valuable feedback again that will hold back scale (many people compensate by adding more time to their work days).
However, the funny thing is the doc writing culture at Amazon is built by and for L8+ leaders. Everything else was just training and weeding people out.
Going from L7 to L8 is where “in-meeting reads” really start showcasing the differences between leaders. I’ve known smarter people that made better decisions but had their careers stagnate while watching other “80th percentile” decision makers grow because of speed to grok information and deliver valueable feedback 9 of 10 times is more important than the incremental benefit of being right 10 of 10 times.
So I get your concerns about in-meeting reads throughs but just keep in mind who and what it is defacto built for.
> "...you can't design a process that only works when competent people participate and incompetent people don't and then blame the incompetent people when it fails."
That reads like something straight out of a Dilbert comic strip. Yes, employers can require that software engineers not be incompetent; that's what they're paying for. If a process reliably reveals their incompetence, that's actually a huge positive because then appropriate corrective measures can be taken.
To me, reading a document in a meeting that was supposed to be read beforehand is unprofessional. It’s creating a culture that says it’s ok to disrespect other people’s time by not being prepared. Meetings are already quite expensive.
> If you ask people to give feedback on something without time to think, you will get noise.
Insightful. I have also observed that such processes induce more noise as participation (regardless of having a good effect) becomes the thing that managers notice for promotion/ demotion.
Fwiw at Amazon it’s expected that the first 33%-50% of the meeting is reading time.
The rest is time for feedback, discussion, and ideally a decision or collecting action items.
Discussed earlier (2021, 215 comments): https://news.ycombinator.com/item?id=27545331