Writing That Gets Things Done: The Async RFC & Memo Framework
A meeting starts with eight people, one presentation, fifteen open questions and a familiar sentence:
“Maybe we should discuss this further.”
Two weeks later, everyone has attended another meeting, but nobody is completely sure what was actually decided.
This is one reason asynchronous written communication at work has become such an important professional skill.
Good writing does more than communicate information. It creates context, exposes assumptions, documents decisions and gives people enough time to think before responding.
For engineers, product managers, project leaders and business professionals, two formats are particularly useful: the RFC (Request for Comments) and the decision memo.
They are not replacements for every meeting. Instead, they give teams a structured way to handle decisions that benefit from careful thinking rather than spontaneous discussion.
Why Asynchronous Written Communication Matters
Synchronous communication requires everyone to be available at the same time.
That works well for emergencies, brainstorming, sensitive conversations and situations where immediate back-and-forth is genuinely valuable.
But many workplace decisions do not require everyone to be online simultaneously.
A well-written document allows someone in Bengaluru to review an idea while another teammate in London is offline. A third person can read it the next morning and leave questions without asking the entire team to schedule another call.
GitLab, for example, describes asynchronous communication as a starting point and emphasizes documenting conclusions so they become a shared source of truth.
The real advantage isn't simply fewer meetings.
It is better thinking before the decision is made.
What Is an RFC?
An RFC, or Request for Comments, is a structured document used to propose an idea, technical change, product decision or system improvement and invite feedback before implementation.
The term has deep roots in the internet engineering community. The RFC series began in 1969 and became an archival record for documenting technical specifications and engineering ideas.
Modern engineering teams often use the concept more broadly.
An internal RFC might propose:
A new software architecture
A database migration
A new API
A security process
A product feature
A change to an internal workflow
A new infrastructure system
The important point is that an RFC is not simply a technical document.
It is a decision-making tool.
A good RFC explains:
What problem are we solving?
Why does it matter?
What are we proposing?
What alternatives did we consider?
What could go wrong?
What feedback do we need?
That structure makes discussions more productive because readers can challenge the proposal rather than spending the first 30 minutes trying to understand it.
The Amazon Memo Structure: Why Narrative Can Beat Slides
Amazon provides one of the most well-known examples of narrative business writing.
In its 2017 shareholder letter, Amazon described its practice of using narratively structured six-page memos instead of PowerPoint presentations, with participants silently reading the document at the beginning of meetings.
Amazon CEO Andy Jassy later described the same working norm, explaining that the company moved away from PowerPoint because highly summarized slides could be easier for the presenter to create but harder for the audience to understand deeply.
The lesson isn't that every company needs six-page documents.
The lesson is more useful:
If an important decision requires explanation, write the reasoning down.
A slide can tell someone what you want to do.
A strong memo can explain why.
That distinction matters when decisions involve cost, risk, architecture, customers or long-term consequences.
The 5-Part RFC and Decision Memo Framework
Whether you're writing an engineering RFC or a business proposal, this structure gives you a strong starting point.
1. Context and the Real Problem
Start with the problem — not your solution.
Weak:
“We need to upgrade our database.”
Stronger:
“Checkout response times increase significantly during peak traffic, creating delays for customers and increasing the risk of abandoned transactions.”
The second version gives the reader context.
Explain:
What is happening?
Who is affected?
How frequently does it happen?
What evidence do you have?
What happens if nothing changes?
Use real data whenever possible.
Metrics, customer feedback, error logs, costs and operational examples make a proposal more credible than vague statements.
2. Define the Non-Goals
This is one of the most underrated parts of professional writing.
Tell readers what your proposal does not attempt to solve.
For example:
Non-goals:
We are not redesigning the mobile application.
We are not migrating cloud providers.
We are not changing the existing authentication system.
We are not solving every database performance issue in this project.
Why does this matter?
Because large discussions tend to expand.
A document about improving website performance can quickly become a discussion about hosting, design, analytics, mobile development and even company strategy.
Non-goals act as a scope shield.
They keep the conversation focused on the decision that actually needs to be made.
3. Explain the Proposed Solution
Now introduce your recommendation.
Don't simply write:
“We should implement a new architecture.”
Show the reader how it would work.
A useful structure is:
Step 1: Current State
Explain how the system or process works today.
Step 2: Proposed Change
Describe what will change.
Step 3: Implementation
Explain the major implementation stages.
Step 4: Measurement
Define how success will be measured.
Step 5: Ownership
Identify who is responsible for each major component.
For technical proposals, diagrams, API examples, workflows and architecture drawings can make complex ideas significantly easier to understand.
For business proposals, timelines, responsibilities and measurable outcomes may be more useful.
4. Compare Alternatives and Trade-Offs
A professional proposal should not pretend that its solution is perfect.
Show readers what else you considered.
For example:
This is where critical thinking becomes visible.
Instead of saying:
“Our solution is the best.”
Explain:
“We considered three approaches. This proposal prioritizes X because the project currently values A and B more heavily than C.”
That gives stakeholders something concrete to evaluate.
5. FAQs, Risks and Rollback Plan
Before asking for approval, answer the questions people are likely to raise.
For example:
What happens if implementation fails?
Explain the rollback process.
What happens to existing users?
Explain migration and compatibility.
What is the biggest operational risk?
Identify it honestly.
How will success be measured?
Define specific metrics.
What would make us reverse the decision?
Set clear rollback criteria.
This section is especially valuable for engineering RFCs because technical decisions often have consequences that appear only after implementation.
A good proposal doesn't hide uncertainty.
It makes uncertainty visible.
When Should You Use an RFC Instead of a Meeting?
Use an RFC or decision document when:
The decision is complex.
Multiple teams are affected.
Technical trade-offs need explanation.
People work across different time zones.
The decision needs a permanent record.
Stakeholders need time to research before responding.
You expect disagreement or detailed feedback.
But don't turn every conversation into a document.
Some situations still benefit from real-time communication.
GitLab's own meeting guidance makes this distinction: the organization has a bias toward asynchronous communication, but recognizes that synchronous communication remains useful when it can achieve the desired outcome more efficiently.
The goal isn't “no meetings.”
The goal is:
Use meetings when conversation is valuable. Use documents when thinking and context are valuable.
How to Write More Concisely at Work
Professional writing does not mean using complicated vocabulary.
In fact, strong business writing is usually simpler.
Instead of:
“At this point in time, we are currently experiencing a situation where…”
Write:
“We currently have…”
Instead of:
“It is important to note that…”
Just state the fact.
Instead of:
“We would like to propose the potential implementation of…”
Write:
“We propose…”
A useful editing test is simple:
Can you remove 20% of the words without removing meaning?
If yes, edit it.
Your reader's time is part of the communication problem.
A Simple RFC Template You Can Reuse
When you need to write your next proposal, start with this:
Title
Make the decision or problem obvious.
Summary
Explain the proposal in a few sentences.
Context
What is happening and why does it matter?
Problem
What specific problem are we solving?
Goals
What should this project achieve?
Non-Goals
What is outside the scope?
Proposed Solution
What are we going to do?
Alternatives
What other approaches were considered?
Trade-Offs
What are we gaining and giving up?
Risks
What could go wrong?
Rollback Plan
What happens if the solution fails?
Success Metrics
How will we know it worked?
Open Questions
What still needs feedback?
Decision Required
What exactly do you need stakeholders to approve?
That final section is important.
Don't end a document with:
“Thoughts?”
End with something actionable:
Decision requested: Approve the proposed architecture so implementation can begin on October 15.
The Real Professional Skill: Making Thinking Visible
The biggest advantage of asynchronous written communication isn't avoiding Zoom.
It's making your reasoning visible.
When your ideas exist only inside meetings, they disappear quickly.
When they are documented clearly, people can review them, challenge them, improve them and return to them months later.
That is why RFCs, decision memos and structured proposals are valuable professional skills.
You don't need to become a novelist.
You need to learn how to take a complicated problem and turn it into a clear argument:
Here is the problem.
Here is why it matters.
Here is what we could do.
Here is what we recommend and why.
Here is what could go wrong.
Here is the decision we need.
That is the kind of writing that gets things done.