Feedback loops are an important part of any product team. Every team should have multiple streams of feedback. One way to get feedback from your colleagues is to use a request for comments (RFC) system.
What is an RFC?
An RFC is … a memorandum describing methods, behaviors, research or innovations applicable to the working of the Internet and Internet-connected systems.
Simply put — an RFC is a document describing the action you would like to take and giving your peers the opportunity to provide feedback.
When should I add an RFC process?
At Field Nation I started thinking about introducing an RFC process when it became dificult to track the changes we were making, and, more importantly, the decisions that lead us to make these changes. We had a problem — teams are making decisions about how our software should work for their uses-cases, but do not have the context of the other team’s requirements. Futhermore, we had a communication problem. Each scrum team in our larger product team was moving so quickly that it became difficult to communicate why a team decided to make a change.
Two common problems are that it is difficult to document the changes you are making, and it is almost impossible to come to a consensus on the amount of “process” you want on your team. On most of my teams we want little to no process. The unfortunate truth is that these two issues are competing with each other. There needs to be some level of documentation, and that is going to require some sort of process.
Here’s the rub.
When considering adding a new process to your team you likely start hearing the complaints (or praises!) from your coworkers. Because of the ceremonies involved with the scrum process, any new suggestions can be exhausting for teams to talk about, let alone considering adoption.
By now most people in the software community have heard of the hurter. Some organizations might even swear by it. I frequently hear, “People over process,” and, if you start the conversation of adding something new, this will likely be an argument against it. Good news — an RFC system is all about putting your people first. It gives everyone a voice. It is an opt-in process. The author of an RFC is making a conversation available to everyone, but there is no requirement that people need to engage in it.
Why it will not make a difference.
I have been working on implementing an RFC process at Field Nation for six months. There are many challenges with the implementation, the biggest being getting people involved. It is a long process, and, if you decide that you want to start an RFC process in your organization, you need to evangelize it. If someone is not facilitating conversations in a public forum, then it will never happen. The most likely reason this will not work is that no one truly believes in it.
Why it will make a difference.
The area that I have noticed a significant change in is in our system architecture and API design. We have some great documentation on why our system was designed a specific way. This is huge! It can be difficult to recall the nuances of a system to new team members, and having living documentation, including detailed conversations, available for people will go a long way. The detail lost in spontaneous conversation might surprise you. Having a place to recall why you made specific decisions will greatly benefit both you and your organzation. Another benefit is that this process does a better job of respecting the time of your peers. You no longer need to interrupt someone every time you need feedback. This will allow team memebers the opportunity to think deeply about a problem before coming to a conclusion, while making those spontaneous, often disruptive, conversations more meaningful.
Implementing an RFC process is a long journey. It is not something you can decide one day, and implement the next. The process is alive, and ever-changing. Like anything else in an agile team it will take some time to grow into, and you may discover the same benefits I have. Or you won’t. There is no process that can fix all problems. As leaders we need to find ways to improve the quality of our conversations. How you achieve that is up to your product teams.