Hacker News Reader

Comment by planckscnst | Hacker News Reader

When I joined, I was perplexed by this way of operating meetings. It surprised me greatly that people wouldn't want to read the doc at ahead, give it time for thinking and researching, and then come to the table feeling prepare to contribute to the best if your ability.

Now, I understand and deeply appreciate this method. I believe it provides lots of benefits. It drives towards better docs that can be understood quickly by non-experts. When there are just a few minutes to review the doc, we don't have time to go digging for information on our own - the critical information must be provided in the material given. There will also be SMEs in the room who can clarify any shortcomings here. Because the audience of the docs is non-SMEs, it drives towards inclusion of other teams. From this, you get more diverse viewpoints, considerations, and experience. It also contributes towards cross-team awareness and education. It makes it much easier to participate as a contributor to the meeting while simultaneously less impactful when you don't. It let's us timebox our attention span - you won't accidentally spend hours rabbit-holing into a doc.

View on HN

I miss many aspects that are the byproduct of this particular Amazon process. Namely:

- it’s also a very email heavy culture, yet I had zero anxiety about what might still be sitting in my inbox unread as I went to a meeting. If it was important pre-work that was required for the meeting we all did it together at the start of the meeting. There was no expectations to have caught up on context prior. - the format was very empowering both as an author and a consumer. As an author the constraints meant you didn’t have to worry so much about the audience or the structure and instead it was a more pure focus on content. Likewise as a reader you quickly build a muscle for how to consume it rather than second guessing if there’s going to be some grand reveal or how a story is building. - it was also nothing short of inspirational being able to observe very senior leadership coming in to a read on something. Near zero previous context about local challenges, the particular business space or problems we’re discussing, and every single time they’d gone straight in on a fundamental issue others had missed or something that seemed inconsistent across the data presented that warranted a closer look.

Agreed on every one of these points. Especially with the inspirational aspect of seeing veteraned industry leaders and principal engineers come in fresh and have questions and misunderstandings. It's given me the courage to be wrong or confused and ask questions. I've also admired a few people's ability to advocate for shared principals and express how this relates to them - especially customer obsession

Funny I literally tell people when they join my team that email is the worst way to get my attention. You have a guaranteed slice of attention from me if you schedule time. If you email me you're spinning the wheel and if what you are sending me isn't that important, I'll get to it when I can.

> I’ll get to it when I can

Sometimes that is what I want: the non-urgent attention of a relaxed person who can think more deeply about a problem.

I think you're missing one of the biggest features.

Do you really think that most L8s have time to read your doc, let alone Jeff or Andy? Their calendars are all completely booked. Asking them to read the documents before the meeting without scheduling the hour for them just means that doc is not going to be read. It's also asking them to value your document over their other obligations and their personal time. Most L8+'s and especially Andy/Jeff are just wall to wall doc reviews and decisions.

Putting the time in the meeting is the respectful thing to do for other people's time. I'm a PE (L7) and I have to ask people just to book an hour for me for docs to read otherwise it just won't happen, someone else who does use my calendar will take that time instead.

I'm an Amazon product leader and I agree 100%, I'm already in back to back meetings all day long, emailing me a doc to read "in advance" puts all the stress on me. I'd rather you put time on my calendar and let me read quietly, and let me give you immediate feedback rather than me having to draft yet another email in reply to poorly explain my questions and/or my ideas.

I also block time in my own calendar, I have to write, a lot, and I have to work with my team on docs and other outputs. I block my calendar for those times, if you want me to read you know clearly when I have time to read with you, just grab a free slot on my calendar (in my timezone please lol). I am happy to provide the time, enjoy learning new things, enjoy sharing my thoughts, and often I can help find the right next person to read with you, or sponsor a leader to read with you.

Now all this said, I do find it a bit intense, to read "on the spot" and provide feedback, that said I will often provide feedback and suggest a follow-up meeting so I can noodle on the topic some. Meanwhile the author can spend time getting other input, improve the doc, and come back with a stronger story.

The best part for me: On-boarding!

When new people join I share major docs that were important to my team's plans, and some of them date back several years! I can share the doc with the new hire, ask them to block time for read + Q&A. It saves time getting them up to speed on our thinking, and we can discuss "so where are we on this journey" rather than spending time telling the full story for the 1,000th time.

When I joined Amazon I was an "Orator" style product manager, I would "tell the story" over and over, sometimes with some power point. And it was successful, however I feel like me and my teams are many times more successful with a strong doc process. And in the end decisions are memorialized, we don't have to go back and hash them over and over.

I was an entrepreneur for 25 years of my career, and CEO all those years. At Amazon I feel like I get the best of both worlds, the ability to innovate, invent, and the ability to do it at scale without pitching 100 VC's my next idea.

