I’ve listened to another great episode of Oxide and Friends on Requests for Discussion or RFD lately. And RFDs and Requests for Comments (RFC) kind of hit close to home for me.
In my previous role, we implemented a similar system as part of the decision process within our team. Every change that had touchpoints to other teams – For instance, a change on how we priced an add-on feature impacted the sales team, marketing and technical account management – are discussed by the broader team. A small change without impact on other tams would not need this.
To figure out where to draw the line between “needs a decision” and “can live in a ticket and get done with it” is the tricky one. But usually as soon as you start drafting your change, you will soon realize in which bucket the type of change shall land.
My feeling is that the RFD 1 of Oxide drives this need for a clear process. Because everything following after builds up on it. Which in itself is beautiful and helps to establish a thought out system design.
With the knowledge that at some point an organization wants or needs to obtain a certification such as ISO27001 or SOC2, this will just help to get there quicker. As you have a lot of company intrinsic knowledge in the RFDs. In the end, I think RFDs are very structured, even more so compared with the decision process we ran.
A company handbook might be less structured, but is also a nice way to publish process and information of the company. But in the end you have what you have.
While having this implemented on a team level, it’s not a good and not a terrible solution, but in retrospect I still think a company should have the RFD or a Decision Process as a base layer that forces each team to handle things similarly. I’m thinking a lot on how I’d structure my next endeavor and what would need to be implemented better if I start from a green field, and an RFD is right up there as one of the foundational things.
