How we revamped our RFC process at Productboard

Jakub Beneš
Jan 21 · 4 min read
Image for post
Image for post
Photo by Alfons Morales on Unsplash

A year and a half ago, I took the opportunity to build the Frontend Platform team that I’m still leading today. While I did this for many reasons, one of them was particularly striking: To empower product teams to make high-impact changes, enable and support innovation, and share our learning across the frontend community.

I could talk for hours about exactly how we’ve executed on this and what the situation looked like when we decided to establish the team. But for the purposes of this article, I want to focus on one practical way we’ve improved our ability to make impactful changes as we scale.

Addressing those growing pains

A couple of months ago, we realized that our Fronted Architecture meeting (as we called it back in the day) no longer worked. It was great when we were essentially half the size we are right now, but it stopped scaling pretty quickly once we grew. And that’s without going into how switching to a completely asynchronous environment took its toll! Ah, 2020, the year of pushing comfort zones!

I teamed up with my mentor from Plato (Hi, Jennie!) to figure out how we could improve the way we share ideas, give feedback, and make changes as the team grows. We decided that it might be time to completely revamp our RFC process, which dates back to the origin of the Frontend Platform team. That’s right, we actually had an RFC process in place, but it never really took off. This time, we had to do a few things differently.

Designing an RFC process that works

Before, heavily inspired by the OSS community around the Facebook projects (namely React, React Native), we had a similar kind of template versioned in our monorepo. But I could count on the fingers of one hand how many times it was actually used. Luckily for us, as we grew, we had another problem to solve — we needed a record of impactful changes that we could refer back to in the future. Creating a culture around RFCs effectively allowed us to kill two birds with one stone.

One problem I saw with git-versioned RFCs was that the process was very heavy and formal. You had to open a PR, commit it, and so on. Also, it hasn’t scaled for our other projects — we have a monorepo with mostly frontend code, but we have other services in separate repositories.

As I thought about the problem, I wanted to avoid overcomplicating things by introducing new tools (a new process with a new tool? That’s a fast track to hell!). And truth be told, we have enough tools as it is. So, given that we are pretty fond of Notion here at Productboard — actually, we love it! — I thought, why not use Notion as our RFC database?

We revamped the old template and simplified it (heavily inspired by Design Docs at Google). We also emphasized that it’s an informal document — no need to rigidly follow the template, just put your thoughts down so everyone can participate and be on the same page. Simple.

Image for post
Image for post
Diagrams are always a huge plus in RFCs. Right?

Next, we aligned at a leadership level to support this initiative across our teams. In essence, the process was as simple as this:

Are you gonna deliver something cool? Awesome!
Do you need to align with more than your team? Sweet, now document it!
If not, is it a huge change that will potentially affect someone outside your domain? Great, go ahead and document it!

Now the last step: How to spread the word? Confluence has its notifications. Notion has a notification system as well, but it might be hard to follow — it can get noisy, and no one really looks at emails. You know what we like besides Notion? Slack!

So we decided to create a simple notification channel in Slack called “n-rfc”. Each time someone adds an “open” document for comment, a new notification appears there. It’s nothing fancy, but it works. And the best part? It’s open-sourced, so you can use it as well.

Image for post
Image for post
The message is hard coded for now, but can be easily refactored. Feel free to send a PR!

The system works!

If you are wondering how it performs, I can honestly say that it has exceeded my expectations. We established our new RFC process at the beginning of Q3 2020, and so far, we have created more than 100 documents this way. That’s pretty impressive given that we’re an organization of under 90 engineers.

That’s it for today, folks. Now over to you — how do you approach changes in your organization?

I hope you enjoyed this article. If you like it or have any questions, please feel free to comment below👇. As you can see, we are solving interesting problems on a daily basis. If you’d like to know more, feel free to ping us. If you’d like to join us on our journey, check out our latest engineering vacancies here!

Productboard engineering

Productboard engineering

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store