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.
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.
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?