HN Reader

Not a panacea for broken culture.

I've just left a company that used to have an internal RFC process and it was a very significant barrier to progress that stifled innovation, led to breakdown of working relationships and caused the most productive engineers to run for the exits.

RFC is a request for comments, and it turns out you have to be really careful about the kinds of comments you solicit and who from. As soon as you ask people to comment you are setting an expectation that you will take their feedback onboard and address their points, but there’s a real asymmetry here - it is much easier to leave a critical comment, or to ask a question, than it is to address the concerns or answer the question.

This asymmetrical nature puts much more work on the shoulders of the RFC author. Similarly, the people writing the RFC have typically thought much harder and longer and deeper about the problem than the people giving feedback on it. This leads to authors having to re-explain their thinking in detail, covering points that they’d omitted for brevity or because they are obvious to those with a good understanding of the problem.

Suddenly, the task changes from shipping the feature or making the change to achieving consensus on the RFC. I have seen that process take months - far longer, and being far more expensive than just doing the work would be.

The worst part is - no one is in the wrong! The authors write the RFC in good faith, the commenters review the RFC in good faith, and they rightly expect that any problems they identify are addressed. But the whole process can be soul crushingly slow, painful and full of professional conflict.

I’m not saying that RFCs are bad overall, but you have to have a culture of accountability, pragmatism and getting things done to actually make this process work.

> The RFC approach has several advantages over verbal alignment. First of all, it is more precise. The need to write forces the author to clearly structure their thoughts into a coherent logical narrative. While writing, the author has time to examine their proposed solution from different angles and clearly see pros and cons of it.

> Another advantage of the document over verbal explanation is that a well-written RFC leaves little room for misinterpretation. It can include diagrams, examples, or calculations to illustrate and support the idea.

> Finally, we can return and reread the RFC later. Human memory is unreliable; already after a day, details that were crystal clear in one’s mind start to get blurry. When these details are written down, it is easy to review them at any time.

‘You have to write things down, because spoken words disappear into the air,’ was one of the first bits of feedback I received in my teacher training.

> The most common objection is that writing proposals is “a waste of time” compared to writing code.

The extra time spent writing is actually spent thinking.

I've tried suggesting this for my team since there are constant complaints of lack of communication. However, the response to this is "we have Teams/Jira/Confluence", but 99% of Jira tickets have no comments for clarification, Confluence has articles that are out of date by 5 years and Teams is never used for clarifying requirements.

Love the title. Reminds me of one of my favorite quotes: "The single biggest problem in communication is the illusion that it has taken place."

This is what user stories were supposed to accomplish in a more lightweight way.

The whole scrum DoR (definition of ready) status means that something is clear and ready for development.

Stories are written and are sent to the engineering team for clarification. This is where the comments are supposed to come in. There is a clear step for clarification of stories, before the story is ready for development. It gets marked as DoR when that clarification is done.

It does not matter if you use RFCs, user stories, or hallway conversations as your process of clarifying work. If it does not work, it does not work.

Any way you can get your teams to communicate more clearly is great.

We started doing quarterly RFC at Newscatcher, and it was a big game-changer. We're entirely remote.

I got this idea from Netflix's founder's book "No Rules Rules" (highly recommend it)

Overall, I think the main idea is: context is what matters, and RFC helps you get your (mine, I'm the founder) vision into people's heads a bit more. Therefore, people can be more autonomous and move on faster.

Been trying to decide whether adopting a traditional RFC process or Oxide's RFD (https://rfd.shared.oxide.computer/rfd/0001) would better suit my team. We're using ADRs at the moment but we've ended up mixing a discussion like process into it and review process and using ADRs more like RFCs/RFDs

Linear should take notes. In my previous consulting and termed engagements the lack of a good standardized spec templates has been a problem. Of course we ultimately made those but it took much more in-fighting than it should have. If the platform already offers a few baked templates then discussions are much quicker resolved. Same as auto-formatting of code; metric tons of tiresome bikeshedding disappear almost overnight.

My current struggle is getting people to engage with my RFCs: that is, leaving comments. I certainly know they're not perfect, and I'd much rather know that before going into a meeting where we discuss the RFC. Especially so I can do any asynchronous research, or just spend some damned time thinking about it.

That being said, this is improving in my team. And I think the stakeholders above me appreciate it.

This guy invented a spec?

This seems to be a worthwhile exercise to explore -- formal but lightweight, and a lodestone during development.

That said, a ticketing system should ostensibly offer this same effect, but in my experience they're often populated with brief titles and maybe a short paragraph on expectations.

My favorite section in an RFC is "alternatives considered". I've seen many times that an option that had been initially discarded became the solution after review and discussion. It's also a great way to answer later questions about "why didn't you do X instead".

We use them internally. Works well but its not a replacement for a business requirement specification, however, it can help in the creation of a (better) one with greater buy-in from all stakeholders

Write a spec, or the developers will write one for you, in a much less clear language.

My interpretation is that this had little to do with specifics of RFCs, and everything to do with the verbal culture described.

I don’t care what format you use in terms of both process and also literal format. Just write shit down.

I’m the first person to say Amazon (AWS) was a shitty place to work. But I did learn a lot while there working in Professional Services. I still use modified versions of the PRFAQ when starting a consulting project now that I lead projects at a third party consulting company.

https://productstrategy.co/working-backwards-the-amazon-prfa...