Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Request for Comments Documents to Drive Alignment
Transcript
- Lucas: You know that moment when two engineers have been arguing about an architecture decision for three days, and nobody can even remember the original trade-offs? Luna: Oh, I've lived that. The longer the debate goes, the more both sides just entrench. Lucas: Right. And the worst part is, even after someone finally makes a call, you've got no record of why. Six months later, someone asks 'Why did we build it this way?' and everyone shrugs. Luna: So what's the antidote? I'm guessing it's not 'more meetings.' Lucas: No. It's the opposite. More writing. Specifically, a practice called RFCs — Request for Comments documents. It's a concept borrowed from the internet standards world, but a bunch of engineering orgs have adapted it for internal decision-making. Luna: I've seen this at a few places. The idea is that before you build anything significant, you write a document that lays out the problem, the options, and a recommendation. Lucas: Exactly. And the whole team gets a chance to comment — asynchronously. So you capture everyone's input without dragging them into a room. The CTO I spoke with for this episode runs this process for every material technical decision at his company. Luna: What counts as 'material'? Are we talking about every database index change? Lucas: Good question. He draws a line at anything that would take more than a week to implement, or that changes an API contract, or that introduces a new dependency. For a typical mid-stage SaaS company, that's maybe two to four RFCs per week. Luna: That feels manageable. I've seen orgs where every single change requires a design doc, and then nobody writes anything because the overhead is too high. Lucas: Right, you need a threshold. So let's walk through a concrete example. This CTO's team was facing a decision about their payment service. They had a monolithic billing system that handled subscriptions, invoicing, refunds — everything. And it was starting to creak. Luna: Classic monolith pain. One deploy touches everything, testing takes forever, and any regression can break the whole revenue flow. Lucas: Exactly. So an engineer proposed splitting it into three services: one for subscriptions, one for payments, and one for invoices. That's a big architectural shift. So instead of just starting to code, she wrote an RFC. Luna: What did the RFC look like? I'm imagining a template. Lucas: He uses a lightweight template with six sections. Context — what problem are we solving? Goals — what does success look like? Non-goals — what are we explicitly not solving? Design options — at least two alternatives, with trade-offs for each. Recommendation — which option you're proposing, and why. And then risks and mitigations. Luna: I like the non-goals section. That's the part people forget. They try to solve everything at once, and the scope balloons. Lucas: Right. In this case, a non-goal was 'migrating the database vendor.' They're staying on Postgres. That keeps the RFC focused. So the engineer wrote up three options: Option A, do nothing and add more capacity to the monolith; Option B, extract a payments service now and leave subscriptions and invoices together; Option C, extract all three services at once. Luna: And I'm guessing Option C looked appealing on paper but was super risky. Lucas: That's exactly what the RFC argued. The recommendation was Option B — start with payments, because that's where the most pain was. Then after that's stable, tackle subscriptions and invoices separately. The RFC laid out the cost of each option in engineering weeks and the risk of data inconsistency. Luna: So the document becomes the artifact. Anyone can read it, comment, challenge assumptions. It's not about winning an argument — it's about surfacing the best thinking. Lucas: And that's the cultural shift. The CTO told me that when he first introduced RFCs, some engineers felt like it was bureaucratic overhead. They'd say 'I could have built this in the time it took to write the doc.' But after a few months, they saw the value. Luna: What changed their minds? Lucas: A couple of things. First, they stopped having to re-argue decisions in hallway conversations. The RFC was the single source of truth. Second, when something went wrong — and it did, a payment service had a bug in the first month — they could go back to the RFC and see what assumptions they'd made about error handling. It made the postmortem way more productive. Luna: So it's also a decision log. Not just a planning tool. Lucas: Exactly. Every RFC gets filed in a repository, and it becomes part of the institutional memory. New hires can search 'Why did we choose this database?' and find the RFC from two years ago. That alone saves weeks of onboarding time. Luna: I want to talk about the mechanics. How long should an RFC be? I've seen some that are thirty pages, and nobody reads them. Lucas: This CTO caps RFCs at five pages. If you can't make your case in five pages, you probably don't understand the problem well enough yet. He also requires that the RFC be written before any code is written — no 'I'll prototype it and then write the doc.' The writing is the thinking. Luna: That's a hard rule. I imagine some engineers push back on that. Lucas: They do. But he's willing to lose a few people who can't work that way. He'd rather have a team that writes clear RFCs than a team that ships quickly but incoherently. And honestly, the data shows that teams using RFCs ship fewer bugs and have less rework. Luna: What about the review process? The RFC gets posted, then what? Everyone just reads it and comments? Lucas: He uses a simple workflow. The RFC is created as a pull request in a documentation repository. Anyone on the engineering team can comment inline. There's a 48-hour comment period. After that, the author addresses feedback and merges the RFC. The merged version is the final decision. Luna: 48 hours feels short for a big decision. Lucas: He extends it to a week for larger changes. But the key is that the decision is made by the author, not by a committee. The RFC is a proposal, not a vote. The author owns the recommendation, but they're expected to genuinely consider the feedback. If they ignore valid concerns, they'll lose trust quickly. Luna: So it distributes decision-making authority. The CTO doesn't have to approve every RFC. Lucas: Right. He only gets involved if there's a tie or a safety issue. Otherwise, the engineer who wrote it owns the outcome. That's a huge force multiplier. And it means the CTO can focus on strategy rather than reviewing every architecture call. Luna: One thing I've noticed with RFCs is that they can become a crutch. Teams write a beautiful document, but then they don't actually follow the recommendation. The RFC sits in the repo and the actual implementation drifts. Lucas: That's a real risk. This CTO avoids it by requiring that the RFC be updated if the implementation deviates from the plan. You can't merge a pull request that contradicts the RFC without also updating the RFC. That keeps the document alive. Luna: Ah, so the RFC becomes a living document, at least until the implementation is done. That's smart. Lucas: And then after launch, the RFC gets tagged with 'implemented' or 'superseded' if a later RFC changed the approach. So you always know the current state of any decision. Luna: It's really a knowledge management system disguised as a process. I'm curious — what happens when two RFCs conflict? Two different teams propose different approaches to overlapping problems. Lucas: That's where the CTO does step in. He'll facilitate a discussion, sometimes a meeting, to resolve the conflict. But the resolution gets captured in a new RFC that supersedes the conflicting ones. So the decision log stays clean. Luna: I like that. It forces explicit conflict resolution rather than letting teams silently diverge. Lucas: And it creates a record of why one approach won over another. Six months later, nobody wonders 'Why did we go with this architecture?' — they can read the RFC that resolved the conflict. Luna: You know, this whole conversation is making me think about how we run our own show. We're constantly making decisions about episode topics, guests, angles — and we don't write any of it down. We just argue and then forget. Lucas: That's actually a perfect parallel. If listeners found today's discussion useful, they might appreciate knowing that the same documentation discipline applies to us. We try to keep this show ad-free and focused on practical takeaways, and listener support is what makes that possible. If you'd like to help, you can find us at buy me a coffee dot com slash fexingo. Even a small contribution helps us keep producing episodes like this one. Luna: Yeah, and we genuinely read the comments. Some of our best episode ideas come from listeners. So if you have a topic you'd like us to cover, that's also a great way to reach us. Lucas: Exactly. Now, back to RFCs — I want to talk about one more pattern that this CTO uses. He requires that every RFC include a 'what if we do nothing' option. That forces the team to consider the status quo seriously, not just pitch their favorite solution. Luna: That's smart. It also prevents the sunk-cost fallacy. If the team has already invested time in thinking about a solution, they're biased toward implementing it. 'Do nothing' is a legitimate option. Lucas: Right. In the payment service example, 'do nothing' was Option A. The RFC showed that doing nothing would cost more in operational overhead over the next year than Option B. That made the recommendation compelling. Luna: So the RFC is also a cost-benefit analysis. I'm wondering — does he have any metrics on whether this process actually improves outcomes? Or is it just a belief? Lucas: He tracks a few things. First, the number of production incidents caused by architectural decisions dropped by about 40 percent in the first year. Second, the time to onboard a new engineer — from first commit to shipping a feature independently — went from about eight weeks to four. He attributes both to the RFC repository. Luna: Those are concrete numbers. The onboarding one is huge. New hires can read the history of decisions rather than bothering senior engineers every hour. Lucas: Exactly. And the senior engineers appreciate it too — they get fewer interruptions. So the RFC practice scales the engineering org without scaling the management overhead. Luna: Alright, I'm sold. But I want to push back on one thing. This sounds like it works for a mid-stage company with maybe 20 to 50 engineers. Does it scale to a hundred? Two hundred? Lucas: He thinks it does, but with some adjustments. At larger orgs, you'd have multiple RFC repositories — one per team or per domain. And you'd need a lightweight way to cross-reference RFCs across teams. Some companies use a wiki with tags for that. Luna: And I imagine the comment period would need to be longer for cross-team RFCs, because people have more context to absorb. Lucas: Right. But the principle stays the same: write down the thinking before you build. The CTO told me that even at Google, they use design docs extensively. The scale changes, but the habit of writing first is universal. Luna: So if a listener wanted to start this tomorrow, what's the smallest possible first step? Lucas: Pick one decision that's coming up in the next week. It doesn't have to be huge — maybe a new API endpoint or a database migration. Write a one-page RFC using the six-section template. Send it to the team with a 48-hour comment window. After that, make a decision and file it. Just that one experiment will show you whether the process adds value. Luna: That's a great takeaway. Start small, prove it works, then expand. I'm going to try it with our next topic decision. Lucas: Let me know how it goes. And to our listeners, if you do try it, we'd love to hear about your experience. Drop us a note — we're easy to find.