👋 Hey {{first_name|there}},
Your team has a decision that keeps coming back around. I don't think it needs more discussion. It needs one page, written so people actually finish it.
Why this matters / where it hurts
Sometime last year, I watched the same architecture question surface in a chat channel for the fourth time. Should the reporting workload move off the primary database, or not. Every few weeks, someone reopened it, two or three people weighed in, the thread drifted, and nothing changed. By the fourth round, even the people arguing sounded tired of their own positions.
This is decision churn. It shows up as the design review that runs for sixty minutes and ends with nobody in the room able to say yes. Or the twelve-page RFC everyone means to read later. Or it's a trade-off that gets settled in a thread, the loudest message winning over the strongest argument. And the lost hours are a small part of it. The higher cost is the half-built compromises that ship anyway, while the decision they depend on sits open.
In Lesson #40 we covered ADRs, which record a decision after you have made it. Useful, but an ADR assumes the hard part is already done. The RFC is the document that comes before it. If the term is new to you, RFC stands for Request for Comments, and in practice, it is just a short written proposal you circulate so people can react to it before anything gets locked in. The name comes from how early internet standards were drafted, though most teams use it far more loosely than that. This week is about writing the kind people actually read, then running the review so it ends in a decision. If you want the meeting side of that, the 30-minute architecture review issue pairs well with it.
🧭 The shift
From: A strong technical document is thorough. It answers every question before anyone can ask it.
To: The RFC that works is one that people can finish in a single sitting, built so that disagreement lands on specific lines instead of a vague bad feeling.
The long document feels safer to write. More of it feels like more protection. In practice it does the opposite: a reader who cannot finish your doc will not approve it, so they defer, and deferral is just churn with better manners. Most stuck RFCs aren't wrong. They just never got finished, by the reader I mean, not the writer.
Dumbing it down is not the fix. The fix is remembering what the document is for. An RFC has one job, which is to get a specific person to say yes, no, or "change this one thing." It is a decision tool, not a place to store everything you know.
Lead with the cost of doing nothing. Stakeholders fund problems they can feel, not architectures they admire.
Show the options you rejected and the reason each one lost. A doc with a single option reads like a sales pitch, and people instinctively resist being sold to.
Put the decision, the decider, and the deadline on the first page. With no owner for the yes, the document just turns into another thread.
📘 The Career Guide got an upgrade
I just finished a major update to the From Developer to Architect career guide. It now includes a self-assessment rubric, a week-by-week 90-day growth plan, architecture artifact templates, and interview prep frameworks. If you're actively working toward a Staff, Tech Lead, or Architect role, this is the structured roadmap.
Free download here: https://www.techarchitectinsights.com/from-developer-to-architect-free-career-guide