Interesting the way you termed docs as useful for Onboarding. I've found myself doing this a lot with our new SDE/SDM/PMs when they come to me for advice on how to propose initatives. I usually send them a top hits list and tell them which doc is appropriate for what scale / audience. Thanks for giving me a better way to phrase this!

That's pretty counterintuitive - surely if I book half an hour on your calendar and ask you to take half an hour beforehand, isn't that being more respectful of your time than booking an hour on your calendar? Surely in the worst case you could achieve the same thing by blocking out the half hour immediately before my meeting yourself, but you gain some scheduling flexibility as well.

If your schedule is busy enough, you may literally not have half an hour free between now and the half hour being booked. Calendar UIs are pretty good at making it clear whether you're finding an open one-hour slot and less good at making it clear whether you're finding an open half-hour slot where there's a free half hour at some prior time. And they also won't put a hold on that half hour, so multiple people might send meeting requests that implicitly expecting the same prep window.

You can potentially build a culture where it's normal for the recipient to decline invitations if they can't find a prep time, but it's much more coordination overhead.

Also, there's an advantage in having the document fresh in your mind, instead of shuffling into a meeting with people grabbing sodas etc. and immediately hearing "So, any comments on section 1." (The article mentions this: "Some people read the document but forgot what it said because they read it days or hours before")

Maybe another way to put this: "respectful of time" does not mean allowing the recipient to cram as many things as possible into their working day; it means allowing the recipient to decide how many things they can pay full attention to. If they don't have a full hour to dedicate, the better answer might be "Let me find you someone else who can provide you feedback" (or declining some other commitment in order to prioritize your document) instead of showing up for half an hour.

I’m a director level person — anywhere from 60-80% of my working hours are allocated in advance, and I have a hard limit where I stop working. So time is precious.

So if your expectation is that I’m doing work to prepare for your meeting, you best be confident that it aligns with my priorities and make that expectation clear.

It’s often a rude awakening for new PMs and salespeople. Lazy people, or people who have worked for micro managers, like to push trivial decisions up for various reasons.

Book an hour because that’s how much time you’re actually asking for. Don’t additionally give someone with a busy schedule the task of booking another appointment on their own to prep.

I think the key insight is that if you have some free time. Being able to schedule your prep is convenient. If your day is going to be packed full 110% of the time anyways then you may as well let the scheduler of the meeting schedule your prep at the same time.

But I have always thought it would be nice to be able to have calendar constraints. Some simple like "I need 1 contiguous hour for lunch between 11 and 15" to more complex "I need travel time between meetings" to automatically rescheduling meetings across people to avoid fragmentation issues. This could be a potential additional constraint. "This 30min meeting requires a preceding 30min of prep". This would be more flexible to schedule so could help busy schedules align. Then every day before I leave the tool can stabilize my schedule for the next day, any maybe I end up doing tomorrows prep today to allow things to bin-pack better.

I don't have an hour before hand. Just book the time on my calendar and you don't even have to show up, gcal lets you do this. This is how I get most of my document reading done for people. Sometimes I find other time to do it. Sometimes I don't. But having the person show up and code on their laptop while I read makes me really feel guilty, so it guarantees I don't get pulled onto something higher priority (this happens to me a lot).

Also if the person doesn't feel it's worth their time to do me the favor of making the appointment or to get my feedback, then are they really going to listen anyway, or are they just having me review it because their manager said they had to?

It sounds like I would have a distinct disadvantage if I was at Amazon. I am a slow thinker, and questions and ideas often come to me a day or so after reading some document. If I had to come up with all my responses within 20 minutes, I'd be effectively cut out of the conversation. Maybe that means I'm not L8 material.

The effective ICs that are that high level get involved in the whole doc process earlier than The Final Review anyway; people are collaborative about those before The Official Meeting, and asking to take a pass at the doc before The Review With So-And-So isn't weird.

It is said in the article that documents can be provided early. So you could read the stuff twice, first the day before so you have the time to think and then at the meeting to refresh your memory. So no, you probably won't have a disadvantage because of your careful thinking.

I found printed documents to be much more helpful than using Quip (or WorkDocs).

Quip / WorkDocs means you start getting comments, highlights and other things from people -- which are then visible to everyone else at the meeting.

If there was a way for you to personally highlight your concerns during the read-through and then the presenter could display them all at once that would be great.

By not having that ability, it tends to mean the person with the "most authority" has their comment taken seriously and addressed straight away -- just like having the "loudest voice" in a meeting works against allowing everyone to contribute.

