I think the author is using RFC not to strictly mean, "IEEE Standards Doc" but more, "a description of the problem you're solving and why also open for comments

I think the author is using RFC not to strictly mean, "IEEE Standards Doc" but more, "a description of the problem you're solving and why also open for comments". I guess in my experience shipping code gung-ho is great for about a year maybe two and then you really start getting to a point where every engineer just cakes their own great ideas on without a technical blueprint of what the company is actually building. Maybe that can be addressed by better technical management, but also in my experience technical managers are not great at conveying overall architecture and context (and perhaps it's not really their fault if non exists in the first place--but that's exactly the problem). I agree you're making a trade off but I don't think it has to be as hardcore as a 20 page specification for IPv10. A small startup with a few engineers can share contex and vision just fine.. until they can't. And the big win with RFCs is you put tribal knowledge down on paper up front instead of post facto. I think the main point I'm trying to make is that RFCs are a way to capture technical intent not just product requirements. It's not enough to just keep adding features whenever product asks for them (which is always and in a volume that's more than than you have time to do). You shouldn't have to get to the point where the thing or the business is going to fall over to get engineers to agree to build responsible software or refactor that shitty thing to actually work properly. I think RFCs help frame building software in an engineering-driven-but-product-inspired-and-business-context-aware way. That's how I want to work, anyway, but what you get with product-driven sprints is product-gets-their-way-and-business-context-is-solved-with-more-funding-for-that-aws-bill-and-for-more-eng-resources-to-build-more-product-value-so-you-can-charge-more-for-the-product.