Earlier this year, our product and engineering organization (known internally as DISQOTECH) adopted an RFC (Request for Comments) process loosely adapted from models in the industry (and Open Source projects) that allow for a democratized way of sharing ideas.

At DISQO, an RFC is a document that proposes a change to any product or process impacting more than one team. It can also propose a brand new microservice, tool, or process. Any team member may write an RFC, or leave comments on one, discuss their thoughts, and declare their support or opposition to the content. Where other companies have used email lists or other forms of distribution, we’ve opted to use a JIRA board, on which we can see the stage that an RFC is in, from draft to adoption. We keep it simple and let people know on Slack that there’s a new RFC to check out.

Our CTO, Drew Kutcharian, started proposing RFCs within the organization as early as 2018. But the actual rollout of RFCs didn’t come in until much later. In early 2020, Drew and the rest of the DISQOTECH management team partnered with our Technical Program Management team and started tinkering on the best ways to adopt the RFC process. After many conversations and feedback sessions, the first version of our RFC process was adopted in April 2020.

Why We Have RFCs

As our engineering department has grown, so has our need to reflect our culture in our processes. RFCs were a natural fit. As Senior Product Manager Anne Rynearson puts it, “we needed a way to allow individuals across [our engineering organization] DISQOTECH to give feedback on changes and initiatives without gathering everyone in a room. We introduced the RFC process as a consistent way to give a voice to all members of DISQOTECH around potential changes and improvements. RFCs allow for asynchronous discussion so that team members can contribute to making DISQOTECH better.”

“At DISQO, we deeply value our team members’ ideas and we want to empower them to make an impact. Our RFC process allows everyone at DISQOTECH to be an agent of change for our organization in a very collaborative way.” - CTO Drew Kutcharian

We introduced RFCs around the time that we shifted entirely to remote work. So having this process highlighted the importance of our written communication. Rather than having ideas floating around, we now have a method of sharing a concise, written account of the changes we are proposing. There’s a paper trail if we need to come back to it, and we all have equal access to the organization’s RFCs since they outlive the lifespan of a Zoom call.

Senior Technical Program Manager Kunal Karandikar identifies that “without a Request for Comment, it can be difficult to float the idea, discuss it, build consensus and greenlight it for adoption. RFCs solve this problem in a rapidly-growing and functionally diverse place like DISQO, where we encourage cross-team collaboration to solve some difficult problems.”

“We needed a way to allow individuals across [our engineering organization] DISQOTECH to give feedback on changes and initiatives without gathering everyone in a room.” - Senior Product Manager Anne Rynearson

As Director of IT, Platform, and Security, Marc Bittner puts it, “we wanted to empower people, even in situations where we have to mediate between the interests of competing groups. Democratizing the decision-making process within a set of checks and balances gives our engineering org the right balance between freedom and responsibility.”

Anyone in the Engineering organization can write and propose an RFC. With less than a year of RFCs under our belt, we’ve already had RFCs from our Engineering Managers, Directors, Data Scientists, Technical Writers, Engineers, and Product Managers. This diversity of positions participating is made possible by our culture of over-communication, especially during COVID-19 times.

Brian David, a Senior Software Engineer on our Purple Electric Penguins team, says what prompted him to write an RFC was that “while working with other teams within our organization and seeing our future plans, I was curious if certain technologies could speed up our processes and benefit the organization in the long run. Launching new features quickly for our users is what’s so fun about being a part of the startup culture.”

Complexities of the RFC Process

We have already found some issues with our current process. It’s all part of what startups like ours do - we try something out, and then we continually iterate and improve. With our RFC process as it is, we’ve identified that we sometimes miss the more tangible and measurable outcomes of each RFC, and we’ve focused on the principles and concepts instead.

In true DISQO fashion, Director of IT, Security, and Platform Engineering Marc Bittner wrote an RFC for RFCs. In this RFC, Marc Bittner identifies that we have issues in the lifecycle of an RFC. We also need to assign concrete checks the RFC needs to hit before moving to another lifecycle stage.

“When we began using this process, much of it was implicit. Over time, this began to impact the success of the undertaking.” - Director of IT, Platform, and Security Marc Bittner

Marc Bittner says, “there are a lot of ways you can structure such as process-specific requirements or constraints that different RFC implementations might take into account. When we began using this process, much of it was implicit. Over time, this began to impact the success of the undertaking. Many engineers would write an RFC and later come to me because they could not figure out what the next step to move it forward should be.”

He continues, “But this is the beauty of an evolving process. It provides a mechanism to repair itself. I’ve written an RFC - which is in the final stages of being ratified - that specifies with overwhelming specificity how RFCs can progress, regress or otherwise fade away. Once published, those participating in the process shouldn’t ever have to wonder about the rules by which proposals move through the system.”

RFC Engagement

As far as engagement with the RFC process, Anne Rynearson says, “every RFC is not relevant to every individual, but when RFCs reflect something a DISQOTECH member cares about, there is a natural inclination to want to review and comment on that RFC.” Marc Bittner says, “the real payoff of this process has been in the way it very specifically focuses on the good ideas that come up continually in a healthy engineering org… Once we created the process, we witnessed a real outpouring of creativity as a byproduct.”

“Every RFC is not relevant to every individual, but when RFCs reflect something a DISQOTECH member cares about, there is a natural inclination to want to review and comment on that RFC.” - Senior Product Manager Anne Rynearson

Brian David says the “feedback process has been a huge positive. When I first started the RFC, I had this considerable scope in mind and honestly did not understand the level of effort involved. Working with other teams within the organization and even having teams prepare a proof of concept has been a great experience. Feedback loops are critical in refining ideas.”

From a numerical perspective, Platform Engineering Manager Hrayr Abazyan says that we’ve had an influx of one to two new RFCs per week. He says we’ve gotten past the initial resistance of having a new process, and we’ve seen some organizational improvements from the addition of RFCs.

“Once we created the process, we witnessed a real outpouring of creativity as a byproduct.” - Director of IT, Platform, and Security Marc Bittner

Kunal Karandikar has seen good engagement with the RFC process and says, “the overwhelming majority of our teammates in Engineering are aware of and have participated in RFC discussions, either directly or through their teams.” Director of Technical Program Management Dave Lam adds, “Our recent RFC survey said 64% said they contributed to an RFC at DISQOTECH. We want to work on increasing this number to 100%.”

RFC Successes

So far, we have seen a range of successes with the RFC process. According to Anne Rynearson, “new microservices became a lot easier to build. The RFC process gave us a clear way to introduce a potential new microservice and get feedback on technical design from key stakeholders and SMEs before launching.”

Kunal Karandikar identifies that “DISQO authored and implemented an RFC to define how we would measure Team Effectiveness in 100% remote-work scenario, in response to the pandemic. The output of this RFC became foundational to pulsing and measuring productivity metrics across DISQO’s entire Engineering organization, which was a huge win for us!”

So far, we’ve seen several successful RFCs, including the one that instigated changing our racial tech terminology. Read more about our efforts in How DISQO is Internally Addressing Racial Tech Terms. At Software Engineering Manager Tuukka Luolamo’s suggestion, the RFC expanded to include gendered, ageist, and ableist language often found in tech workspaces. For example, “man-hours” becomes “people or engineer hours”; “grandfathered” becomes “legacy”; and “dummy value” becomes “placeholder.”