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.
In the early days of building ride-sharing app Ride, we went from three to more than 25 members, across product, design, and engineering, in the first six months. We were tasked with the challenge of taking an early prototype for a carpooling platform and bringing it to life on the web, iOS, and Android. To make things more fun, we were also distributed across the United States, Mexico, Colombia, Brazil, Argentina, and Ireland.
In the process of building our apps, I received a private Slack message from "a not very happy front-end engineer," who asked:
Why was the data dashboard built using React if our front-end stack is based on Ember?
This made me quickly realize a few important things I shouldn't have missed:
- I didn't know we had added a new tool to our stack.
- Other team members—who should've known about it—didn't know either.
- Someone made an important decision on behalf of our entire team, but the team wasn't included in it.
- No one, including myself, appreciated the surprise.
This situation was the result of a process failure. Given that process is what I ship (as the VP of engineering), I was also responsible for improving the process so the team didn't find itself in these positions again. We needed a way to make decisions as a team that would:
- enable individual contributors to make decisions for systems they're responsible for;
- allow domain experts to have input in decisions when they're not directly involved in building a particular system;
- manage the risk of decisions made;
- include team members without it becoming "design by committee";
- have a snapshot of context for the future;
- be asynchronous; and
- work on multiple projects in parallel.
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 Request for Comments (RFC) process would help us make better decisions together.
The RFC process, which is widely used in open source projects to gather feedback from contributors and other stakeholders, has become one of my favorite tools in managing distributed engineering teams. I implemented it shortly after joining Splice and adopted it Elizabeth & Clarke 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 three years using RFCs in production, I thought I'd share some practical lessons in case you want to try it out.
1. Deciding when to write an RFC is hard.
Given the complexity of decisions, exposure to context, the variance of engineers' expertise, and frequent lack of subject matter understanding, determining when to write an RFC is the most challenging question of the whole process.
In general, if you're asking,
"Should I write an RFC for this?"
the answer probably is,
"If you need to ask, you probably should."
To facilitate the process, we've created guidelines to decide when to write an RFC proposal.
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.
2. Inclusion requires responsibility.
I've found no better way 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.
If you want to be included, you must participate.
Our RFC implementation 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 to be included.
RFCs have reduced the number of times managers hear the dreaded question, "Why wasn't I consulted about X?" In addition, when they can refer to a document, individual contributors (ICs) can be given concrete feedback on performance if important decisions, which are part of their responsibilities, were not on their radar.
Something worth measuring is the rate of participation on RFCs. A low participation rate (participants/total team size) may be indicate a few problems lurking in the background. If you see a low participation rate, you team members may be dealing with the following challenges:
- They have too much going on.
- They are not interested.
- Tools used for process management are not providing them a great user experience.
- They may need better personal time management.
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.
3. Trust issues become more evident.
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 in a system is making decisions, and this has helped managers identify situations where trust issues are preventing ICs from making decisions. Detecting trust issues early is important in maintaining effective collaboration in teams.
4. Power dynamics can be managed.
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.
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.
5. The newbie tag enables psychological safety.
Senior devs don't grow on trees, you must give juniors a chance.
— ☠️Buriticá ☠️ (@buritica) July 25, 2014
To be inclusive, engineering process design should consider the input of people with different levels of experience, both at career level and technical depth. For example, I may have been writing JavaScript for several years, but not have much context in the Go way of things.
As a team, we agreed that any comment or proposal tagged with [newbie] 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 psychological safety that was supportive of learning for both senior and junior members.
6. Engineering leadership can participate at the right level of abstraction.
At Ride, I was expected to run the engineering organization and provide technical direction, a hybrid VP of engineering/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 be solved. If the risk to the business was high, like in the case of large rewrites/refactors or the addition of a tool to the stack, I could reject or approve a proposal if I could see learning opportunities at a manageable risk. This is how it works today at Elizabeth & Clarke, where I'm chief technical husband on the weekends.
At Splice, I'm responsible only for the engineering organization and partner with Matt Aimonetti, 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 given Matt visibility into how members of our team think through technical direction, as well as allowed 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 to have the entire system in his head.
RFCs are my jam
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.
This article was originally published on Juan Pablo Buriticá's blog, Juan's And Zeroes, and is reprinted with permission.
Comments are closed.