Writing up a request for comments
A story about doing the necessary investigation required for sustainable organisational change
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. — Antoine de Saint-Exupery
“Change” is a funny thing. It’s inherently destructive, and yet without it we never improve upon our processes, implementations or anything else. So, it’s both a necessary evil and something to be cautious of.
Specifically, I’m speaking about large changes, rather than the incrementalism that defines all professions. Fundamental, “let’s move this app from ec2 to kubernetes” or “let’s rebuild our hiring framework” type changes. The sort of changes that done well can net a multitude increase in productivity, but done badly can isolate, offend and demean team members.
Among the best ways to generate the necessary feedback to “sound out” whether a change makes sense is the “request for comments” process, or RFC. This has a long history particularly intertwined with the internet but is adopted for large, important software projects such as PHP. Even absent the process inherent in these examples, writing up something that resembles a request for comments is still extremely useful, in that it means:
- We need to define the problem in some detail
- We need to spell out how their solution works
- We can be challenged directly on our assumptions, as well as why other solutions aren’t as good
- We (or others) can follow up whether changes had the anticipated effect
- Means we’re explicit at both intended and actual ROI
Such a document takes some considerable time to write but such major changes will take multitudes more time to implement, and time spent investigating how this change will impact the organisation and how best to roll it out is time well spent.
To be clear, this document is both:
- An investigatory document
- A sales document
Change hasn’t happened before as there is not the desire or the will to implement it. Accordingly, while investigating the constraints of a change is necessary, pushing the change through is an act of changing how people feel.
The RFC
A template for this can be found on GitHub’s Gists section, but below we go through each of the components of the RFC:
Abstract
A summary of the proposal, including description, benefits, risks and estimated costs. Some general guidelines include:
- Keep this short
- Pique interest
Quite often, it is better to write the abstract last after the proposal has been written.
Stakeholders
A proposal affects more people then it may initially seem. While proposing a change may make sense from the authors point of view, the author should consider the ramifications to others, and document in the proposal how this change will affect them. Some example stakeholders include:
- Business Team
- Marketing Team
- Development Team
- Administration Team
Problem
An outline of the problem that the proposed solution will solve. If a proposal does not solve a problem it is worthless. Outline any efficiency improvements as problems. For Example:
"On mobile, connections are slow"
rather than
"with HTTP/2 mobile load times will decrease".
Hook into a metric that the reader cares about.
"lower page load times are correlated with decreased user engagement and, by association, cart abandonment"
Fear vs. Hope: There are broadly two strategies for engendering change; creating the idea that things will be better after change, or convincing people that it’s dangerous not to change. They are both useful strategies, but for different reasons.
Fear is most useful when trying to get a user to stop a given behaviour, for example “stop posting to social media with each deployment”. Conversely, Hope is useful for eliciting a new behaviour, such as “please adopt my thing it will make things better”
Evidence: Unless the writing can be backed up by references either generated through experience in the company (post mortem, case study) or external it will do no good as part of the RFC. If it is not possible to draw some evidence from the broader community clearly state that there is a lack of evidence to make a decision either way, and this RFC is experimental.
Content without references can be easily picked apart, and will discredit the rest of the RFC regardless of how well the rest of the RFC was written.
Solution
The solution to the problem as defined in ‘problem’ section.
Example: "Implement HTTP/2 to make the TCP connection more efficient"
When writing the solution out there are ways in which the solution can be expressed that are more likely to lead to higher “buy in”.
Side Benefits: Decisions in which the benefits will manifest in the future are subject to biases; the classic example being overspending in the short term at the cost of the long term. To address this be sure to make it clear the immediate benefits of such a solution.
Verification: Any proposal will invariably cause some level of change. In order to determine whether the proposal should be retained after an initial trial period it should be clear how to measure the success or failure of such a system.
There should be an anticipated measurable change in some thing that this proposal seeks to change. If there are no metrics about what it plans to change, first instrument that thing then plan the change.
Anticipated Difficulties
Any set of change will come with it a set of difficulties. The greater the change, the more it’s likely to cause a disruption — to cause problems. It is better to find and estimate these new issues, as well as illustrate how they can be addressed to mitigate any damage. Even if a problem does not have a solution, list it regardless. A problem with a solution is better, but opening up the problem for discussion may contribute a greater chance of the change being accepted.
Risks
Risks are new things that may provide unexpected difficulties as a result of the change. Risks are different than anticipated problems in that they’re accepted as an event that may happen, but not one that will definitely happen. For example, a proposal may increase costs for a short period. Or it may cause a level of disenfranchisement to the affected team.
Previous Examples
Previous examples are useful to give credence to the idea that this proposal is possible, as well as give consumers of the proposal ways they can find answers to questions that this proposal does not address.
Even failing examples may be useful as a mechanism to illustrate risks, and how they’re mitigated in this particular iteration.
Expert Opinion
Experts in a given area can help provide a measure of credibility to the proposal, as well as allow users to follow up with those users to seek further clarification on the issues that they’re raising.
Additionally, it is a more human assessment to make a decision based on the credibility of a perceived expert, rather than attempt to determine the logical basis for the analysis.
Estimated Costs
Estimated costs are the required expenditure to implement the change.
There can be several facets to the costs:
- Development time, or the time required to roll out the change.
- New equipment / product / system purchase
- Reskilling time, or time lost to team members being required to re-skill to operate in the changed environment.
Implementation
The steps the organisation will go through to implement the change. It’s helpful when thinking about the implementation to consider each of the steps that people will take.
For example, users will generally try and fit a new change into their existing workflow as easily as possible, using their existing knowledge on this new problem. As much as possible it’s important to allow them to do this; while this can mean the change takes longer, it’s much more likely to see a wider adoption.
Generally speaking it’s easier to roll out a change in stages:
Proof of Concept: A single example of something being useful to a team. Not necessarily a successful proposal, but rather a sample and demonstration of what a potential rollout might look like.
Scale: Replication of the proof of concept. This may take the form of being one chunk of the business / entity after the other, rather than an all-in-one rollout.
Enforcement: Immediately following the change, as well as indefinitely after if the change requires a greater level of effort for users there will be a temptation to fall back into the old behaviour.
To retain the new behaviour there needs to be a control loop; some way of encouraging users to keep to the new behavior, even though the old may be easier. Perhaps the best example of this is Continuous Integration, but simply reminding people periodically of how and why we do things is useful.
Completion & Evaluation
Once a proposal has been rolled out, it needs to be subject to evaluation. Change is wildly unpredictable, and should be subject to critical analysis.
There should be several points at which a proposal is evaluated:
30 days — Determine whether the proposal is being implemented as anticipated, and has sufficient buy in from the community to push forward 90 days — Determine whether the proposal had the anticipated effect 365 days — Determine how well the proposal worked, and if there are any lessons that may impact future proposals.
Changes should have a mechanism for users to submit feedback directly, rather than needing to wait for an evaluation window.
Rollback
Though much effort has been put in to making sure proposals are successful, many (perhaps most) of them will fail. The nature of the status quo is it’s economically given to be the status quote — to change it will require changing the economy itself.
Accordingly, all proposals should have a mechanism to “fail back” to the status quo. Whether this is early termination, a limited trial or a specific set of steps required to change defaults from their new state back to their previous, changes should be reversible.
Terminology exposes any words that may be unfamiliar to the intended audience of this RFC (likely non-specialist executive stakeholders)
References
Generally speaking these should be automatically generated; I use the Bibtex extension for Asciidoctor, and mark things up in APA format.
In Conclusion
Change is a difficult topic — far more so than it may seem at the outset. It can upset people, cause chaos, break timelines and budgets and generally be a difficult thing indeed. However, organisations that do not change wither on the vine, eventually succumbing to another, more agile company.
Hopefully this has been useful to you as a method to help you plan any organisational change you’d like to push through.
Post Script
I use a template for these now. You can see it here!
❤
