For protocols or standards RFCs are a natural fit because they are about mutually agreed upon communications and formats -- its self evident they must be based on consensus since the consensus itself is the core of what delivers value. Many software development tasks (including examples given by the author) do not have the characteristic of necessitating consensus so requiring RFCs seems to be a trade-off between consensus and other important things like velocity or iteration cycles, not essential complexity to solving the problem.
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.
It is never fun having to find out something has changed only after production release or later down the line.
Their solution to that was to make everything in the company revolve around the manager. After feeling personally hurt that they weren't included on every decision ever, now there's paperwork which can HOLD PEOPLE ACCOUNTABLE if they break "the documented rules".
Those darn workers better check those rules every time they're about to do something just in case, and if it's a new thing, ho boy, they better think twice because now they have to be prepared to wade through all that argumentation and red tape first.
This is awful and borderline mentally ill. It instills a fear culture into employees and ignores that developers want to write code. Instead it's trying to force them into the manager box of talking big and shouting each other down until an idea wins. Sick.
You know what the solution was? "Yeah, well they built it and it's pretty cool. If you want to do it in something else then make a better one." End of problem.
If this person was my manager I would be looking for a new job.
A team where everyone is doing things "their way", and then rebuilding it if it wasn't up to par is an enormous waste of resources.
Specifically, writing RFCs asks an engineer to articulate a design, consider and list the tradeoffs involved, and evaluate it against a set of motivating use cases. It also invites feedback: other people may have legitimate concerns or find blind spots. As the writer you don't have to make changes to incorporate everyone's views: it's up to you to decide on a case-by-case basis if their feedback needs to be incorporated or not.
Management decisions and associated rules will happen regardless of documentation. It is better to have a paper trail.
This point is mentioned but there's no clarification. As soon as you open up a design discussion to other members you're heading to design by committee territory, unless you take specific action to control it. Is there something in the formalized RFC process that addresses this?
It is an opportunity for you to get important feedback about aspects of the plan you might be under-informed about and make sure the relevant parties are aware of what is happening.
After feedback, you may decide your plan was flawed and needs adjustment, but just because there is disagreement doesn't mean you need to change your design to fit everyone's needs.
An RFC should seek to articulate the key constraints, surface every unique point of disagreement, and address every one of those. Sometimes, addressing such a point may involve changing the proposal; other times, it'll involve providing a considered and thoughtful response that amounts to "no, and here's why not". That may lead to someone dropping the objection on further consideration, or refining their concerns in an effort to better articulate what they value that they feel the proposal doesn't deal with. And occasionally, even after that, the answer may remain "no", and the objection will stay on record as disagreement with the consensus.
Unfortunately, many engineers and managers scoff at the idea of writing an RFC because of the traditionally poor UX instead preferring collaboration tools and diagrams. As a coworker once put it, "diagrams are weak sauce". Collaboration software is convenient for comments and visibility, but it fails to carry the same weight as an RFC and tends to produce more ephemeral artifacts. The best thing about writing an RFC is learning how people (mis)interpret your writing. If you want to win an engineer's heart, speak their language.
This is critical. One of the most important parts of the RFC process is that by its very nature it invites comment. It specifically invites people to poke holes in it, to find issue with it, to voice their concerns and be heard. While it doesn't promise unanimity, it promises consensus. And while every single objection may not be fully satisfied, every one of them should be addressed.
An RFC averts the tendency towards an overabundance of confidence, warranted or otherwise, and instead starts a discussion.
The big challenge is that developers tend to only think of "spec" as in "technical specs", whereas the most important specifications are the context, the goals and the history (the "function specs" in project management terms).
Formalising that into something like a RFC / PEP seems a great idea. Add in the email based discussions and it's the start of bringing democracy into the feudal corporate world
Assuming the author is reading this, how do you manage the feedback and decision-making process for these RFCs?
My opinion is that what to do with feedback and final decision authority rests with the proposal owner except under certain circumstances. Some of these would be if a component of the proposal is particularly complicated, clearly not completely understood by the team (e.g. there are dependencies on other teams that need more clarity), or contentious (e.g. major rewrites, switching to new frameworks or data storage and pipelines, etc.). In the latter I require consensus especially: proliferation of languages, data store solutions, and frameworks is a real problem and rarely a good solution.
Count yourself lucky if it's common for you :-)
I think documentation for others (your users) is still needed, but I rarely write documentation for myself or my team.
