I often see people believe in their solution and think theirs are better than the others’. They defend their cases without having an exact reason. These situations often create long and meaningless discussions that go nowhere. Often they result in conflicts and people being offended by others’ behavior.

Some people take action and implement their idea. Act fast, fail fast, and learn quicker. But this doesn’t work when two or more people discuss how to implement a change or use new hyped technology. When people only talk a bit and implement a new hype, it often ends up with resentment. When we act and embrace failing that fast, we cannot keep someone accountable.

On the other hand, some people try to get everyone’s confirmation to implement something that affects a large group. This strategy doesn’t work either. Because it’s impossible to get everyone on the same page, each person has a different opinion. When we try convincing everyone, we cannot implement anything at all. We just talk, and decisions come later than we need.

That’s why we need to balance both taking action and asking people to present their opinion on a topic. This balance is achievable with an excellent process. I helped build this balanced process in an organization where we aimed to solve another problem – the lack of feedback. We introduced a process called Request For Comments (RFC). It is a common feedback mechanism in the software world presented by the Internet Society (ISOC) and used currently in the Rust language.

The RFC process uses a document written by someone about their proposal on a topic. It has a specific timeframe and everyone can give feedback on it. The RFC and feedbacks are posted publicly. Everyone can join the discussion. The goal is to include as many people as possible to access more points of view and spread the knowledge simultaneously. The good thing is that people focus on the proposed idea and give their feedback based on facts instead of only beliefs. On the other hand, it has a way bigger effect.

While the initial goal of the RFC is collecting feedback, I think it achieves a way more significant benefit by only writing the document itself. Writing shapes thoughts. Everyone has an opinion on any topic. But people who write their ideas form them into great content that is based on the facts.

Writing helps to clear the mind. When we write on any topic, we separate our proposal from ourselves. It’s still part of us. But since we plan to present it to the public and leave it there forever, we start being careful. And most of the time, we are not starting with blank white paper.

The RFC processes use either a template or follow one standard style in documents. The aim is to help the authors to explain their plan in a structured way and, at the same time, make giving feedback easier. Each section of the document has its own goal, which helps separate the intent from the idea in a certain way.

We used the NABC model from Stanford. The model starts with defining the Need, followed by Approach, Benefits, and lastly, Competitors. Separating the Need from the Approach is very smart. While writing the need, the authors have to understand it very well. The approach and benefits sections are pretty straightforward, where authors define their strategy and list down the advantages. Since most people focus on them when they talk about ideas, it’s also easy to write. Then the competition section comes. It is the part the authors have to consider competitors of their proposal. Thinking about an alternative solution instead of their suggestion requires people to focus on the problem instead of blindly loving and defending their solutions. With these four parts, the NABC is a pretty good model. But it’s not the only one.

Everyone has different needs. Therefore the formats might differ. Our manager at work also came up with a way more straightforward structure with only four questions to answer. It was only for our team, while the engineering department had the RFC process for a wider audience.

The RFCs have another effect on the organization. The process seeks a consent-based environment, not a consensus-based one. If some people care about a topic a lot and come up with a written document that explains many things in detail, everyone can (and should) trust them. The authors shouldn’t wait for everyone’s confirmation of their proposal. When they get enough feedback, they should be able to continue further with or abandon the idea. It’s their decision. Since they prepared the doc and collected many comments on it, they can have a better judgment.

The process brings accountability, as well. Whoever writes the proposal should be kept accountable. When people know that they will be accountable, they tend to approach more carefully and consider different aspects seriously. Holding someone accountable doesn’t mean that there will be a blame in case of failure. It only means that they have to follow up on their proposals, make sure it results in some way, and answer questions on the way. Also, most of the time, the RFC process is separated from the implementation process. While the author is accountable for the RFC itself, the implementation can be done by different people, and the RFC author might not be involved in it at all.

These hidden gems of writing the idea in a structured way and asking people for comments afterward prevents many endless debates. The culture changes with it as well. Instead of endless debates, we create discussions and solutions based on facts. The process prevents people from talking and doing nothing. Even though the RFC process might not be perfect itself, writing is enough to halt the endless and meaningless discussions. It also helps build trust in the community. So, if you are new to the RFC system, start with writing down your proposal. I’m pretty sure that the result will be way better than expected.

Check out the comments on HackerNews.

Cover Photo by 30daysreplay Marketingberatung on Unsplash