Justin Garrison
March 15, 2021

The Document Culture of Amazon

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:

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

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

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

Follow me

Here's where I hang out in social media