From Chaos to Clarity: Leveraging RFCs in High-Performance Environments

Hi, everyone. Matheus Palano here. I'm from Brazil. I'm also a senior software engineer and tech lead at Quintana Roo, and I'm here to present this talk, From Chaos to Clarity, Leveraging RFCs in High-Performance Environments.

So first of all, I'd like to give you some context about Quintana Roo and why RFCs are so important there. So Quintana Roo is the largest housing platform in Latin America. It's already present in over 50 Brazilian cities and has started making its first moves into the international market. Currently, it has more than 5,000 employees, including 1,000 people in product and technology. So therefore, our architecture decision-making process needs to be very, very efficient, and that's why we have created an initiative called AmazingRFCs.

What we are hoping to achieve by the end of the initiative? We'd love to see visibly improved the quality of our deliveries, reduced time spent on design, RFCs as a way of sharing knowledge, cross-describe, and drive collaboration. So to do that, we needed to increase the density of people technically capable of conducting great architecture decisions, and a way to do that is by RFCs, but writing RFCs involve many, many areas, and that's why we have decided to split it into three main areas. The first area that we were going to work was empowering focal points in each tribe. It means having local technical leadership who are subject matter experts and can provide assistance. Those leaders would also be directly claiming individuals from these tribes. The second area would be managers capable of training and guiding. They will also be responsible for monitoring technical decisions, establishing accountability for good technical decisions within the area itself, and last but not least, tools, guides, and process, creating guidance to assist with different aspects of the architecture, creating tools for tracking, and improving quality.

So we took many actions to achieve those goals, but I'd like to show you three actions that really made the difference for us. The first one was create a group called RFCs Advisors, people who are responsible assisting others with RFCs and create a community for them to exchange ideas, as well as bring specific advisors who are experts in system areas. So how did that work? We have the advisors on the top, and the process of writing an RFC would be split into three steps. Step one, initial writing, presentation to the team, and then external review. The advisor would also be present along with the person who's writing in those three steps. The second one was open for comments, at least one week in advance so people can prepare and have a week to read the RFC. Then the person who was writing along with the advisor would present it to the line and then make the adjustments if it was necessary. And last but not least, it would require approval by at least two reviewers, and then it was good to ship. The second action that we took that made a lot of difference was regarding design and review process. We have noticed that our synchronous time are very valuable and tend to produce great results as they're fast-paced through our discussions. But to achieve an optimum use of time for every person, we changed the schedule and forum. So changing the invitees to be selected by their domain knowledge and interest. Suppose that we are discussing a new architecture for layout components that will be used heavily across the login page. While we may have several super good candidates for discussion, like front-end engineer that contributed for the login in the past, or full-stack engineer that modified the login page and integrated with the APIs, or the engineer manager that will soon be pushing his team to propose a new architecture for SSL login.

We can also have some people that will not have too much to contribute and could potentially use their time better, like a back-end engineer that is currently solving a field-challenging or another team that doesn't have anything with login, or a full-stack engineer that is currently focusing on integrating several high-complexity services for the past few months and isn't aware of the login process. So that's why we have decided that only people are interested or key people in the subject of the RCs will be present. Other people are invited too, but it's not mandatory for them.

The second thing related to the design review process was scheduling ad hoc design reviews instead of a fixed weekly. So we changed our design review meetings from weekly to an ad hoc schedule, which means the person that are writing the RCs will schedule the design review meeting. Together with the advisor, they are responsible for choosing and aligning with the people that will be invited for the discussion. Together with the advisor, they will pre-select the core approvals that will have a required review for their RC to be included. And the design review will be scheduled at a time that best suits the writer, the advisor, and the participants. That way, we can make sure that only the interested people are there and they will have the time and they will be there to review the RCs synchronously.

And other action that we took that I'd like to present here was daily training initiatives. We have developed trainings that focus on enhancing the technical skills and knowledge necessary for architectural decision making. It covered a wide range of topics from fundamental architectural principles to advanced techniques. For instance, introduction to problem analysis, where we have learned to properly identify an initiative, gather requirements, clarify objectives, and define scope, identify potential user roles and stakeholders, identify potential solutions, outline strategies, and allocate results, and also test and measure outcomes. Another training that we had was on solution architectural overview, where we learned the concepts behind the architecture, an overview on microservices, micro-frontends, MVC, and other partners. Syncing versus asynchronous communication, Quill, Topic, PubSub, UTLs, and API gateways. Those trainings gave us a lot of, like a toolbox on writing RCs and find solutions that could be potentially good. And that helped us to expedite the review as well, because the quality of our RCs increased significantly.

So what were the outcomes of those actions? First, we have increased the density of people technically capable of conducting great architectural decisions. That was our main goal. And today, we have people that are very, very capable of writing good RCs. Secondly, we have increased the number of RCs written. People felt more comfortable in writing RCs, and therefore, they wrote even more RCs. And last but not least, we have increased the quality of the RCs deployed. Not only the reviews, but also the first draft of the RCs are in really, really good quality. And this helped us to have a better solution in production. So this was what I decided to bring to you and show this case. I hope you enjoyed, and thank you very much. And as we say in Portuguese, Obrigado!