For anyone that’s worked at a startup, you’ll know making decisions, particularly in engineering, is really easy. There’s only a few of you. You probably sit right next to each other. You have a chat, make the decision, move on and never look back.
But as your startup moves into a scale up, you all of a sudden have more than 1 engineering squad and you have to start implementing chapters and guilds to keep things aligned. The more you have (and the faster you get there), the harder it is to make sure the right people are either informed or consulted on decisions that could shape the direction of anything from the squad, all the way up to the entire platform. Let alone the impact it can have on multiple areas of engineering if teams make these decisions in silos.
The immediate need to surround decisions in process inevitably hampers speed, productivity and ultimately you stifle very creative individuals by, as my boss likes to refer to, ‘making them walk through treacle’.
Tackling this problem is not easy, it’s a fine line, and this is our current iteration.
We use RFC’s to tackle this problem. Everyone that works in technology is aware of RFC’s (Request For Comment), it’s how the internet was built, slowly. But how do we use them?
How we use RFC’s
Whenever we talk about RFC’s and pace in the same sentence, people give us funny looks. All the big decisions about how the internet works, how protocols work are all handled by RFC’s and they take an age to mature. But they don’t have to.
The basic concept is very simple and the way that it’s applied makes all the difference, especially in terms of being able to maintain pace and autonomy.
Our goals are to ensure all teams and individuals have the facility to make changes anywhere in the stack; they can contribute and have a sense of ownership over it. It’s also really important that teams can move quickly and maintain their autonomous nature.
Basic RFC process
Decide if you need to raise one. Not sure? Speak to an Engineering Manager
Write the RFC
RFC announced at upcoming Engineering Forum and in the RFC Slack channel
Open for comments and discussion
We come to an agreement or compromise (weeks not months)
Git merge RFC
RFC process
Deciding When To Raise An RFC
Deciding when an RFC is appropriate is the key to success here. It’s really important to think of the RFC in this context as being extremely flexible.
It can be a decision making process for anything that has far reaching implications within engineering. Or it can be a simple decision log for your own team's decisions. We have 1 team that runs them internally for everything they do, so they can easily refer back to it for themselves and new joiners in the team.
It can hold as much detail as you like on how you arrived at that decision; holding data from spikes, POC’s or research etc. The important part to consider is, “will the changes proposed have any impact outside your own team?” If so, it’s worth canvassing for input from across engineering.
Write the RFC
You should think of it as RFC lite. We use a template that consists of basic headings that teams need to explain, like domain, impact, scope, proposal. They don’t need to fill everything out, but the more useful info they put in there, the fewer comments they’ll have to address.
The RFC can be as detailed or as abstract as teams like; they can use one as the catalyst to start a conversation, or they can use one to finalise a decision. Once they have everything on the doc, they can start to socialise their RFC.
We use Github, it’s perfect for this use case. The RFC is in MD format, and the PR serves as opening up the RFC for comment. We can then use the GitHub PR comments feature so teams can work async. We don’t want this process to turn into a decision making group, so it’s really important we are able to work on these asynchronously.
RFC Announced (socialisation)
The raising of an RFC requires socialisation so everyone is aware and can comment. We use a few avenues for this;
A slack channel where all new RFC’s are announced (but not debated, that happens in the PR). This way people can always see when a new one has been raised and whether they should look into it more.
They’re also announced at our fortnightly engineering forum session. It’s an informal session for all of engineering to talk about any topic, engineering related, that they want to.
Comments and Discussion
Engineers and teams can then comment in the PR on specific lines, or ask general comments. Updates can be made and we get to keep a history of this as it’s all in Github.
Agreement
Typically, teams and chapters are able to come to an agreement themselves. All the senior engineers are hands-on, and we believe they’re all best placed to be making these decisions. Again, we don’t need or want a centralised decision making group, that stifles everything we care about and want our engineers to care about, pace, creativity, autonomy and ownership.
Teams use spikes and data to inform their decisions, so very little is left to emotion or feelings. This is a critical aspect of getting RFC’s through without having long winded discussions. If there are alternative opinions, they’re typically asked to back these up with some data.
However, there are occasions where disagreements cannot be resolved and some facilitation is required. For when we can’t come to agreement or compromise on the proposal in the RFC a panel is convened to arbitrate the way forward. The panel:
Sits ad-hoc, only when needed
Is comprised of varied members of Engineering
Is guided to strip out the detail from the RFC leaving only the decision needed to unblock progress
“Agrees and moves on”
But that said, the best way to get a proposal through is by agreement and compromise, not through this panel.
RFC disagreement process
Conclusion
Since setting up this process we’ve had loads of RFC’s raised, and all but a very small handful go through without the need for the panel to be set up; when you work in a scale-up, lots of things need to be done, and in general, most people are keen and excited to do them, you just need time and people to do them.
Blockers typically aren’t “what to do, or how to do it”, they’re more about finding the people to drive them forwards. Giving people that facility is the largest part of the problem.
We treat the process for RFC’s like any other and perform regular retrospectives to seek improvement with every iteration.
I personally have had a few occasions already where I’ve been able to refer people to an RFC when they ask, “Why are you using this tool?", or, “Why did you choose to do it that way?".
