How Google, Uber, and Rust Run Their RFC Process

Every engineering organization eventually faces the same question: how do we make technical decisions that stick? The answer, across wildly different organizations, converges on some form of written proposal process. But the details vary significantly.

Here is how four well-known engineering cultures handle RFCs and design documents, and what you can learn from each.

Google: Design Docs as a Core Engineering Practice

Google's design doc process is one of the most well-documented internal practices in tech, thanks to engineers who have written about it publicly after leaving.

At Google, design docs are typically written in Google Docs (naturally). They follow a loose template that includes context, goals and non-goals, the proposed design, alternatives considered, and cross-cutting concerns like security, privacy, and scalability. The doc is shared with relevant reviewers, who leave inline comments.

What makes Google's process distinctive is the role of readability reviewers. These are engineers who have been granted "readability" in a specific language or domain. They review not just the code but the design docs that precede it. This creates a quality bar that goes beyond "does this compile" into "is this the right approach."

Design docs at Google are expected for any non-trivial project. A new service, a significant refactor, a change to a shared library -- all of these warrant a design doc. The doc lives alongside the project and serves as a historical record of why decisions were made.

Key takeaways from Google's approach:

• Low-friction tooling matters. Using Google Docs means zero setup cost. Engineers do not need to learn a new tool.
• Reviewer quality is as important as writer quality. The readability reviewer system ensures that experienced engineers are in the loop.
• Design docs are tied to projects, not processes. There is no central RFC committee. The team owns its design docs.

Uber: Request for Discussion (RFD)

Uber's engineering blog has described their internal "Request for Discussion" (RFD) process. The naming is deliberate -- it is a request for discussion, not approval. This framing matters.

Uber's RFDs follow a lifecycle: Draft, Discussion, Accepted, or Rejected. The emphasis on the Discussion phase is what sets it apart. RFDs are explicitly designed to surface disagreement early, before code is written. Engineers are expected to engage with RFDs from other teams, not just their own.

Uber operates at a scale where a backend change can ripple across hundreds of microservices. The RFD process exists to catch those ripple effects before they become production incidents. An RFD for a new serialization format, for example, would need input from the platform team, the observability team, and the teams that own the highest-throughput services.

What Uber gets right:

• Naming shapes behavior. Calling it a "Request for Discussion" sets the expectation that feedback is the point, not a formality.
• Cross-team visibility is built in. RFDs are discoverable by anyone in engineering, which prevents duplicate work and surfaces expertise.
• Lifecycle states keep things moving. An RFD cannot sit in "Discussion" forever. There are expectations around timeboxing the review period.

Rust: Open RFCs on GitHub

The Rust programming language runs one of the most transparent RFC processes in software. Every significant language change goes through an RFC filed as a pull request on the rust-lang/rfcs GitHub repository. RFCs are numbered sequentially and tracked publicly.

The process works like this: anyone can submit an RFC by opening a pull request. The community discusses it in PR comments. Core team members and working group leads weigh in. Eventually, the RFC enters a "Final Comment Period" (FCP), after which it is either accepted, rejected, or postponed.

Rust's RFC process has produced some remarkably well-reasoned documents. RFC 1105 (API evolution), RFC 2094 (non-lexical lifetimes), and RFC 2229 (closure captures) are examples of complex technical decisions that were thoroughly debated in public before being implemented.

The tradeoff is speed. Rust RFCs can take months to reach a decision, and the comment threads can run to hundreds of messages. For a programming language, this thoroughness is appropriate. For a product team shipping features quarterly, it would be paralyzing.

What the Rust process demonstrates:

• Public accountability improves quality. When your reasoning is visible to thousands of developers, you think harder about it.
• Structured phases prevent endless debate. The Final Comment Period creates a forcing function for decisions.
• Not every RFC gets accepted, and that is okay. Rejected and postponed RFCs are preserved as a record of what was considered and why it was not pursued.

React and TC39: RFC Repos for Ecosystem Changes

Both the React team and the TC39 committee (which governs the JavaScript/ECMAScript specification) use dedicated GitHub repositories for RFCs and proposals.

React's rfcs repository has been the venue for proposals like Hooks, Server Components, and the new React compiler. Engineers open a pull request with a markdown document following a template. Discussion happens in PR comments, and the React core team decides whether to accept.

TC39 takes this further with a formal four-stage process for JavaScript language proposals. Stage 0 is a strawman idea. Stage 1 means the committee thinks the problem is worth solving. Stage 2 means there is a draft specification. Stage 3 means the spec is complete and needs implementation experience. Stage 4 means it is ready for inclusion in the standard.

TC39's staging model is worth studying even if you are not designing a programming language. The idea that a proposal gains credibility incrementally -- from "we agree this is a problem" to "we agree on the solution" to "we have proven it works" -- is applicable to any engineering organization.

Patterns from the open-source RFC world:

• Templates reduce variance. Both React and TC39 provide structured templates that ensure every proposal covers the same bases.
• Staged acceptance reduces risk. You do not go from "idea" to "shipped" in one step. Each stage has clear criteria.
• Public discussion attracts unexpected expertise. Some of the best feedback on React RFCs has come from community members, not core team members.

What Patterns Emerge

Despite the differences in scale, tooling, and culture, several patterns show up in every successful RFC process:

Written proposals as the default. None of these organizations make major technical decisions in meetings alone. The written document is the artifact that persists.

Structured templates. Every process uses some form of template. It does not need to be rigid, but it needs to ensure that problem statements, alternatives, and tradeoffs are addressed.

Explicit lifecycle states. Whether it is Google's informal "LGTM" culture, Uber's Draft/Discussion/Accepted states, Rust's FCP, or TC39's four stages -- every process has a way to signal where a proposal stands.

Cross-functional review. Good RFC processes pull in reviewers from outside the authoring team. Google does this through readability reviewers, Uber through cross-team RFD distribution, and Rust through public GitHub discussion.

Preserved history. Rejected proposals are as valuable as accepted ones. Knowing why an approach was not taken prevents teams from re-litigating the same decisions.

The specific tooling matters less than the culture around it. Google uses Docs. Rust uses GitHub PRs. Uber uses an internal system. What they share is a commitment to thinking before building, and capturing that thinking in a form that others can engage with.

If you are setting up an RFC process for your team, you do not need to copy any of these exactly. But you should steal the principles: make writing easy, make reviewing expected, make decisions visible, and keep the history.