Building a Culture of Written Proposals in Your Team

You can set up the perfect RFC template, buy the best tooling, and write a beautiful process document. None of it matters if your engineers do not write RFCs. And they will not write RFCs because you told them to. They will write RFCs because they have seen the value firsthand.

Building a culture of written proposals is a behavior change problem, not a tooling problem. Here is how to approach it.

Why Engineers Resist Writing

Before you can fix the resistance, you need to understand it. Engineers who push back on RFCs are not lazy or unreasonable. They usually have one of these objections:

"It slows us down." This is the most common objection, and it is partially true. Writing a proposal takes time that could be spent writing code. What this objection misses is the time saved downstream: fewer redesigns, fewer "why did we build it this way" conversations, fewer production incidents caused by unconsidered edge cases. But you cannot win this argument with theory. You have to demonstrate it.

"I'd rather just code it." Many engineers think better in code than in prose. Writing a design document feels like translating their thoughts into a foreign language. For these engineers, the RFC process needs to be low-friction enough that the translation cost is minimal.

"Nobody reads them anyway." If past RFCs have been ignored, rubber-stamped, or left to rot in a wiki, this objection is earned. The process has to prove that writing an RFC leads to meaningful engagement.

"We're too small for this." Small teams often feel that RFCs are for big companies with hundreds of engineers. The counterargument: a five-person team that loses a founding engineer also loses all the context in that person's head. Written proposals are insurance against institutional memory loss.

Start with One Influential Engineer

Do not roll out an RFC process with a company-wide announcement. Do not send a Slack message titled "New RFC Process -- Mandatory for All Teams." That approach creates compliance, not culture.

Instead, find one engineer on the team who is respected by their peers and who already thinks in systems terms. Ask them to write a design document for their next project. Not an RFC -- just a document that describes what they are planning to build and why. Share it with the team for feedback. See what happens.

If the document is good, the feedback will be good. Other engineers will point out edge cases the author had not considered. The author will revise the design before writing a line of code. When the project ships cleanly, everyone will remember that the design doc helped.

This is the seed. One successful design document, written by someone the team respects, is worth more than any process document.

Make It Low-Friction

The number one predictor of whether engineers will write RFCs is how much effort it takes to start one. If writing an RFC requires opening a specific tool, navigating to the right folder, copying a template, filling in twelve sections, and tagging the right reviewers, most engineers will find reasons to skip it.

Reduce the activation energy. A good starting point:

• One template, one page. The template should fit on a single page. Problem statement, proposed solution, alternatives considered, open questions. That is it. Anything more can be added as the discussion develops.
• Write where you already are. If your team lives in GitHub, use a markdown file in the repo. If your team lives in Notion, use Notion. If your team lives in Google Docs, use Google Docs. Do not introduce a new tool just for RFCs.
• No approval gates to start. Anyone should be able to create an RFC at any time without asking permission. The barrier to entry should be zero.

You can add structure later, once the habit is established. But premature process is the enemy of adoption.

Make Reading RFCs Part of Sprint Rituals

Writing RFCs is only half the equation. If nobody reads them, the writer's effort is wasted and they will not write another one.

Build RFC review into existing rituals rather than creating new meetings:

• Sprint planning. When a team picks up a project that has an RFC, reference the RFC in planning. "This is covered in RFC-042, everyone should read it before we start."
• Weekly engineering sync. Spend five minutes at the start highlighting RFCs that are open for review. Not presenting them -- just flagging them and asking people to read and comment asynchronously.
• Pull request reviews. When reviewing a PR, check if there is a related RFC. If the implementation diverges from the RFC, that is a conversation worth having.

The goal is to make RFCs a natural part of the engineering workflow, not a separate activity that competes for attention.

Celebrate Good RFCs Publicly

Positive reinforcement works. When an RFC leads to a good outcome, make it visible.

A few ways to do this:

• Call it out in retrospectives. "The migration went smoothly because the RFC identified the backwards compatibility issue before we started coding."
• Share in engineering-wide channels. "Great RFC by [engineer] on the caching layer redesign. Worth reading if you work on anything that touches the data pipeline."
• Reference RFCs in postmortems. When a production incident could have been prevented by better upfront design, say so. And when an incident was prevented because an RFC caught the issue early, say that too.

Do not gamify it. Do not create an "RFC of the Month" award with a trophy. Engineers will see through that. Just make it normal to acknowledge good design work the same way you acknowledge good code.

The Flywheel

Culture change follows a flywheel pattern. Here is the RFC flywheel:

1. A good RFC is written. It identifies a real problem, proposes a well-reasoned solution, and considers alternatives.
2. Reviewers engage meaningfully. They ask questions that improve the design. The author revises the proposal based on feedback.
3. The project ships with fewer surprises. Because the design was vetted before implementation, there are fewer mid-project pivots and fewer "we did not think of that" moments.
4. Engineers see the value. The team notices that RFC-backed projects go more smoothly than ad-hoc ones.
5. More engineers write RFCs. Not because they are told to, but because they saw that it works.
6. Return to step 1, with higher expectations. As the team writes more RFCs, the average quality goes up because engineers learn from each other's documents.

The flywheel takes time to spin up. Expect three to six months before writing RFCs feels natural to the team. During that ramp-up period, the process is fragile. One bad experience -- a rubber-stamped RFC that should have been challenged, or an RFC that sat unreviewed for a month -- can set you back significantly.

Practical Tips for Managers and Tech Leads

Write the first few RFCs yourself. If you are the tech lead or engineering manager introducing the process, you should be the first person to use it. This signals that RFCs are not busywork you are delegating -- they are a tool you value enough to use yourself.

Pair with junior engineers on their first RFC. Writing a design document is a skill. Junior engineers may not know how to structure their thinking into a proposal. Sit with them, help them articulate the problem, and coach them through the alternatives section. Their second RFC will be much better than their first.

Do not mandate. Invite. "I think this project would benefit from a design doc -- would you be up for writing one?" works better than "All projects over 5 story points require an RFC." The former builds buy-in. The latter builds resentment.

Protect RFC time. If your sprint is so packed that engineers cannot spend half a day writing a design doc, the problem is not the RFC process -- it is the sprint planning. Design time is not separate from development time. It is the most valuable part of development time.

Review RFCs promptly. Nothing kills the process faster than an RFC that sits unreviewed for two weeks. If you are listed as a reviewer, respond within two business days. If you cannot, delegate to someone who can. The author invested time in writing; honor that investment with timely feedback.

Accept that some engineers will never love writing. That is fine. Not every engineer needs to write RFCs. But every engineer should be able to read an RFC and give useful feedback. A team where half the engineers write and all of them review is doing well.

The goal is not to turn every engineer into a technical writer. The goal is to build a team where writing down your thinking before building is the natural, expected thing to do -- not because of process, but because everyone has seen that it works.