Request for Comments: Psychological safety
Posted 2020-06-23
A request for comments (RFC) is a kind of document written by engineers to record meeting notes, outstanding decisions to be made, and standards to comply with. This standard of formatting and style has been around since the early days of the internet, and serves as a medium for evolution.
The RFC format is helpful in part because the internet evolves by means of de facto standards. In other words, the internet only means what people agree it means, so controlling its evolution is done by asking others to agree with a proposal. Historically, this property has led to political posturing and strife, but that is not the topic of this blog post.
Relatively recently, the RFC process has been internally adopted by software development companies as a means of driving internal change and agreement. This could include writing new software, choosing new features, identifying and declaring a strategic product direction, or declaring bankruptcy on a known bug or issue. This blog post is about using RFC in the workplace, and some of the implications I've observed.
Cities
We can look to information theory to rationalise why large groups tend towards this familiar, organic pattern of interlinked clusters, both in the micro scale (bacteria on a petri dish), and on the macro scale (city street connectivity in a sprawling metropolis).
The pattern common in those two cases seems to be quantity of individuals that compose the group. However, I claim that this pattern is not dependent on quantity, and also that groups in high quantity sometimes don't form such patterns - ant hills and beehives, for example, are more crystalline in structure. This seems to reflect their authoritarian societies (at least tangentially related to this blog post!)
Rather than quantity, I believe that the relationships and information sharing between the entities in the group are what tend towards the familiar neural network shape. Specifically, the entities in the group tend to be:
- chaotic, acting independently
- adversarial, in the sense that they may be competing for the same attention or resources
- directionally aligned, in that they at least broadly agree on what good looks like
- limited communication, either because conversations are expensive, or are infeasible to organise
Today's software development companies often fit this description - sometimes because they're sprawling, as in $BigCompany, and other times because they're chaotic. One such example of chaos is in product environments where microservices consume one another without understanding or necessarily caring about the full call stack or side-effects of some remote procedure call.
If you expose an API with some contract of uptime, and definition of client expectations, then my freedom to consume from you stands to benefit both of us: it enables me to achieve my outcomes faster, you to realise value in a resource you expect to be general purpose, and both of us to be satisfied in sharing and contributing towards some sort of society.
The RFC process serves as the low-bandwidth, low-barrier communication medium for chaotic - even adversarial - entities, including in the workplace. It's a powerful tool for maintaining alignment between groups that have different motivations and goals. It stands to benefit not only software developers working on unrelated products, but also for entirely disparate business areas that may find themselves at odds.
So, even if you're a CIO, I recommend trying out the RFC process next time you want buy-in from the CFO (or any other combination of CxOs).
Psychological safety
What's the alternative to the RFC process? I can think of a few:
- Meeting hell
- Demand-based change (and by extension, some kind of hierarchy)
- Nothing at all (chaos)
Organisations tend to be in one of the first two categories - either highly dependent on a large volume of meetings, or highly dependent on some omnipotent decision-maker who can force relevant teams to cooporate when appropriate. Clearly, companies that employ the RFC process for internal agreement still have some structure, and still run meetings. My claim is that the company's culture will typically be meeting-heavy or highly hierarchical, and the RFC process can serve to reduce the need on both.
Sidebar: it's possible to run highly effective meetings, and also possible to build a company culture that fosters sharing and reuse without creating adversarial relationships. These things are important - but they're important to do in supplement of considering better mediums of communication. I claim that running good meetings and promoting a healthy company culture may be insufficient.
Psychological safety is the concept of achieving confidence in one's ability to provide their opinion without fear of consequences or repurcussions. It's often discussed in conjunction with company culture, where a healthy company culture democratises the opinions of its employees, chooses solutions based on technical merit, and fosters growth and development around why some best idea wins. Without psychological safety, your company culture can only achieve such things among those whose opinions were elevated above some baseline.
I have noticed that developer-types seem to lean towards the RFC process, rather than meetings. I was once in a meeting with a senior engineer who sat mostly quietly, nodding in agreement during the meeting. At the end, he started shouting at the meeting organiser for not providing an agenda, inviting too many people, and not really achieving anything.
Was that engineer overreacting, being inappropriate, egregious, even extreme? Yes, but they also weren't (entirely) wrong. When you get used to using RFC for driving agreement, a 30 minute meeting with five people can rapidly become unacceptable.
Here are some factors to think about when comparing communication mediums and psychological safety:
| RFC | Meetings | |
|---|---|---|
| Every opinion counts | Low bar for writing and commenting | Need buy-in to call a meeting; may need to interrupt conversation to provide an opinion |
| Preparation needed | Order of days or weeks to comment at your own pace | Pressure to make decisions or come to agreement during the conversation |
| Vocal eloquence/ideas pre-formulated | Low bar, reader just needs to understand the writer; effort-dependent | Grand statements, english prowess have big impact; respected individuals tend to quell conversation |
| Visibility | Every opinion remains as a comment; very likely people will read your comment | Someone is likely to end up being "right" during the meeting, and other opinions become lost entirely |
The RFC process lends itself better to a psychologically safe culture. It creates a decision model that's far more merit-based, and far more fair for people who don't speak English as their first language.
Good
Organisations typically make decisions - for better or for worse - by defining success criteria and otherwise some kind of definitions of good. This applies to product changes, for example in the form of SLIs; and it applies to business projects, for example in measuring and confirming change or agreement.
A good meeting includes these things, but doesn't dwell on them - people tend to agree to some broad explanation of how measuring good might look.
A good RFC, because of visibility and merit, might not get away with that kind of cowboy approach - so RFCs may sometimes focus too much on measurement and definition of done.
I provide this as a limitation to the value of RFC. As a cowboy myself, I tend to prefer the lightweight version of defining good.
In Conclusion
RFC is a powerful communication tool for aligning interests on projects. I recommend it - whether you're a product developer or not.
I also recommend writing your RFCs as though you're presenting to adversarial or chaotic actors, and as though you're setting up, running, and tearing down a high-quality meeting from end-to-end.