Embarking on the journey of implementing technical RFCs as a decision-making tool can be a challenging yet enlightening experience. Discover the six invaluable lessons learned along this path, offering insights that can guide and enrich your own journey in this technical realm.
“Cada cabeza es un mundo”
Street Art by Juegasiempre / DjLu in Bogotá, Colombia
- As an engineering leader, you value trust and believe that individual contributors should be involved in architectural and high level technical decision making.
- Every line of code is a decision made on behalf of someone else
- Having a fast-growing distributed team makes technical decision-making particularly difficult to manage
Engineering leadership can participate at right level of abstraction
Use RFCs to understand decisions being made at the architecture level and approve or delegate approval of these decisions without the need to micromanage
- At Splice, I’m only responsible for the engineering organization and partner with Matt, 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
Process is what I ship
The RFC process 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.
- 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.
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
Deciding when to RFC is difficult
Here are some guidelines to decide when to write a proposal
- You should write an RFC if you: are building something from scratch
- Will need a rewrite
- Would like to define a contract or interface between clients or systems. Are adding a new dependency
- Are adding or replacing languages or tools to the stack
The newbie tag enables psychological safety
Any comment or proposal tagged with [newbie] indicated that its author was coming from a vulnerable place.
- This tag allowed for mistakes while knowing they were in an environment of psychological safety, that was supportive of learning for both senior and junior members.
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
- Just like building software, I like iterating on processes and I’d love to hear from you how you’ve improved technical decision making with your teams
Inclusion requires responsibility
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
- A low participation rate (participants/total team size) may be an indicator for a few problems
- Low participation rate may be due to:
- Too much going on
- They are not interested
- Tools used for process management are not providing them great UX
- Lack of personal time management
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.
