Hacker News Reader

> 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.