RFC processes are a poor fit for most organizations
A while back, someone I know was frustrated that their organization seemed incapable of making progress on any but the most trivial security initiatives. I asked what happened when they proposed changes and they said:
[My organization] has a “document and discuss” framework […]. New security controls are introduced via that process including describing the goals, requirements, constraints, alternatives explored, etc. Rolling out those security controls rarely happens both because the process encourages endless debate and leadership redirects attention toward other tasks.
Upon further discussion, I found out that this “document and discuss” framework they mentioned was heavily inspired by the RFC process used by many standard bodies, most prominently by the Internet Engineering Task Force (IETF). This process, if you haven’t encountered it before, revolves around written proposals called “Requests for Comments” (RFCs), and an open and broad discussion about these RFCs. These RFCs form the foundation of much of the Internet – RFCs define things like HTTP, TCP/IP, email, and so on.
Many organizations see the broad success of RFCs in defining the modern Internet and decide to adopt something similar for use internally. This is a mistake: the RFC process clearly works for standards bodies, but RFCs are a bad fit for most corporate settings.
The IETF’s RFC home page holds a key hint to why they tend to work poorly outside of standards bodies:
Software developers, hardware manufacturers, and network operators around the world voluntarily implement and adopt the technical specifications described by RFCs.
Did you catch the problem? It’s these two words: “voluntarily implement.”
Why RFCs fail in corporate settings
The crux of the problem with RFC processes in corporate settings is that the process, as designed, doesn’t include any sort of decision-making framework. They are, as the person whose quote opened this piece described, a “document and discuss” framework – and not a decision-making framework. RFCs are written and discussed, but there’s no mechanism by which they’re formally adopted or rejected. Organizations choose to implement them (or don’t); they become standards through widespread voluntary adoption.
This means that, if engineering organizations naively adopt an RFC process without bolting on some sort of explicit decision-making step, the process quickly breaks down. Without some sort of process to move towards a decision, the default outcome of an RFC is “no” – so you end up with the kind of inaction the person I quoted up top was frustrated about.
In corporate settings, RFC processes tend to lead to endless discussion, especially as the organization grows. At one place I worked, the entire 150+ person engineering org was invited (and encouraged!) to comment on RFCs. This means there’s always someone who has another question or another concern, so discussions tend to run long enough that they fully burn out whatever initial energy to get things done was there at first.
This in turn rewards people who can write to exhaustion. I know one engineer who bragged that his trick of getting his proposals accepted was that he would write RFCs so incredibly long that nobody would want to spend the time to read the whole thing, thus making sure nobody objected. (He was pretty proud of this “hack”; I was horrified.)
Further, these processes are insensitive to expertise. Since everyone is invited to participate, they tend to put experts in a domain on even ground with everyone else. That seems really backwards to me: why go to the trouble of hiring or developing domain experts if we don’t give them the power to exercise their expertise?
Finally, RFC processes are insensitive to power dynamics and power structures. Companies don’t really operate in an even, egalitarian manner; there’s an explicit power structure. Certain things can’t happen without certain people’s buy-in. A hyperbolic example helps drive this home: if I, as an engineer, write an RFC calling for 100% raises for everyone on the team, it doesn’t really matter how much “consensus” I gather.
Fundamentally, when an organization adopts an RFC process without adding any sort of decision-making, that’s leadership abdicating their responsibility to lead. Consensus sounds nice in theory, but in practice if there isn’t a way to get to a “yes” or “no”, and quickly, inertia takes hold.
RFC-like processes can work, but only if there’s a well-designed decision-making process
Now, look, the desire to implement some sort of RFC comes from a good place. The general idea that organizations should document proposed changes and discuss them is a good one! Written proposals serve to focus and guide conversation and discussion in really positive ways, and having records of complex changes and the reasoning behind them is fantastic.
But you can’t just grab the RFC process and use it without problems. You need to have explicit decision-making step, something that drives the organization towards a clear decision, quickly and effectively. This process can be hierarchical (e.g. “manager decides”), democratic (“team votes”), or even consensus-driven if you understand how consensus-driven decision-making actually works (hint: it’s not “argue until everyone agrees”). In other words, you can’t just adopt a “document and discuss” framework; it needs to be “document, discuss, and then decide”.
Next up: let’s get concrete
How does this work in practice? That’s next in this series. In part 2, I’ll share a “document-discuss-decide” process that I’ve used and seen be very effective, and discuss a few alternatives. Stay tuned!