davidbgk
/
larlet-fr-david-cache

title: 6 Lessons I learned while implementing technical RFCs as a management tool
url: https://buriti.ca/6-lessons-i-learned-while-implementing-technical-rfcs-as-a-management-tool-34687dbf46cb
hash_url: 23b9ed11a9f44f12c58d899dc056b48d

<p name="1cd7" id="1cd7" class="graf graf--p graf-after--h3">As an engineering leader, I value trust and believe that individual contributors should be involved in architectural and high level technical decision making. I consider every line of code to be a decision made on behalf of someone else (including your future self) and having a fast-growing distributed team makes technical decision making particularly difficult to manage.</p><p name="815f" id="815f" class="graf graf--p graf-after--p">In the early days of building <a href="http://www.businessinsider.com/uber-cofounder-oscar-salazar-launches-ride-2015-4" data-href="http://www.businessinsider.com/uber-cofounder-oscar-salazar-launches-ride-2015-4" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">Ride</a>, we went from 3 to 25+ members across product, design, and engineering in the first six months. We were tasked with the challenge of taking an early <a href="https://techcrunch.com/2014/12/11/ride-b2b-carpooling/" data-href="https://techcrunch.com/2014/12/11/ride-b2b-carpooling/" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">prototype for a carpooling platform</a> and bringing it to life on the web, iOS, and Android. To make things more fun, we were also distributed across the US, Mexico, Colombia, Brazil, Argentina, and Ireland.</p><p name="d01b" id="d01b" class="graf graf--p graf-after--p">In the process of building our apps I received a private Slack message:</p><blockquote name="d8fe" id="d8fe" class="graf graf--pullquote graf-after--p"><em class="markup--em markup--pullquote-em">Why was the data dashboard built using React if our front-end stack is based on Ember? — a not very happy front-end engineer</em></blockquote><p name="0d27" id="0d27" class="graf graf--p graf-after--pullquote">This made me quickly realize a few important things I shouldn’t have missed:</p><ul class="postList"><li name="371e" id="371e" class="graf graf--li graf-after--p">💀 I didn’t know we had added a new tool to our stack. 😳</li><li name="1a2c" id="1a2c" class="graf graf--li graf-after--li">💀 Other team members who should’ve known about it, didn’t know either.</li><li name="98b1" id="98b1" class="graf graf--li graf-after--li">💀 Someone made an important decision on behalf of our entire team, but the team wasn’t included in it.</li><li name="f4a6" id="f4a6" class="graf graf--li graf-after--li graf--trailing">💀 No one, including myself, appreciated the surprise.</li></ul>

