Posted on March 15, 2021  •  6 minutes  • 1257 words

In my time at Amazon, I’ve observed the way we use documents is incredibly unique. A lot has been written about the six-pager and PR/FAQ so I’m not going focus on document formats, but I wanted to share how our process benefits from document-based meetings. I also have identified some areas for improvement if you are looking to adopt document-based meetings for your workplace.

I’ve been wanting to write this blog post for a while and Jaana’s tweet finally gave me the inspiration to share my thoughts.

My role is a Sr. Developer Advocate within AWS Container Services so my experience may be different from other areas and roles at Amazon. A majority of my meetings start with reading a document. This takes “this meeting could have been…” and flips it upside down. Most of the time, if there isn’t a doc there isn’t a meeting.

Depending on the meeting, the document could be a six-pager, a PR/FAQ, a one-pager about an idea, a narrative to help find a solution to a problem, or even a service review full of charts, graphs and bullet points. The document adapts to fit the audience and purpose of the meeting.

Reading documents is so ingrained in our culture and process that our scheduling tools have check boxes to automatically create a document. If I’m catching up on a new service or feature launch, I will find the document rather than emailing or calling the product manager.

The interesting part to me isn’t in the format of the document, but how it is used. Meetings start with reading. Depending on the length of the document, we’ll read anywhere from ten minutes to half an hour. If the meeting has a long document (six-pagers are the longest) and many attendees, the meeting will be scheduled for enough time to read and discuss.

Reading the doc is part of the scheduled time. I’ve worked at plenty of places that I’ve tried to document everything for a meeting ahead of time. I’ve written well thought-out emails, shared links to documents, and written detailed wiki pages. In all of my meetings outside of Amazon I had one of three outcomes:

• No one read the email/document and I had to explain everything in the meeting
• Some people read the document but forgot what it said because they read it days or hours before
• At least one person had a question that I could have answered via email

Before I started at Amazon these were some of the expected benefits to reading in meetings.

• All of the information for the meeting is contained in the doc
• People are not expected to find their own time to read
• The document is fresh in everyone’s mind

Some other benefits I’ve found while putting it in practice are:

• Presenters, including myself, don’t have to feel nervous about presenting in front of people.
• Documents help eliminate many biases, for or against, the person who wrote the document.
• You read everything in your own voice and vocal communication barriers such as accents, vocal ticks, or handicaps (e.g. stuttering or hearing loss) are not present in the document.
• There’s no “can you see my screen”, background noise, or call audio disconnects while understanding the main content for the meeting.
• There’s a wealth of current and past documents. Want to see what the PR/FAQ looked like for Amazon EKS or AWS Lambda? It exists.
• You are not expected to retain document information outside of the meeting. Feedback and discussions happen during the meeting. Comments can be answered asynchronously. If more discussion is needed then the document will be revised and a new meeting will be scheduled to read and discuss it.
• If a document is provided early and I have a conflict at the begining of the meeting I can read the document ahead of time and join the meeting 10-20 minutes late without missing anything.
• Document reading from home has been a great way to get 10-20 minutes of exercise in.

There are some limitations to document based meetings. The first I have noticed is if you’re not a very good writer you will be at a disadvantage communicating your ideas. Amazon has a lot of internal training to help you write good Amazon documents, but even with training it still requires a good foundation. I’m very thankful for my years of practice writing for How-To Geek and Cloud Native Infrastructure . Even with that background, my first one-pager review was intimidating.

I’ve been told “if there’s no document, it doesn’t get done.” This includes meetings. If there’s no document, we cancel the meeting.

While documents can create a more level playing field it’s also a high barrier to entry. Even for small ideas, features, or iterations the first thing you will likely need is a document. My perspective may be skewed because in my current role I don’t write production service code, but I do affect features, design, and positioning of the services. I have a lot of feedback and ideas, but I don’t implement them.

The available wealth of historical documents can be enlightening to read through, but it also can be confusing to trace the lineage of a service with a plethora of documents and comments. I have caught myself more than once reading a document which I thought sounded similar to an existing service only to realize 20 minutes later the document is for the service and I didn’t look at the date of the document or I didn’t know the product code name.

I have the benefit of working with the service teams and providing direct feedback about new features and services. Most documents I read are very interesting. Many teams at Amazon don’t have direct product input. However, they’re still required to write documents to communicate plans with their team. Not all docs are interesting, but they are crucial to the decision making process.

I’ve said multiple times that Amazon has the foundation for a great remote-first company. The document-based process provides employees in multiple timezones the same context as someone in Seattle. The discussions in meetings enable faster feedback loops, but the downside is they can limit the potential for asynchronous engagements if notes and questions aren’t captured in the document.

I’ve never had the benefit of attending an Amazon meeting in person. From what I’ve heard document-centered meetings have been extremely successful in transitioning to remote requirements. But the content isn’t the only thing that matters.

Amazon, like many large organizations, uses a lot of tools to communicate. It’s often difficult to find documents spread across so many tools without an ability to cross search or centrally organize them. I could see how a tool like Command E could help a lot. This can be additionally difficult with the multitude of open source and social platforms I engage with on a weekly basis. I currently have a user in 53 Slack workspaces. 💀

Even with areas that could use improvement I can’t think of a place I have worked that wouldn’t benefit from document-based meetings. I’m sure with more practice I will get better at writing with a more Amazonian style.

I thoroughly enjoy not having to prep for meetings, because I’m confident the document will give me the context I need to participate. I know the person who called the meeting invested their time so they don’t waste mine. I reciprocate the same thoughtfulness with meetings I create and documents I write.

Thank you everyone who reviewed this document. ☺️ Banner image credit pixbay