I actually prefer the online docs format as there's usually a bunch of things people jump on, and if I see someone commenting on that, I can keep reading and get further down the doc (better coverage).

When I did doc reviews on paper, I found everyone would find the same weak point in the first paragraph and would miss getting to the end of the doc.

Another major benefit, esp for junior employees, is the person who wrote the doc does not have to take as many notes, they're all in the online doc. Meetings full of senior folks tend to have TPM/PMs in the meeting who are playing notetaker. But junior folks are defending their thesis and taking down notes, it's just a lot to do. Online docs makes that a lot easier.

As I've had mentors say... if you find issues in the first part of the doc, what are they hiding at the end... Save your questions till you read the whole thing.

Understood that with printed docs multiple people may start commenting on the same points, however, the discussion happens only once still.

I personally find that many of the comments showing up with online commenting are not worth, and they don't even get acted upon. What's lost in the process are good comments amongst the sea of them.

Notetakers should be capturing the key points anyways. Large number of online comments is perhaps even worse than meeting summary notes with a raw listing who said what.

I'm with you on filtering out the key points. But I felt I had to do that in paper meetings as well. I have no real issue closing out comments after the review.

I've also started making heavy use of suggestions instead of comments for minor edits... I spend a lot of time doing grammar and phrasing stuff on early release documents. This feels more like collaborative editing.

Both paper and online docs are a lot better than sending around word docs with track changes on tho.

+1 overall.

>> I'm with you on filtering out the key points. But I felt I had to do that in paper meetings as well.

Agreed. Even for the verbal discussions after paper meetings, the law of triviality still usually applies. https://en.wikipedia.org/wiki/Law_of_triviality

Just that it has become worse with online documents.

>> I have no real issue closing out comments after the review.

+1.

>> are a lot better than sending around word docs with track changes on tho.

I agree, collating feedback from multiple Word documents is a lot harder for accommodating the smaller comments (i.e., those comments which should be handled later offline).

It would have been ideal if (online) document review tools had the following features:

(a) Allow the reviewers to mark their own comments on importance. I would find this useful even as a reviewer so that I can bring up only the important points into the verbal discussion. It would also be helpful if I can mark some comments as intended for myself only.

(b) Submitting the key comments first (using 'a' above), subsequently the remaining ones after the meeting.

With online commenting, comments show up even before they have read the whole document which partly defeats the purpose. Often the comments are already addressed later in the doc.

With printed documents, the audience naturally brings the most important comments first, and many less important ones would never come.

I personally prefer to send documents by email. Everyone has their own copy in which they may put comments, but what comes back in the meetings are only good comments.

The other side I heard from someone who worked at Amazon:

The SMEs read critically and take the full time. The PMs skim it and start pitching whatever idea comes first to mind.

If someone is wasting time in a meeting on tangents unrelated to the goal of the meeting, the person running the meeting has every right and obligation to shut down the tangent.

This is a problem regardless of the document culture. If anything the document culture gives you an objective standard that makes it very clear whether a line of discussion is on topic.

I agree 100%, I'm a product leader at Amazon, and if a meeting goes off the rails we will say "let's take that offline". I even inject things from my background and end it with "let's connect offline". I've even told leaders higher up in my management chain "Let's not solution this here, we can schedule time for that if we agree on next steps". They don't mind, we're all busy, often very excited about what we're reading, and in free-flow feedback mode.

It's easy to get excited and run off topic a bit. Brining it back in actually shows a respect for everyone in the room. Not everyone in the meeting is interested in the random off the rails thread anyway, schedule a follow up and get the meeting back on track.

> Let's not solution

Ah, corporate language :-)

Let's not solve this, solve.

When you are in a room with Solution Architects.. what do you say.. use the vernacular of your audience.

Former AWS SA Manager here, my team had a standing joke about dissolving the problem.

I guess they should be renamed to Solve Architects, then :-p

To Solution = Discuss options, tradeoffs, identify next steps, working towards a possible solution.

It's a transient state that leads to a solution eventually but not necessarily by the end of the first discussion

To Solve: To identify a definitive solution immediately.

Sure, you're not wrong, it's corporate-speak. But it does have some nuance.

or even worse solutionise/solutionising.

Conversating

When you begin to enforce such rules is when you know the culture is going to shit.

The act of “shutting down a tangent” will be seen as hostile and a grudge is created. Hurt parties will refuse to or be difficult to cooperate with. Your culture can survive only if there’s a shared commitment to it and people feel like they belong.

Perhaps you would want to shut down “politely” and it’s an art to do it without embarrassing the receiving party? But that means that only people with such political skill/power can take that action.

I think it's pretty easy to politely shut down tangents.

