I worked for a company that followed a similar process. This worked really well, except for one thing which I blame the terrible culture at that company, which is: Some times people would have strong disagreements on how to do something, so you end up with two competing RFCs to solve the same problem, which basically divided engineering into three camps: one for each proposal, and the people which don't care.
It is not that one of the proposals is wrong and the other is right, it is just that they make different trade offs and the teams/engineers behind them have different preferences and backgrounds, probably both would work, with different long term consequences.
At this point I think it is where you need A) Strong management/tech leads/seniors/principals/architects/whatever which can make a call of what direction to take, and B) Clear company principles which would guide those leaders into making the decision, such as "We go with option 1 because we value more simplicity over performance, using external services over NIH, etc...
Once a decision is made to resolve the conflict, some people will not be happy. But that's better than having everyone unhappy because everyone is blocked on working on competing solutions at the same time.
This company I was working for, had a TERRIBLE (the worst I've ever seen) management/leaders... (and some of those leaders where even very popular opensource developers) you had the ones that just didn't care about anything except they paycheck, and the ones that just said yes to everyone and to everything to keep everyone happy, which led more than once to competing solutions implemented in parallel (just imagine the codebase we had....). I even remember one time some team decided to go crazy with monorepos and building an entire platform of tooling around it and when we asked for the Proposal (our name for RFCs) they just wrote it on the fly and showed it a few days later.... no need to say they had to "invent" the need to make their already built solution "fit".
So yes, this process is great, but you also need 1) Great/responsible leaders and 2) A not so shitty culture.
It is not that one of the proposals is wrong and the other is right, it is just that they make different trade offs and the teams/engineers behind them have different preferences and backgrounds, probably both would work, with different long term consequences.
At this point I think it is where you need A) Strong management/tech leads/seniors/principals/architects/whatever which can make a call of what direction to take, and B) Clear company principles which would guide those leaders into making the decision, such as "We go with option 1 because we value more simplicity over performance, using external services over NIH, etc...
Once a decision is made to resolve the conflict, some people will not be happy. But that's better than having everyone unhappy because everyone is blocked on working on competing solutions at the same time.
This company I was working for, had a TERRIBLE (the worst I've ever seen) management/leaders... (and some of those leaders where even very popular opensource developers) you had the ones that just didn't care about anything except they paycheck, and the ones that just said yes to everyone and to everything to keep everyone happy, which led more than once to competing solutions implemented in parallel (just imagine the codebase we had....). I even remember one time some team decided to go crazy with monorepos and building an entire platform of tooling around it and when we asked for the Proposal (our name for RFCs) they just wrote it on the fly and showed it a few days later.... no need to say they had to "invent" the need to make their already built solution "fit".
So yes, this process is great, but you also need 1) Great/responsible leaders and 2) A not so shitty culture.