WTH is an RFC, why I need them & what makes a good one?

The partial answer to that is: "it depends on who you ask". RFC can stand for either Request for Change or Request for Comment - for the purposes of this article for the former I will use one of its synonyms Change Request (CR) and save the RFC for the latter (Request for Comments)

CRs are requests for a change to a system either in development or in operations and are governed via a change management process; CRs for operations are typically more detailed and risk averse than changes to systems in development and for good reason. Will not discuss CRs further, but here is a good checklist of what they should contain.

What about RFCs though? The history of RFCs ties with the history of the Internet; simply put they come from the 60s (yeap 1969 just making the cut), are written in ascii and you can find them using RFC Editor. The original RFCs were essentially proposed standards / methods that were opened up for input and peer review to a (select and limited) at the time audience.

There has been a growing trend in the last years for companies to adopt the notion of RFCs to enact change internally and as a solution to some of the challenges of scaling. But why RFCs and not CRs if CRs spell out change literally in their name? Because CRs target system changes while RFC target people and process changes, with ultimate goal to drive decision making. Let's explore that further.

An RFC is the embodiment of an idea; a captured conversation which is beyond a pair exchange, beyond the raw output of a brainstorm session, beyond a back of the napkin design solving a problem at the pub.

It is taking any or all of that and shifting it to the next level by giving it enough rigour to be able to meaningfully present it to someone else, debate the merits of some options and be able to pick a way forward. All while not turning it into a multi-volume waterfall-like specification and enter analysis paralysis or remain fearful of making a commitment.

Good comments are critical to an RFC, but good comments have prerequisites; the key prerequisites are what make a good RFC. Here is my take on them (and while it is tempting to keep adding keeping the bare minimum is another key prerequisite):

1. Why. The reason why this RFC is written and needs to be read in the first place. Basically the justification for its existence - should we be spending time on this, is this a problem that is relevant to achieving a business outcome? Ideally linking to that business outcome / product feature or initiative that it aims to address. If this is missing, that is a bad smell that it is a solution looking for a problem.
2. What. What is the problem that is being addressed; with the problem being defined as tight as possible and with a clear view of its boundaries using an in-scope/out-of scope or goals / non goals demarcation.
3. How. The stake in the ground. This is what we are doing to solve the problem, unless a different / better solution arises through this RFC approval process.
4. Alternatives Considered. The other roads that were considered but rejected and the why. This is important as if the goalposts change or the constraints around the problem are reset suddenly another alternative option may emerge as more suitable.
5. Costs. This is often an overlooked area. Costs should include engineering costs and operational costs - does the solution require a 3rd party service subscription? Is the cost usage and scale dependent and if so what capacity model has been used for the solution?
6. Risks. This can be debated as non bare-minimum. Almost on the fence on this personally (depends a bit on internal organisational knowledge and/or previous POCs) but I like it because including it makes the RFC mirror more the benefit-cost-risk tuple of a traditional business case.
7. Impacts. This is about being a good neighbour and show consideration for others. Say the proposed solution does not impact the team developing the solution but has impacts downstream to other teams or disciplines. That is important to call out as this arguably constitutes external costs (not necessarily financial) but costs in time, people's satisfaction within the organisation etc.
8. Measure of success. Fast forward in time, your RFC has both been approved and implemented. Did it succeed? How would you know? By setting up upfront what success look like you will be able to confirm using data if the RFC suggested approach met its objectives (granted you can't possibly know if the selected option is -based on evidence- better than the alternatives, but if that was a key consideration then a proof of concept (POC) between different options would be a better vehicle)
9. Future development. This is part of thinking bigger. Yes, by necessity we have limited the scope of the problem to solve so as not to enter a boil the ocean scenario. However we can peek a bit further ahead and see what is just outside the boundaries, what if they were extended a bit or the constraint of the problem (typically timelines) were extended. Does this RFC address the problem in the short/ medium or long term? Whatever it targets this is the area to highlight what the solution could look like in its next iterations from a features and benefits perspective.
10. State. RFCs need to have a process behind them to guide them through their lifecycle. Possibly starting with a draft, allowing for a certain period of time to collect comments, maybe a predetermined round of conversations/redrafts and then an approval workflow subject to your organisation maturity and scale.

Last, RFCs are not a goal in their own right; fast, impactful decision making is. Your RFCs need to morph as required to facilitate and support that now and as you scale.