Most engineering teams write RFCs (Request for Comments) behind closed doors. In this episode, Lucas and Luna explore why publishing RFCs to the entire company — not just the engineering org — can catch architectural blind spots early, reduce rework, and build institutional knowledge. They dig into a case where a database migration proposal caught a critical data compliance issue because someone in legal spotted it during the public comment period. They discuss the trade-offs: more eyes means more noise, but also more signal. Lucas argues that the transparency forces authors to write more clearly, while Luna points out that it also democratizes decision-making beyond the senior engineers. They wrap with practical advice: start with one team, use a weekly digest to avoid notification fatigue, and treat RFCs as living documents, not one-and-done proposals. If you're a CTO or engineering manager looking to cut decision debt, this one's for you.