## Metadata: - Source: Juan Pablo Buritica - Reference: https://opensource.com/article/17/9/6-lessons-rfcs , [[3. Resources/Readwise/Articles/6 Lessons on Using Technical RFCs as a Management Tool|6 Lessons on Using Technical RFCs as a Management Tool]] - Tags: #opensource, #rfc ## Summary: This article by Juan Pablo Buritica explores the use of technical RFCs (request for comments) as a management tool. It highlights the advantages of using RFCs for management, such as improved communication and collaboration, more efficient decision-making, and better visibility into the technical direction of a project. The article provides six key lessons for using RFCs as a management tool and offers examples of how they can be implemented in real-world scenarios. ## Main Content: The article begins by discussing the benefits of using technical RFCs for management. It explains that RFCs allow individual contributors to make decisions and domain experts to provide input without getting caught up in design by committee. RFCs also provide a snapshot of context for future reference and enable work on multiple projects in parallel, asynchronously. The author emphasizes the importance of having guidelines in place to determine when to write an RFC. Some situations that warrant writing an RFC include building something from scratch, considering a rewrite, anticipating an impact on multiple systems or team members, defining a contract or interface, adding a new dependency, or introducing new languages or tools in the stack. One of the key lessons highlighted in the article is the need for participation in the RFC process. The author states that if someone wants to be included, they must actively participate. This ensures that team members are involved in decision-making and have a sense of ownership. It also helps managers identify trust issues early on and provides visibility into who is making decisions. The article also emphasizes the importance of creating a common language within the team. This involves using clear and concise language in RFCs to ensure effective communication and understanding among team members. It also helps in aligning everyone's understanding of the problem and proposed solutions. Another lesson discussed is the creation of a culture of shared ownership. RFCs should not be seen as a top-down decision-making process but rather as a collaborative effort where everyone's input is valued. This fosters a sense of belonging and empowers team members to have an impact on the project. The article suggests using RFCs as a tool to drive decisions. By documenting decisions and their rationale in RFCs, teams can refer back to them in the future and ensure consistency in decision-making. RFCs also provide a platform for discussions and feedback, allowing for iterative improvements. In conclusion, the article highlights the effectiveness of using technical RFCs as a management tool. It provides practical lessons for implementing RFCs, such as developing a common language, creating a culture of shared ownership, and using RFCs to drive decisions. By following these lessons, organizations can improve collaboration, decision-making, and overall project management. ## Links - [[DevRel MOC]] — applies-in — RFCs as a transparent technical-decision practice - [[Building Realistic Roadmaps for Tech Debt Cleanup]] — extends — both are management tools for technical direction - [[Cathedral vs Bazaar - A Metaphorical Approach to People Management]] — contrasts — open vs centralized models of technical decision-making - [[3. Resources/Literature Notes/Elements of a Good Technical Document]] — applies-in: an RFC only works as a shared decision record when its title, language, and coverage make the proposal understandable. - [[3. Resources/Literature Notes/Criteria for Valuable RFI Inputs]] — extends: both formats need modular, expert, actionable input that a decision-maker can review. - [[3. Resources/Permanent Notes/Data-Model-First Releases Reduce Decision Coupling]] — applies-in: an RFC can record the boundary of a smallest useful release while leaving later interface decisions open.