Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Cut Decision Debt With RFCs
Transcript
- Lucas: So there's this term floating around engineering leadership circles — decision debt. It's not talked about as much as technical debt, but it might be more insidious. Luna: Decision debt. I've heard the phrase, but let's pin it down. What does it actually mean in practice? Lucas: It's the accumulation of unresolved or poorly-documented decisions. Every time a team revisits the same architectural question because nobody wrote down why they chose one database over another, that's decision debt accruing interest. Luna: And you said it's worse than technical debt? Lucas: At least technical debt has a remediation plan — you can refactor, rewrite, or deprecate. Decision debt is invisible. It lives in Slack threads, in hallway conversations, in the head of one senior engineer who left six months ago. Luna: So how do you actually manage it? I've seen teams try decision logs, but they quickly become stale. Lucas: The approach I want to talk about today is the RFC — Request for Comments. It's not new — open-source communities have used it for decades — but I've seen a CTO at a mid-stage SaaS company adapt it for internal engineering decisions with remarkable results. Luna: Wait, like the IETF RFCs? Those are hundreds of pages. Lucas: Exactly. But this team stripped it down. Their rule: any decision that involves more than two engineers requires an RFC. And the RFC itself must be under 500 words. That forces clarity. Luna: 500 words. That's tight. What goes in it? Lucas: Four sections. The problem — one sentence. The proposal — a few paragraphs. The alternatives considered — at least two, with a one-sentence rejection reason each. And a concrete 'no' section — what the proposal explicitly says the team will not do. Luna: That 'no' section is interesting. Most proposals only argue for their own idea. Lucas: Exactly. By writing down what you're saying no to, you prevent the same debate from resurfacing. Someone says 'why didn't we use Kafka?' and you can point to the RFC that says 'we considered Kafka, but for our current volume of 50 messages per second, a simple queue was sufficient and reduced operational overhead.' Luna: So it's an explicit trade-off log. Lucas: Right. The CTO I mentioned told me that in the first quarter after adopting RFCs, their team saved roughly 200 hours of meeting time. Because debates that used to take an hour in a room were resolved in twenty minutes of asynchronous reading. Luna: Two hundred hours — that's five weeks of one person's time. Lucas: And that's conservative. They also noticed a second-order effect: junior engineers started writing RFCs. Because the format was so constrained, they didn't feel intimidated. And the 'no' section gave them permission to challenge decisions without being confrontational. Luna: Let's talk about the format more. 500 words — do they include diagrams? Lucas: Yes, but only one diagram per RFC. And it has to be an ASCII art or a simple box and arrow. No polished diagrams that take hours to make. The goal is to communicate, not to impress. Luna: Where do these RFCs live? Notion? GitHub? Lucas: The team I saw uses a simple markdown file in a shared GitHub repo. Naming convention: yyyy mm dd short description. That way they're sortable by date. They also have a README that indexes all RFCs by status — proposed, accepted, rejected, superseded. Luna: Superseded — that's important. Decisions change. Lucas: Exactly. And when a decision is superseded, the new RFC references the old one, and the old one gets a link to the new one. So there's a chain. That's how you avoid the 'we already decided this' trap that stifles innovation while still respecting past context. Luna: I want to push back a little. Doesn't this create bureaucracy? Another thing to write, another thing to review. Lucas: It can, if you're not disciplined. The key is the 500-word limit and the rule that only decisions involving more than two engineers need an RFC. For two-person decisions, a quick Slack decision is fine. But once you add a third person, you need a shared artifact. Luna: So three engineers is the threshold. Why three? Lucas: Because with two people, you can have a conversation and both walk away with the same understanding. With three or more, you get ambiguity. People interpret the same conversation differently. The RFC creates a single source of truth. Luna: That makes sense. I've been in meetings where three people left with three different understandings of what was decided. Lucas: And then a week later, you're in another meeting rehashing the same topic. That's decision debt compounding. The RFC stops that cycle. Luna: What about decisions that affect other teams? Like a backend team deciding on an API contract that the frontend team needs to consume. Lucas: Great question. In that case, the RFC must include a 'consulted' section — list the people or teams who were asked for input. Not just informed, but actually consulted before the decision is made. That prevents siloed decisions that create friction later. Luna: So the RFC becomes a coordination tool too. Lucas: Exactly. And it's lightweight. No meetings required. Someone writes the RFC, posts it in a Slack channel, and sets a deadline — typically 48 hours for comments. If no objections, it's accepted by default. That's the 'silence implies consent' rule. Luna: That requires a culture where people actually read RFCs. How do you build that? Lucas: The CTO I mentioned made RFC review part of everyone's weekly goals. Not a huge time sink — just 'review pending RFCs' for 30 minutes a week. And they started with a single team, proved the value, then expanded. Luna: And the 200 hours saved came from that one team? Lucas: Yes. One team of 12 engineers. After three months, they estimated they spent about 15 hours per week in decision-making meetings before RFCs, and about 10 hours after. But more importantly, the quality of decisions improved because they were written down and thought through. Luna: Alright, I'm sold on the concept. But I want to talk about one risk: what if someone writes a bad RFC that gets accepted, and then you're stuck with a bad decision documented forever? Lucas: That's where the superseded status comes in. A bad decision can be replaced by a better one. The key is to have a culture where changing your mind is seen as a strength, not a failure. The RFC chain shows that you learned and adapted. Luna: But some decisions are hard to reverse — like choosing a database provider. Lucas: Those are exactly the decisions that need the most scrutiny. The RFC for a database choice should have a longer comment period — maybe a week — and require sign-off from at least two senior engineers. But the principle holds: write it down, argue it out, then commit. Luna: Now, you mentioned this is a CTO at a mid-stage SaaS company. Can you give us a specific example of an RFC that made a difference? Lucas: Sure. One RFC was about whether to move from a monolithic Rails app to microservices. The proposal was to start extracting a single service — the billing system — as a pilot. The alternatives considered: do nothing, go full microservices, or use a modular monolith. The 'no' section explicitly stated the team would not rewrite the entire app. That RFC was accepted, and six months later, that billing service was handling 10 times the transaction volume without any downtime. Luna: And without the RFC, they might have either stayed monolithic forever or jumped into a full rewrite — both bad outcomes. Lucas: Exactly. The RFC forced them to articulate the boundaries of the decision. And because it was written down, new engineers joining the team could understand why that choice was made. Luna: This feels like something any team could start doing tomorrow. What's the first step? Lucas: Pick a decision that's been debated recently. Write an RFC yourself — under 500 words. Share it in a public channel. Set a 48-hour comment window. That single act will demonstrate the value. Usually, one good RFC is enough to convert the skeptics. Luna: I like that. It's like the 'eat your own dog food' approach. Lucas: And I think there's a broader lesson here. If you can eliminate decision debt, you free up mental energy for the decisions that actually matter — the ones that shape your product and your team's future. Luna: We keep the podcast free of ads for exactly that reason — we don't want you to have to filter through sponsored content to get to the useful stuff. If you find value in conversations like this one, you can support us at buy me a coffee dot com slash fexingo. Keeps it sustainable and distraction-free. Lucas: Appreciate that, Luna. So to wrap up: RFCs are a low-cost, high-impact practice for any engineering team. Start with one decision, keep it under 500 words, and watch the decision debt melt away. Luna: And if you try it, let us know how it goes. We'd love to hear a success story or a lesson learned. Lucas: Absolutely. Next time, we're going to talk about something that might be even more controversial — why you might want to slow down your deployment frequency. Until then.