6 Lessons on Using Technical RFCs as a Management Tool  [[3. Resources/Readwise/Full Document Contents/Articles/6 Lessons on Using Technical RFCs as a Management Tool|Full Document Contents]] ## Document Notes Abstract: This article examines the effectiveness of using technical RFCs (request for comments) as a management tool. It begins by outlining the advantages of using technical RFCs for management, such as improved communication and collaboration, more efficient decision-making, and better visibility into the technical direction of a project. It then offers six key lessons for using technical RFCs as a management tool, including developing a common language, creating a culture of shared ownership, and using RFCs to drive decisions. The article provides examples of how technical RFCs can be used in the real world and provides advice on how to successfully implement and maintain an RFC process. By following these lessons, organizations can maximize the effectiveness of technical RFCs to improve collaboration and decision-making. 1. What are the guidelines for writing an RFC? 2. How has the RFC process improved decision making? 3. What challenges can arise from low participation rate on RFCs? RFCs (Request for Comments) have become a valuable management tool for distributed engineering teams, allowing individual contributors to make decisions and domain experts to provide input without becoming too bogged down in design by committee. They provide a snapshot of context for future reference and work on multiple projects in parallel, asynchronously. It's often hard to decide when to write an RFC, and teams should have guidelines in place to help them determine when it's necessary. Using RFCs also enables team members to participate in decisions and be included in the process, as well as giving managers visibility into who is making decisions, helping them to detect trust issues early. Senior leaders are also able to provide the right level of technical direction and manage risk. RFCs are an excellent way to create a sense of belonging in teams, where members can be involved in meaningful decision-making and experience the consequences of those decisions. > [!note]+ Document Notes > Abstract: > > This article examines the effectiveness of using technical RFCs (request for comments) as a management tool. It begins by outlining the advantages of using technical RFCs for management, such as improved communication and collaboration, more efficient decision-making, and better visibility into the technical direction of a project. It then offers six key lessons for using technical RFCs as a management tool, including developing a common language, creating a culture of shared ownership, and using RFCs to drive decisions. The article provides examples of how technical RFCs can be used in the real world and provides advice on how to successfully implement and maintain an RFC process. By following these lessons, organizations can maximize the effectiveness of technical RFCs to improve collaboration and decision-making. > > 1. What are the guidelines for writing an RFC? > 2. How has the RFC process improved decision making? > 3. What challenges can arise from low participation rate on RFCs? > > RFCs (Request for Comments) have become a valuable management tool for distributed engineering teams, allowing individual contributors to make decisions and domain experts to provide input without becoming too bogged down in design by committee. They provide a snapshot of context for future reference and work on multiple projects in parallel, asynchronously. It's often hard to decide when to write an RFC, and teams should have guidelines in place to help them determine when it's necessary. Using RFCs also enables team members to participate in decisions and be included in the process, as well as giving managers visibility into who is making decisions, helping them to detect trust issues early. Senior leaders are also able to provide the right level of technical direction and manage risk. RFCs are an excellent way to create a sense of belonging in teams, where members can be involved in meaningful decision-making and experience the consequences of those decisions. ## Highlights - You should write an RFC if you: • are building something (a new endpoint, component, system, library, application, etc.) from scratch; • had "rewrite" cross your mind; • suspect something will impact more than one system or other team members; • would like to define a contract or interface between clients or systems; • are adding a new dependency; • are adding or replacing languages or tools in the stack; or • wonder whether you should write one. ([View Highlight](https://read.readwise.io/read/01gw0b7k0shc4968sgba4nrsme)) - > *If you want to be included, you must participate.* ([View Highlight](https://read.readwise.io/read/01gw0b7vhvv0hb7xk9qbbr0cqb)) - Note: This document outlines the benefits of using Request for Comments (RFCs) as a management tool for distributed engineering teams. It outlines the advantages of RFCs, such as enabling individual contributors to make decisions, allowing domain experts to provide input, managing risk, and providing a snapshot of context for the future. It explains that RFCs are an excellent way to generate a sense of belonging in a team, as well as an opportunity for team members to be involved in decision making and have an impact at work. Additionally, the document provides tips on when to write an RFC and how to measure participation rate. Finally, it explains how RFCs can help to identify trust issues and provide opportunities for less dominant members to lead.