RFCs: The Most Underrated Skill in Software Engineering

How writing down your decisions sharpens your thinking, improves your PRs, and grows your technical influence

How much time do we waste re-explaining decisions we already made?

How much easier would things be if those decisions were written down, clear, and useful for whoever joins later?

In today’s email, you will learn how to stop your technical decisions from disappearing into Slack threads and endless PRs.

The real problem: technical decisions that disappear

Most problems in software systems don’t come from syntax errors.

They come from forgotten reasoning:

• A decision is made on a call.

• Someone summarizes it in Slack.

• Three months later, nobody remembers why that path was chosen.

Then someone proposes a “better” solution.

And the debate starts again.

Rework. Friction. Endless PR comments.

👉🏼 RFCs are the antidote to collective technical amnesia.

They create memory.

What an RFC actually is in your day-to-day work

Forget Internet standards.

In your team, an RFC is simply a short, structured document that explains:

• Why this change is needed

• What is being proposed

• What trade-offs exist

• What could go wrong

That’s it.

👉🏼 It’s about raising the quality of technical thinking before code is written.

And that alone changes the level of conversation.

Why writing RFCs builds authority and helps you persuade

☝🏼 Let’s be honest: Authority in engineering does not come from seniority alone. It comes from clarity and transparency.

Writing RFCs builds both in public.

👉🏼 You demonstrate structured thinking and invite participation.

Anyone can have an opinion in a meeting.

Very few people can:

• Clearly define the real problem.

• Separate assumptions from facts.

• Lay out alternatives.

• Explain trade-offs.

• Anticipate risks before someone else mentions them.

An RFC forces you to do exactly that.

And there’s something even more important: Many technically sound proposals fail because they arrive fully baked. When developers are not involved early, they don’t feel ownership. And when people don’t feel ownership, they resist.

👉🏼 Sharing an RFC as a draft changes the dynamic. It becomes a conversation instead of a decision announcement.

When you should write an RFC

☝🏼 Not every change needs one.

But write an RFC when the decision:

• Changes the architecture.

• Introduces a new or expensive dependency.

• Modifies a public API.

• Affects multiple teams.

• Has long-term impact beyond a single ticket.

👉🏼 Just to give you a real example: The last time I wrote an RFC was to propose how to implement the AGENTS.md framework in the repos of the Engineering Organization.

From AGENTS.md to sub-agents: structure and best practices

Now, an important part.

How to handle feedback without turning it into an opinion war

☝🏼 RFCs don’t eliminate disagreement but they structure it.

To deal with this situation, a few simple rules help:

• Separate facts from preferences.

• Set a time window for feedback.

• Escalate only when needed.

• Document the final decision clearly.

And one important principle: No silent vetoes.

👉🏼 If someone blocks the proposal, ask them to write a counter-proposal using the same structure.

Where to write RFCs

I like to use Git to publish my RFCs because I find it a good tool for:

1. Reach my audience, a.k.a. developers.

2. A Pull Request permits comments and contributions.

So, if you want to start writing RFCs, my suggestion for you is:

• Create a new repository.

• Where the README.md file explains what the repo is and how to create RFCs.

• Also, you will have an RFC template that the people can (must) use to contribute their RFCs.

That’s it!

So far, you have some clarity about the RFCs. Now, let me give you the template I’m using nowadays. Click the button below to receive it for free 👇🏻

✨ Summary

RFCs are not ceremonies. They are not corporate theater. And they are definitely not paperwork for the sake of process.

They are thinking tools.

They force you to slow down just enough to clarify the problem before jumping to the solution. They turn opinions into arguments. They transform isolated ideas into shared decisions. And over time, they build something most engineering teams lack: technical memory.

Writing RFCs will not make your code compile faster. But they will make your decisions stronger. They reduce friction. They create alignment. They make discussions sharper and shorter. And they make your reasoning visible.

And, look:

• If you want to grow as an engineer, keep writing code.

• If you want to grow in influence and authority, start writing decisions down.

Hope you enjoy today’s email. I know I made some bold arguments, and I hope you consider them when you plan your next proposal.

---

Thanks for your support and feedback, I really appreciate it!

You’re the best! 🖖🏼

𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!

𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