Writing memos

As a technology leader, communicating clearly with both technical experts and business partners is essential. Whether it’s writing technical documentation, crafting a presentation or speaking in public, communication is a huge part of an engineer’s job and a significant factor in how well they will succeed inside an organisation. In particular, being able to convey information in a written form, like a narrative memo, that is then read and debated with all stakeholders, has been proven to be a key part of Amazon’s success.

On June 9, 2004, at 6:02 p.m., the Amazon STeam received an email from Bezos with, like most Bezos’ communications, an unambiguous subject line: “No powerpoint presentations from now on at steam.”

Since that now-famous email, powerpoint presentations (and any verbal communication) have been replaced by 4 to 6-pages narrative memos. Before a meeting, participants have 20–25 minutes to read the memo from beginning to end. During this time, most people write down questions or feedback directly on the printout. After this “study hall” reading session, everyone in the room challenges the project owner’s position, questioning their tactics and digging through the data to make sure it is valid. The project owner needs to have everything prepared ahead of time as there is no ideation or brainstorming during these kinds of meetings. But why is a narrative memo much more efficient than a discussion of a presentation?

Writing brings clarity

In his introductory course on writing effectively, Larry McEnerney, the Director of the University of Chicago’s Writing Program, shares that unlike journalists or novelists, experts like scientists and business leaders use their “writing process to help [themselves] think.” If you’ve tried to write a blog post or a long-form essay, you know what McEnerney means. When conveying a complex idea in writing, the medium “forces” you to be much more structured and argumentative than a discussion.

During a discussion, you have the opportunity to hear the other person’s feedback or questions, even monitor their body language, and rephrase your point until the other person understands. But in writing, you’re cut from the other person(s). You don’t get their feedback (at least not immediately). You can’t monitor their body language. So you have to anticipate any possible questions and make the most explicit possible points.

What’s interesting about this process is that it helps you discover flaws in your reasoning along the way, without emotions. This is extremely important for entrepreneurs and any leaders who are very good at convincing others orally. I remember several occasions where I convinced my team of ideas that ended being absurd when writing them after the meeting.

You can also use this technique to deal with technical problems. Instead of asking a “quick” question to a colleague and interrupting their flow, writing it down (or talking to a rubber duck) can help you solve your problem.

Why the narrative is important

According to Bezos, “the reason writing a 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related.”

In the above quote, the most important and often overlooked word is “narrative”. Unlike bullet points, a narrative accounts for a series of related events or experiences, revealing how one impacts the next. Narratives can be straightforward, like in the past it was like this… then something happened… so now we should do this… so the future might be like this…

When writing a memo to introduce a new project (for example, a new feature for an existing software), the narrative could look like this:

Introduction: background information about the software or service and the users (or subset of users) we’re developing the feature for
Problem: what has changed (or what was discovered) so that users are now experiencing a new problem that needs solving
Solution: here is what we want to build and why we believe it will solve the users’ problem
Challenges: everything that could prevent this solution to be a success
Goals: what we want to achieve and how we will measure success
Conclusion: how the future will look like

Everything Starts with a Merge Request

Since 2004, many companies have embraced written communication by default. Twitch, now an Amazon subsidiary, the 6-pager process is used a lot, but instead of printing and reading, team members debate projects digitally. At GitLab, even proposals for new internal processes are done and then debated through merge requests. Basecamp also uses a similar process for new features, called the pitch.

The common point in all these examples is that asynchronous, written communication is better than synchronous live meetings. Many leaders believe that putting the best people in a room will always end up with the best or most innovative solution. This belief is so anchored in business practices that brainstorming, and all by-product techniques, is the de facto standard for solving problems. It is, unfortunately, not. During a live session, especially if all the facts were not shared and absorbed before, participants might make uninformed contributions based on hunches. Some people (like me) also need time to formulate sound arguments and keep silent instead of participating. Giving everyone time to read, comment and debate in writing, ensures that everyone can contribute with excellent arguments so that leaders can make more informed decisions.