Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why You Should Write Your RFCs in Public
Transcript
- Lucas: So like a lot of engineering teams, we write RFCs. Request for Comments documents. But for years, the default was: write the RFC, share it with a handful of senior engineers, get their sign-off, and move on. Luna: Right, the small-circle approach. It feels efficient. Lucas: Efficient on the surface, yeah. But we kept seeing the same pattern. An RFC would get approved, work would start, and then three weeks in, someone outside that initial group would ask a question that revealed a fundamental flaw. And suddenly you're backtracking. Luna: I remember one specific case. The team proposed migrating a core database from Postgres to a sharded MySQL setup. Good technical reasons throughput, latency. The RFC got approved by the infrastructure lead and a couple of senior backend engineers. Lucas: And then what happened? Luna: A junior engineer on a different team happened to read it during a lunch break. She flagged that the migration plan didn't account for a particular data retention policy required by our EU customers. GDPR stuff. The senior engineers had completely missed it. Lucas: That's the classic blind spot. The people closest to the technical problem are often the least likely to think about compliance, legal, accessibility, or even documentation impact. And those are exactly the perspectives you want early. Luna: So the fix seems obvious. Make the RFC public to the whole company. But that comes with its own problems, right? Noise. Notification fatigue. People ignoring them. Lucas: Absolutely. When we first tried publishing every RFC to a company-wide Slack channel, it was chaos. Twenty RFCs a week. Nobody read them. The signal to noise ratio was terrible. So we had to iterate. Luna: What worked? Lucas: Two things. First, a weekly digest. Every Friday, one person curates a one-paragraph summary of each RFC published that week. You can skim it in 30 seconds and decide if you want to read the full doc. Second, we made RFCs asynchronous by default. No meetings to discuss them. Comments happen inline over a seven-day review period. Luna: So you're trading speed for depth. But isn't that a tough sell when your CTO wants to move fast? Lucas: It can be. But here's the counterargument: how fast are you really moving if you have to redo a chunk of work because you missed something obvious? The GDPR example delayed that migration by maybe two weeks. If they'd discovered it during implementation, it would have been a month or more of rearchitecting. Luna: The 'slow down to speed up' argument. I buy it. But I think there's another benefit that's less talked about. Lucas: What's that? Luna: Public RFCs force the author to write better. When you know only two senior engineers are going to read your doc, you can be sloppy. You can skip context. But when you know a junior developer in another department might read it, or someone from legal, you actually explain the trade-offs. You define terms. It makes the document more durable. Lucas: That's a great point. And it builds institutional knowledge. Six months later, when someone says 'why did we choose this architecture?' the RFC is there. Public. Searchable. With a comment thread that captures the debate. Luna: That's basically a decision log, which we've talked about before. But here it's embedded in the process itself. Lucas: Exactly. So the question becomes: how do you start? I'd recommend picking one team, one project. Tell them to publish their next RFC to the whole company. Give them a template that includes a section called 'Impacted Teams' where they explicitly list who might care. And set a clear comment period. Luna: And what about the noise problem for the rest of the company? If I'm a front-end engineer, do I really need to see every database migration RFC? Lucas: No, and that's the nuance. You don't need to read them all. But you should have the option. The weekly digest lets you opt in. And if a front-end engineer reads a migration RFC and realizes it will change the API response format, that's gold. They can comment early. Luna: Right. So it's not about forcing everyone to read everything. It's about making the information available and letting people self-select. Lucas: Exactly. Another thing we've learned: treat RFCs as living documents. People treat them as one-and-done. Write it, approve it, archive it. But the best RFCs get updated during implementation. The author adds a note saying 'we tried this, it didn't work, here's what we changed.' That's where the real learning happens. Luna: That's a cultural shift. It requires people to be okay with documenting their mistakes in public. Lucas: Big time. And that starts with leadership. If a senior engineer or a CTO posts an RFC that gets challenged, and they respond constructively, that sets the tone. It signals that the goal is the best decision, not the author's ego. Luna: I want to push back a little. There are some decisions that genuinely shouldn't be public. Security architecture, for example. Or things that involve customer data or competitive strategy. Lucas: Totally fair. We're not talking about publishing everything. Some RFCs should be limited to a smaller group. But I'd argue that the default should be public, and you should have a specific reason to restrict access. Not the other way around. Luna: That's a good principle. Default to open, restrict by exception. Lucas: Exactly. And I'll give you one more concrete example. We had an RFC about switching our CI/CD pipeline from Jenkins to GitHub Actions. The author published it company-wide. A data engineer commented that the new pipeline wouldn't handle their long-running data processing jobs. The author hadn't considered that use case. They added a parallel workflow for data jobs. Problem avoided before anything was built. Luna: That's the kind of cross-team insight you can't get from a closed review. Lucas: Right. And it's not just about catching mistakes. It's about building a culture where decisions are transparent and anyone can contribute. That's how you get buy-in. That's how you avoid the 'not invented here' syndrome. Luna: So if someone listening wants to try this, what's the first step? Lucas: Pick one non-critical RFC. Not a huge migration. Maybe a minor API change or a new library choice. Publish it to a company-wide channel. Set a one-week comment period. Then actually read the comments and respond. See what happens. The worst case is you get zero comments, which is fine. The best case is you catch something you'd have missed. Luna: And if you're a CTO listening, you can model this behavior yourself. Write an RFC for something small and publish it publicly. Show that you're open to feedback. Lucas: Exactly. And before we wrap, I want to mention something that's relevant here. We keep this podcast ad-free intentionally. No sponsors, no interruptions. If that kind of approach resonates with you, and you'd like to support it, you can find us at buy me a coffee dot com slash fexingo. Luna: Yeah, it's a small way to keep the show independent and focused on the stuff that actually helps. Appreciate anyone who chips in. Lucas: So to bring it back: the key takeaway for me is that public RFCs aren't just about catching errors. They're about building a more informed, more collaborative engineering culture. And that pays dividends far beyond any single decision. Luna: I'd add one more thing: start small, but start. Even one public RFC a month will shift the conversation. Lucas: Well said. Next time, we'll talk about something a little more controversial: whether you should let engineers choose their own tools. But that's for another episode. Luna: Looking forward to it. For now, thanks for listening.