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

Hi, everyone. Mateus Palino here. I'm from Brazil. I'm also a senior software engineer and tech leader 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 Amazing RFCs. What we hope to achieve end of the initiative. We'd love to see visibly improved quality of our deliveries, reduced time spent on design, RFCs as a way of sharing knowledge, cross-describe and try 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 involved many, many areas. And that's why we have decided to split it in 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 directly claim 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 guides to assist with different aspects of 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 for 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 a 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 a language 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 designing review process. We have noticed that our synchronous time are very valuable and tend to produce great results as a first phase through our discussions. But to achieve an optimum use of time for every person, we change the schedule and forum. So changing the invitees to be selected by their domain knowledge and interests. 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 engineering manager that will soon be pushing his team to propose a new architecture for SSO login. We can also have some people that will not have too much to contribute and could potentially use their time better. Like a backend engineer that is currently solving a field challenging or another team 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 interested or key people in the subject of the RCs will be present. Other people are invited to, but it's not mandatory for them. The second thing related to the design review process was scheduling and accurate design reviews instead of a fixed weekly. So we changed our design review meetings from weekly to non-ad hoc schedule, which means the person that are writing the RC 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 closed, and their 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 RC synchronously.

And another action that we took that I'd like to present here was tailored training initiatives. We have developed trainings that focused 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 initial, 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 Architecture Overview, where we learned the concepts behind architecture, and overview on microservice, micro-contents, MVC and other partners, syncing versus asynchronous communication, query or topic, pub-sub, UTLs and API gateways. Those trainings gave us a lot of like a toolbox on writing RCs and finding solutions that could be potentially good. And that helped us to expedite the review as well, because the quality of our RCs increases 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 reading. 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 solutions deployed. Not only the reviews, but also the first drafts 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 it. And thank you very much. And as we say in Portuguese, Obrigado.