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.
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.
> 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.
>> 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.
Until someone decides that using ChatGPT to write your RFC is a good idea. Then you get something that looks great, but the person behind the prompt actually understands less.
"Eventually they realized that this was something they were going to have to sort out, and they passed a law decreeing that anyone who had to carry a weapon as part of his normal Silastic work (policemen, security guards, primary school teachers, etc.) had to spend at least forty five minutes every day punching a sack of potatoes in order to work off his or her surplus aggressions. For a while this worked well, until someone thought that it would be much more efficient and less time-consuming if they just shot the potatoes instead. This led to a renewed enthusiasm for shooting all sorts of things..."
- Douglas Adams, "Life, the Universe, and Everything"
(It took an unreasonably long time to find this quote!)
>> 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.
Common theme for decades is "we can save a few days of planning with just a few weeks of programming".
But then there's the darker realization that sometimes the people you are working for are incapable of reasoning about planning artefacts or understanding how the system will look or operate simply from a document. So you need to present the system in small iterative chunks and repeatedly re-align expectations with reality: Agile.
And sometimes you genuinely need to do exploratory work which doesn't fit into a planning framework - actual research!
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
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.
It's not the lack of communication. IMO, it's the lack of team culture. Keeping documentation up to date is something only the team could do. And it can't be solved by using Confluence/Wiki/mailing lists tools.
It's clearer if you deconstruct the conversation about Jira and then think about the washing hair and shampoo comment. It's a stretch, but when you see it is should make sense.
I ask my team to clarify requirements better. They say that they already have Jira. It's as if they were implying that the presence of a tool (Jira) should be enough to provide clear stories. But it's not about the tool. It's about them not using the tool properly but pointing at the tool (or process) as an excuse.
I ask my son to wash his hair. He says there is shampoo in the shower. It's as if the presence of the shampoo implies that his hair should be clean. It's not about the lack of tooling, but about the fact that he did not wash his hair with the tool that he had available.
People often blame tooling or methodology, but most often its that they don't know how to use the tooling or methodology well. They will say things like "if we only used X our problems would go away." Most likely, they won't.
I posted a lazy comment earlier because I did not have time to type it out. Apologies.
I see, thanks. All analogies are flawed and that's a fact of life but your clarification made it crystal clear.
RE: your work, I would probably fight hard to reduce all the bureaucracy-inviting tools (like Jira). That removes the excuse "we have tools already, why don't we have clear stories?" -- though I am aware that for many people this fight would cost them their job.
He's saying that there's shampoo in the shower but he didn't use it (implied) -- however, the question wasn't about the presence of shampoo in the shower.
Aha, but that's not a rebuttal at all. The son is just stating a rather very loosely connected fact. If I was the father I'd immediately respond with "Yeah, and?".
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.
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
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.
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.
> That said, a ticketing system should ostensibly offer this same effect
If the ticketing system were private to the engineers, it probably would serve the same purpose. But inevitably ticketing systems have wider visibility, and become a mechanism for signalling progress to management/product/sales... at which point engineers are actively incentivised not to put actual data in the ticketing system
We usually use this before tickets are even created.
In many cases, an RFC can lead to an epic-level ticket that includes multiple user stories.
In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.
A benefit of the RFC approach is if it lives in the repo itself the documentation is along side the code.
Anything that will prompt stakeholders to engage and clarify expectations is a win. It's hard to make this happen even when everybody is philosophically aligned on the need to do so, so reframing it as an RFC could be quite the useful "One Weird Trick" ;-).
Ticketing systems inevitably get Goodharted. Everyone starts in good faith, then the manager starts using the number of tickets closed, touched, etc as a proxy for work being done, then the agents replace number of tickets with things actually accomplished.
It's not a foregone conclusion. I've had great success writing BDD-style literate tests (not using a framework, just comments that follow a particular grammar). They've allowed verbally negotiating the approximate expected specification, and dealing with the realities of what comes up once you start writing code. But you end up with a spec, expressed as a number of BDD scenarios.
Obviously this does't work for all software. But it suits systems with end-to-end behaviour and sequences of actions.
So it's possible to leave it to developers, but expect a high quality spec along with the code.
In our org, an RFC precedes a tech spec. The RFC literally is the "let's formally talk about this before we nail down a specification". For smaller specs, annotated comments can serve this purpose. Before this process, what we had found was no one was paying attention to tech discussions in our eng slack channels. Having an RFC gave us an inflection point where we could point back and say, "an official discussion happened, we decided to move forward with a spec".
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.
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.
> 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.
> The extra time spent writing is actually spent thinking.
Until someone decides that using ChatGPT to write your RFC is a good idea. Then you get something that looks great, but the person behind the prompt actually understands less.
- Douglas Adams, "Life, the Universe, and Everything"
(It took an unreasonably long time to find this quote!)
> The extra time spent writing is actually spent thinking.
Common theme for decades is "we can save a few days of planning with just a few weeks of programming".
But then there's the darker realization that sometimes the people you are working for are incapable of reasoning about planning artefacts or understanding how the system will look or operate simply from a document. So you need to present the system in small iterative chunks and repeatedly re-align expectations with reality: Agile.
And sometimes you genuinely need to do exploratory work which doesn't fit into a planning framework - actual research!
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.
I am right and my son is right, but his hair is still not washed.
I became a more effective manager and a better father when I learned how to talk to him better.
I also don't get your son's response at all. How is he contradicting you at all and how does that lead to unwashed hair?
I ask my team to clarify requirements better. They say that they already have Jira. It's as if they were implying that the presence of a tool (Jira) should be enough to provide clear stories. But it's not about the tool. It's about them not using the tool properly but pointing at the tool (or process) as an excuse.
I ask my son to wash his hair. He says there is shampoo in the shower. It's as if the presence of the shampoo implies that his hair should be clean. It's not about the lack of tooling, but about the fact that he did not wash his hair with the tool that he had available.
People often blame tooling or methodology, but most often its that they don't know how to use the tooling or methodology well. They will say things like "if we only used X our problems would go away." Most likely, they won't.
I posted a lazy comment earlier because I did not have time to type it out. Apologies.
RE: your work, I would probably fight hard to reduce all the bureaucracy-inviting tools (like Jira). That removes the excuse "we have tools already, why don't we have clear stories?" -- though I am aware that for many people this fight would cost them their job.
https://productstrategy.co/working-backwards-the-amazon-prfa...
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.
If the ticketing system were private to the engineers, it probably would serve the same purpose. But inevitably ticketing systems have wider visibility, and become a mechanism for signalling progress to management/product/sales... at which point engineers are actively incentivised not to put actual data in the ticketing system
In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.
Anything that will prompt stakeholders to engage and clarify expectations is a win. It's hard to make this happen even when everybody is philosophically aligned on the need to do so, so reframing it as an RFC could be quite the useful "One Weird Trick" ;-).
Obviously this does't work for all software. But it suits systems with end-to-end behaviour and sequences of actions.
So it's possible to leave it to developers, but expect a high quality spec along with the code.