12,399 views

, 23 tweets, 4 min read

I just found out my current company has an RFC process. I was pleasantly surprised. But it also brought to mind the RFC process we had at my previous employer.

For those who don't know, an RFC is a Request For Comment and it has a venerable history on the internet. In addition to very serious work, such as defining a process for allocating IPs on a private network, RFCs can be . . . less serious.

ietf.org/rfc/rfc2324.txt

The idea is that nobody can know all of the implications of something you are working on, so you want to get as many people as possible to look at your proposal and poke holes in it. You'd rather find out there is a problem early so you don't build something that won't work.

In a company context, it makes sense to send out RFCs to every part of the company. You never know when some product change could impact marketing or sales or architecture or the community. The earlier you find out about another department's concerns, the better.

Before you read on, I want you to think about how this might go wrong in a company that was founded by programmer types and hired them almost exclusively for the first few years.

And now imagine there was no RFC process until after the company filled out non-engineering roles with people who were mostly not familiar with programmer culture on the internet.

And now picture the company had immense pressure to grow revenue.

Ok. Got something in mind?

Good.

Here's what happened:

RFCs written by engineers tended to be published early on in the project and contained a lot of technical details that non-engineers didn't understand or care about. Meanwhile, RFCs from non-engineers came late in the project when almost all the work was finished.

Engineering RFCs would get comments from other engineers and silence from other parts of the company. They usually went through several versions before finally being ready to implement. At that point it would become clear what was happening to non-engineers.

If the person working on the RFC were lucky, the thing they had worked on would be non-controversial. But if they were unlucky, someone from another department would slam on the brakes at the last moment. Silence didn't mean everyone was fine, but rather they hadn't read the RFC.

Obviously this is a waste of time. Better for engineers to send each other technical specs and not bother to ask for comments that arrived too late.

But worse were the non-engineering RFCs that described projects nearly ready to launch.

Engineers seeing an RFC naturally assumed they should comment on it. It's _expecially_ important to comment when you see a problem with the proposal. One might imagine that most, if not all, comments to an RFC would be negative. And some of the comments would be "Don't do this!"

It's easy to see what happened on the receiving end. To people not aware of how RFCs work, they seem like a part of a standard process to get sign off from stakeholders. It's not immediately clear why a developer should care about a new marketing initiative.

So instead of a routine checkpoint along in the go-to-market strategy, RFCs became a battleground between engineers and non-engineers.

To help lighten the process, someone put out a joke RFC. That didn't seem to help.

Another solution was to create an edict system so that you'd say something nice before ripping an RFC to shreds. I still try to do that, but it was too little too late. People had already soured on RFCs as a concept.

The sad thing is the company was publicly attempting to bridge the gap between technical people and not-so-technical people. It's something that still desperately needs doing. But after the RFC process failed, departments returned to their natural state: siloed.

In the last year, I started to see signs of real cross-team cooperation. I believe design was a driving force there. We also had a core values exercise which, whatever it's flaws, did bring people together across the company.

But back to RFCs. I think they help clarify projects early on if people take them in the right spirit. Engineers should consider writing an abstract (possibly with mockups) that explain what problem they are trying to solve and what it might mean for non-engineers.

It's a good idea to leave a mix of positive and negative comments. Think about how your words sound in the ears of someone who cares very deeply about the subject. Don't hold back criticism, but try not to gang up on the author.

Ultimately the problem was not limited to RFCs. Long after the RFC process was shuttered, the same fundamental problem happened on another opportunity for feedback.

stackoverflow.blog/2019/07/18/bui…

By failing to solve the communication divide between departments years ago, the company was set up for the sort of miscommunication I observed last year.

jlericson.com/2020/02/02/201…