When You Can’t Fit Engineering in One Room Anymore: A Practical RFC Playbook

There’s a moment in every scale-up when architecture stops being a “shared intuition” and turns into a coordination problem.

Before 50 engineers, alignment is often a social artifact. You can still rely on hallway conversations, a couple of team leads syncing once a week, and the comforting illusion that “everyone basically knows what’s going on.” You can put most people in a room, whiteboard the approach, and walk out believing the decision is now common knowledge.

Past 50, the physics change. Rooms are too small. Teams are split across locations and time zones. Calendars get eaten by recurring meetings that exist mostly to repair misalignment created elsewhere. Even when you do get the right people in the room, the decision rarely survives contact with reality: someone new joins, another person rotates teams, and six weeks later you discover three different interpretations of what was agreed.

I came into this phase with an open source bias from working around Canonical/Ubuntu, and later on CNCF projects, where distributed decision-making is not a novelty, it’s the operating system. When you can’t assume synchronous alignment, you write things down, make them easy to review, and you create a clear path from proposal to decision to implementation.

That’s why I like RFCs.

What I mean by an RFC (and what I don’t)

In practice, I use “RFC” as a design document that is intentionally written for review before the design is finalized. It’s less “here’s what we’re doing” and more “here’s what I propose, here are the tradeoffs, and here’s how we’ll validate it.”

A Hacker News thread I’ve kept bookmarked captures the distinction nicely: a design document can be what you write once you’ve decided, while an RFC is what you write to invite others into selecting the design, with details strong enough that feedback is grounded in reality rather than vibes.

The goal is not bureaucracy. The goal is to replace decision-making-by-meeting with decision-making-by-artifact.

Two real examples where alignment broke without written artifacts

1. Kafka adoption. “Use Kafka” hides decisions on ownership, schemas, retries, ops, and migration. No RFC means divergence and firefighting.
2. Limit orders. Looks like a feature, but it’s correctness, edge cases, and failure modes. No RFC means hidden assumptions hit prod.

The RFC playbook I’ve used at 50+ engineers

1) Put RFCs where engineers already work

The highest-leverage move is making the RFC live in a Git repo and using pull requests for review. It gives you version history, threaded comments tied to specific lines, and an obvious “open vs merged” lifecycle. I’ve also run this in Notion using a database, which can work, but Git tends to win when you want durable, engineering-native workflows.

2) Make comments open, but approvals explicit

Open commenting is non-negotiable for me. Anyone should be able to read the proposal and leave feedback, because hidden reviewers create hidden constraints, and hidden constraints are how architecture fragments.

Approval is different. Approval needs to be clear, bounded, and predictable, otherwise you end up with endless bikeshedding or silent vetoes.

I’ve had good results with an approval rule that depends on blast radius:

• Small blast radius change: 1 component owner plus 1 principal or staff engineer
• Multiple subsystems: 2 principal or staff engineers, at least one representing an affected subsystem
• Large architectural change: 2 members of the architecture council, and often the CTO as well (or a delegated equivalent)

3) Require a template that forces the hard parts

Templates are underrated. A good template doesn’t create more writing, it prevents rework by ensuring first-round questions are answered up front, which is exactly what multiple engineers in that same thread pointed out from experience.

A practical RFC template I’ve used looks like this:

• Context and problem statement
• Goals and non-goals
• Proposed design (high level, then key details)
• Alternatives considered and why they were rejected
• Impacted systems and owners
• Rollout plan and migration strategy
• Observability and operational ownership
• Explicit approvers

The RFC is not there to predict the future, it’s there to surface tradeoffs early and record why you chose a path.

4) Make the proposer own the persuasion

The accountability should sit with the developer leading the change. Their job is to explain the approach, show they understand the implications, and convince maintainers of affected components that the proposal is safe enough to try.

5) Create an architecture council, but don’t let it become a closed committee

I strongly prefer having an architecture council whose role is to manage flow, not to decide behind closed doors.

What that means in practice:

• The council reviews the RFC backlog, identifies stuck proposals, and ensures the right approvers are assigned.
• Architectural debate happens in the RFC itself, or in a meeting that includes the RFC author and the relevant maintainers.
• The council does not become a private room where decisions are pre-cooked and then “announced.”

If you get this wrong, you’ll end up with the worst of both worlds: slow decisions and low trust.

The payoff: fewer meetings, clearer decisions, faster onboarding (and smoother AI-agent adoption)

The biggest win I’ve seen from an RFC culture isn’t “better architecture” in the abstract. It’s reduced coordination load.

When plans exist as written artifacts, engineers can review asynchronously, decisions don’t get lost in meeting notes, and the org builds a searchable memory of tradeoffs and rationale. That’s what keeps direction coherent as the team grows, even as people rotate and context evaporates.

What’s interesting is that this also maps cleanly to how teams will adopt AI agents. An RFC is basically a plan before implementation: inputs, constraints, ownership, risk, rollout. That’s the same structure you need when you’re delegating work to agents, because the failure mode is identical: ambiguity scales faster than execution.

So if you’re crossing 50 engineers and your architecture feels like it’s drifting, don’t start by adding more meetings. Start by building an artifact pipeline: proposal, review, explicit approval, recorded decision. It will make your humans faster today and your agent workflows safer tomorrow.

Write the change down, make it easy to find, and let the best arguments win on the page.