"Thanks for raising that. In this meeting I want to focus on X. Why don't you start an email thread with <whoever> or setup a time to discuss this later."

Meeting is about X. If someone rolls in and only wants to talk about Y they are one or more of these things, a) clueless, b) unprofessional, c) disrespectful of others time.

But what typically happens is people get excited and have ideas. That's great, but focus is key and people need to be reminded.

TBH, I don't even see any art in shutting it down. I get excited about ideas and can head off on tangents. The meeting runner (or anyone else) should call me out, and get us back on track. And when this happens, I apologize and thank them for the reminder.

Pal, it's like meeting 101, the only people possibly get butthurt about this are those with zero work exp

Um this happens all the time, and you know what, usually the people involved in the discussion realise it is the wrong forum and it is one of them who will suggest 'taking it offline' so as to not waste everyone else's time.

Not in my experience. I value it hen someone realizes that a discussion path left to its own will not help with the goal of the meeting and then asks to have that discussion in a different channel. This is true when I was contributing to the distraction as well as when I was wishing we could get back to the meeting's purpose

I can picture this so clearly it’s painful.

To be clear, it’s very possible that both these perspectives can be true simultaneously. Big corps are one in name only, different divisions could be different companies and thus the variance in experience.

The PMs are often SMEs of related concerns and own stakes in the new idea being discussed

PM prerogative. Same as it ever was.

I’m at AWS and the doc focus meetings is my favorite cultural force of working there. I was surprised to see the article leave out the benefit to author of forcing them to clarify their thoughts and get evidence to support their claims. I am always way more prepared to discuss and defend my proposals after writing a document, even if I thought my idea was pretty clear before writing it.

A drawback, if you want to call it that, is it can be exhausting. Both on the consumption side when you have to review lots of deeply technical and nuanced things all day and be on your A game, or in having to constantly write documents. As I’ve gotten more senior it has taken the largest part of my time now. It also seems like a lazy answer from management can be “well write that up in a doc and we can review”. Feels like you can’t discuss anything without a doc sometimes. But still love it, net net.

What's an SME?

Engineering jargon for "Subject Matter Expert".

Is this common across the industry, or mostly used at Amazon? I’ve been a professional software engineer for 20 year and read a lot of HN, but I think I haven’t seen this particular acronym around much (I think I would usually call these people “domain experts”).

The term "SME" is common in engineering. It is equivalent to "domain expert".

Yeah - I’m nowhere near Amazon but I’ve heard it, even been called it more than once. In my experience it’s not a title, so much as a role in a particular context. Like, I could be GM of billing - and therefore in a meeting I might be one of the billing SMEs.

I worked at Nielsen (TV Ratings) 3-4 years ago and we used it all the time and not for tech. At the time it was used by all he major Entertainment Studios in Los Angeles as well. Any type of office role it: Marketing, Mathematician, Software and Data Roles, ...

Never used it at small companies so it seems mostly used at larger companies or relatively new.

This is commonly used in the Hr, accounting, finance, and logistics teams in retail companies I’ve worked at that aren’t Amazon. In my experience it’s not uniquely an engineering term.

Same here, 25 years writing software, never heard it, even working in the Bay Area.

I got a pretty large number of upvotes on the three-word post above so I think the term is common in some circles, unheard of in others. Someone should map it somehow.

Map it somehow? What do you mean? There is a Wikipedia entry on it [1] that is a start.

To your point, maybe there needs to be an HN glossary of terms or something like that.

[1] https://en.m.wikipedia.org/wiki/Subject-matter_expert

I mean map which companies use this SME acronym and which don't, similar to how "soda", "pop", and "coke" map to different regions of the USA.

My hunch is it comes from companies that use PMI project managers. Maybe that maps to older non-tech companies, but I have no proof to back any of that up.

> never heard it, even working in the Bay Area.

I think SME is would be less common in the Bay Area. I tend to associate it's usage with older, less computer tech first, companies.

Subject Matter Expert

More than anything it actually gives people time to read the document. Time doesn't come from nowhere, especially for people higher on the ladder. It's always good when its purposefully scheduled, rather than expected.

What happens if a document does not deliver the data and too many things are unclear? Like too many questions appear and the while meeting is becoming unproductive?

Typically you get that feedback, in a very clear and positive way. I've never felt like someone was putting me down when my doc was not answering the questions.

The goal of a doc is not to show how smart you are. The goal is to expose the truth as "We" know it and expose it to critical feedback to dig deeper, or decide we have enough to make a decision.

If it's an important meeting, it's expected that you've gone through previous reviews with other people who would've given you that feedback

If there are issues that have not been caught until that important meeting, you'll get feedback to come back with the concerns addressed

Reply on news.ycombinator.com