Article summary
Our team’s process for discussing and making significant technical decisions was broken. As the tech lead, I wasn’t getting the feedback I wanted. Some team members were concerned about being excluded from the work, and the thought of running lengthy video meetings to discuss the pending decisions wasn’t something anyone relished. We needed a change.
After some reflection, we turned to a practice used by numerous open-source projects and standards organizations: a Request For Comments (RFC) process. So far, we’ve found the change empowering, low-stress, and helpful in managing the decision making process for our technical team.
The Problem
We have a relatively large project team with twelve developers, which makes my default problem-solving approach — getting everyone together for discussion — less than ideal. It’s disruptive and costly to call that many people away from their development work. And we all have enough video calls on our calendar and aren’t excited about adding another.
Besides, an all-hands meeting isn’t a good way to get quality feedback on complex technical topics:
- Responding in the moment to a complex technical need isn’t everyone’s strength. Some people (myself included) need time to digest and consider implications before they can provide their best feedback.
- It’s easy for the conversation to get derailed or monopolized by a vocal minority.
- When the written background is provided before the meeting, there’s no guarantee that participants read it or that it provided sufficient information to set up the meeting for success.
- We rarely reach a conclusion during the hour; often, we’re left with open questions, or we need more time to consider implications.
- We usually end up with an incomplete record of the context around a decision, even if the decision itself is recorded reasonably well.
What We Did
We could have improved our meeting preparation to include an RFC-like writeup and kept an all-hands meeting, or we could have made attendance opt-in so only interested individuals needed to come.
But the RFC process sounded interesting and cheap to run as an experiment, so we gave it a try.
1. We created a space for the discussions.
We created a GitHub project with three columns (Draft, Open, Closed) to track our RFCs. GitHub issues categorized on a project board provide a good forum for conversation, as demonstrated by many open-source projects.
2. We posted our first two RFCs.
Each RFC was carefully written to provide fertile soil for a productive conversation. We included:
- Background – What is the broad context for the issue? What is the current problem or upcoming challenge?
- Goals – What do we want out of a solution? (This section tends to focus on values and principles that are implementation agnostic.)
- Options – What are the implementation paths that the author has considered?
- Recommendation – If there’s an approach the author favors as a fit for our goals, which option is it, and why does it fit best?
3. We set clear rules.
Each RFC had four simple rules at the top to remind everyone how to participate:
- Each the RFC will be open for a set period. (For our first two RFCs, that was one week.)
- Keep conversation civil and respectful.
- If you have a conversation outside the comments section of this issue, summarize that conversation in the comments.
- Participate!
4. We reviewed RFCs regularly.
We did a brief review of open and recently-closed RFCs during each two-week sprint. We used a small portion of our regularly-scheduled dev. team retrospective and technical show-and-tell time to help with awareness of what was open and closed, but not to discuss the RFCs depth. More detailed conversations could be scheduled, as needed, with specific people.
The Results
As expected, the asynchronous nature of a written RFC process was a good fit for our fully remote team’s schedule. It allowed us to focus solid blocks of core working hours on pairing and feature development while still providing a space for important discussions with more distant impact. The asynchronous aspect of the process has been even more helpful as individual team members’ schedules have been impacted in diverse ways by COVID-19 and other life circumstances.
Having the conversations written and visible for the whole team has made it easy for others to catch up and will likely be helpful in the future as a reference. It also reduces the urgency of participation and gives team members time to think and an easy avenue for participation when they have something to contribute.
Since the goal is for the conversation to start in written form, we’ve spent more time preparing the initial RFC posts. They’ve been clear and helpful (as the author of our first two, I may be biased) and have forced us to think everything through before bringing it to the group. I’ve noticed that my RFCs have been intentionally focused on what I want out of the team on a given topic (i.e., What are the key points I’m looking for input on? What are the questions the team needs to answer?)
I’ve also felt that the team reads the RFCs more closely than they would read the notes in a meeting invitation, which helps us have more productive conversations.
The relatively short timeframe for our RFCs doesn’t block the decisions for long. I could see using RFCs that are open for a few days to a week or two, depending on the urgency. The important part is making the RFC visible and setting clear expectations about how long it will be open.
The RFC process also levels the playing field for participation. It’s more difficult for a vocal minority to dominate a written conversation, so everyone should have a chance to have their perspective heard. I’m also eager to encourage other team members to initiate RFCs and thereby lead/steward significant technical change on the project.
Overall, we’ve been pleased with the process so far. It helped significantly with the pain points we were experiencing, and I’m hopeful that we’ll find more value in the process as more team members initiate their own RFCs.