<h3 name="6a03" id="6a03" class="graf graf--h3 graf--leading">Process is what I ship 🚢</h3><p name="bc23" id="bc23" class="graf graf--p graf-after--h3">This situation was the result of a process failure, and given that process is what I ship as the VP of Engineering, I was also responsible for improving the process so the team doesn’t find itself in these positions. We needed a way to make decisions as a team that would allow us to:</p><ul class="postList"><li name="7857" id="7857" class="graf graf--li graf-after--p">enable individual contributors to make decisions for systems they’re responsible for</li><li name="8817" id="8817" class="graf graf--li graf-after--li">allow domain experts to have input in decisions when they’re not directly involved in building a particular system</li><li name="7015" id="7015" class="graf graf--li graf-after--li">manage the risk of decisions made</li><li name="bbba" id="bbba" class="graf graf--li graf-after--li">include team members without it becoming design by committee</li><li name="721f" id="721f" class="graf graf--li graf-after--li">have a snapshot of context for the future</li><li name="e8a8" id="e8a8" class="graf graf--li graf-after--li">be asynchronous</li><li name="9867" id="9867" class="graf graf--li graf-after--li">work on multiple projects in parallel</li></ul><p name="8137" id="8137" class="graf graf--p graf-after--li">We weren’t the first people to encounter this problem, so we looked at how open source software projects dealt with these situations, and came to the conclusion that adopting the <a href="https://www.ietf.org/rfc.html" data-href="https://www.ietf.org/rfc.html" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">RFC</a> process would help us make better decisions together.</p><p name="3766" id="3766" class="graf graf--p graf-after--p">The RFC process has become one of my favorite tools in managing distributed engineering teams. I implemented it shortly after joining <a href="https://splice.com" data-href="https://splice.com" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">Splice</a> and adopted it <a href="https://elizabethandclarke.com" data-href="https://elizabethandclarke.com" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">Elizabeth &amp; Clarke</a> too. I’m still learning about how it can help the organizations I lead to make decisions. Given my overall positive experience over the past 3 years using RFCs “in production”, I thought I’d share some practical lessons in case you want to try it out.</p>
<h3 name="ae2e" id="ae2e" class="graf graf--h3 graf-after--p">Learning from RFCs “in production”</h3><h4 name="5d6b" id="5d6b" class="graf graf--h4 graf-after--h3"><strong class="markup--strong markup--h4-strong">Deciding when to RFC is difficult</strong></h4><p name="315e" id="315e" class="graf graf--p graf-after--h4">Given the complexity of decisions, exposure to context, the variance of expertise of engineers and frequent lack of subject matter understanding determining when to write an RFC is the most challenging question of the whole process.</p><blockquote name="13e6" id="13e6" class="graf graf--pullquote graf-after--p">Should I write an RFC for this?</blockquote><p name="c623" id="c623" class="graf graf--p graf-after--pullquote">My general answer to this question is, “If you need to ask you probably should”. To facilitate the process we’ve arrived at some guidelines to decide when to write a proposal.</p><p name="369e" id="369e" class="graf graf--p graf-after--p">You should write an RFC if you:</p><ul class="postList"><li name="ea23" id="ea23" class="graf graf--li graf-after--p">are building something from scratch. New endpoint, component, system, library, application, etc.</li><li name="5d16" id="5d16" class="graf graf--li graf-after--li">the need rewrite has crossed your mind</li><li name="28ba" id="28ba" class="graf graf--li graf-after--li">will impact more than one system or other team members.</li><li name="b8a6" id="b8a6" class="graf graf--li graf-after--li">would like to define a contract or interface between clients or systems.</li><li name="6680" id="6680" class="graf graf--li graf-after--li">are adding a new dependency.</li><li name="c291" id="c291" class="graf graf--li graf-after--li">are adding or replacing languages or tools to the stack</li><li name="6963" id="6963" class="graf graf--li graf-after--li">are in doubt of whether you should write one</li></ul><h4 name="da82" id="da82" class="graf graf--h4 graf-after--li">Inclusion requires responsibility</h4><p name="8061" id="8061" class="graf graf--p graf-after--h4">I’ve found no better way yet to generate the sense of belonging in teams than by including people in decision making. Having an impact at work is important, and some of this impact happens through decision making. If we’re involved in important decisions, our work has the potential to be more impactful and this gives it a sense of purpose. By giving team members the opportunity to comment on decisions proposed by others, RFCs become excellent tools for inclusion and enable participation that can result in impact at work.</p><blockquote name="195e" id="195e" class="graf graf--pullquote graf-after--p"><em class="markup--em markup--pullquote-em">If you want to be included, you must participate</em></blockquote><p name="3fdb" id="3fdb" class="graf graf--p graf-after--pullquote">Our implementation of RFCs recommends that proposals remain open for comments for a minimum of two days and a maximum of a week, but shorter or longer are allowed depending on context. In addition, engineers are not required to participate, but if they don’t do it in time they lose the opportunity of being included.</p><p name="6dd3" id="6dd3" class="graf graf--p graf-after--p">RFCs have reduced the number of times managers find themselves with the dreaded “Why wasn’t I consulted about X” question. In addition, when there is a document they can refer to, individual contributors (ICs) can be given concrete feedback on performance if important decisions which are part of their responsibilities were not on their radar.</p><p name="beff" id="beff" class="graf graf--p graf-after--p">Something worth measuring is the rate of participation on RFCs. A low participation rate (participants/total team size) may be the indicator for a few problems lurking in the background. If you see a low participation rate, you team members may be dealing with the following challenges:</p><ul class="postList"><li name="8949" id="8949" class="graf graf--li graf-after--p">😵 They have too much going on.</li><li name="7a55" id="7a55" class="graf graf--li graf-after--li">😱 They are not interested.</li><li name="17a5" id="17a5" class="graf graf--li graf-after--li">🔨 Tools used for process management are not providing them great UX.</li><li name="4475" id="4475" class="graf graf--li graf-after--li">🕰 They may need better personal time management.</li></ul><p name="6256" id="6256" class="graf graf--p graf-after--li">I’ve found that some engineers increase their participation if you schedule review slots in a regular interval during the week and help members organize themselves around it.</p>
<h4 name="f333" id="f333" class="graf graf--h4 graf-after--p">Trust issues become more evident</h4><p name="1c00" id="1c00" class="graf graf--p graf-after--h4">Making technical decisions that materialize into software and experiencing the consequences of these decisions is an important way to learn how to build software. In some cases, team members may be preventing teammates from making decisions because of lack of trust. We’ve found RFCs increase visibility into who is making decisions in a system and has helped managers identify situations where trust issues are preventing ICs from making decisions. Detecting trust issues early in teams is important in maintaining effective collaboration.</p><h4 name="d223" id="d223" class="graf graf--h4 graf-after--p">Power dynamics can be managed</h4><p name="41f3" id="41f3" class="graf graf--p graf-after--h4">Using RFCs has allowed us to create spaces for team members who wouldn’t normally take the lead in technical decisions. Managers and senior ICs are encouraged to appoint less dominant members as authors of RFCs. Being an author makes it clear that you are the person who is responsible for the proposal. This is an explicit way of being empowered to take the lead without the need to be the loudest or most dominant member of a team.</p><p name="2737" id="2737" class="graf graf--p graf-after--p">Having a visible record of non-dominant member participation also allows me to evaluate how managers are handling power differentials, which has an impact on overall team happiness.</p><h4 name="5561" id="5561" class="graf graf--h4 graf-after--p">The newbie tag enables psychological safety</h4><p name="6ecf" id="6ecf" class="graf graf--p graf-after--figure">To be inclusive, engineering processes design should consider the experience of people with different levels of experience, at both career level and technical depth. For example, I may have been writing JavaScript for several years, but not have much context into the Go way of things.</p><p name="d0ac" id="d0ac" class="graf graf--p graf-after--p">As a team, we agreed that any comment or proposal tagged with <strong class="markup--strong markup--p-strong">[newbie] </strong>indicated that its author was coming from a vulnerable place. Whether motivated by lack of expertise, context or confidence, this tag allowed for us to make mistakes while knowing we were in an environment of <a href="https://rework.withgoogle.com/blog/how-to-foster-psychological-safety/" data-href="https://rework.withgoogle.com/blog/how-to-foster-psychological-safety/" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">psychological safety</a>, that was supportive of learning for both senior and junior members.</p><h4 name="9ac4" id="9ac4" class="graf graf--h4 graf-after--p">Engineering leadership can participate at right level of abstraction</h4><p name="4666" id="4666" class="graf graf--p graf-after--h4">When I was at Ride I was expected to run the engineering organization and provide technical direction, hybrid VPE/CTO role (full-stack exec? 😂). In this case, I used RFCs to understand decisions being made at the architecture level and I would approve or delegate approval of these decisions without the need to micromanage or dictate how problems were to solved. If the risk to the business was high, like in the case of large rewrites/refactor or the addition of a tool to the stack I could reject a proposal or approve if I could see learning opportunities at a manageable risk. This is how it works today Elizabeth &amp; Clarke, where I’m Chief Technical Husband on the weekends.</p><p name="3b7e" id="3b7e" class="graf graf--p graf-after--p">At Splice, I’m only responsible for the engineering organization and partner with <a href="https://twitter.com/mattetti" data-href="https://twitter.com/mattetti" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">Matt</a>, our CTO, who is responsible for our technical direction. As senior leaders, we’re accountable for decisions made at all levels of engineering and technology. RFCs have particularly enabled Matt to have visibility into how members of our team think through technical direction, allow him to manage risk and be involved in technical decisions at the right level, with the option to dig deeper or delegate when necessary. It’s also nice that he doesn’t constantly need have the entire system in his head.</p>

<h3 name="ec87" id="ec87" class="graf graf--h3 graf-after--p">RFCs are my jam</h3><p name="ee91" id="ee91" class="graf graf--p graf-after--h3">Giving team members, present, and future, the context into why and how decisions have been made has allowed me to run happier and more effective distributed engineering organizations. Now, instead of trying to inadequately respond when I’m asked “what were these people thinking?”, I point to files that may be able to resolve all doubts and allow members of my team to wear the software historian hat.</p><p name="465e" id="465e" class="graf graf--p graf-after--p graf--trailing">Just like building software, I like iterating on processes and <a href="https://twitter.com/intent/tweet?text=@buritica%20I%20think%20RFCs%20are%20...&amp;hashtags=MyFavEngProcess" data-href="https://twitter.com/intent/tweet?text=@buritica%20I%20think%20RFCs%20are%20...&amp;hashtags=MyFavEngProcess" class="markup--anchor markup--p-anchor" rel="noopener" target="_blank">I’d love to hear from you</a> how you’ve improved technical decision making with your teams.</p></div>