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 <a href="https://rework.withgoogle.com/blog/how-to-foster-psychological-safety/">psychological safety </a>, that was supportive of learning for both senior and junior members.

The newbie tag enables psychological safety

In the process of building our apps I received a private Slack message:Why was the data dashboard built using React if our front-end stack is based on Ember? — a not very happy front-end engineer <ul><li>💀 I didn’t know we had added a new tool to our stack. 😳</li><li>💀 Other team members who should’ve known about it, didn’t know either.</li><li>💀 Someone made an important decision on behalf of our entire team, but the team wasn’t included in it.</li><li>💀 No one, including myself, appreciated the surprise.</li></ul>

Making decisions in a bubble = 🤬

You should write an RFC if you:<ul><li>are building something from scratch. New endpoint, component, system, library, application, etc.</li><li>the need rewrite has crossed your mind</li><li>will impact more than one system or other team members.</li><li>would like to define a contract or interface between clients or systems.</li><li>are adding a new dependency.</li><li>are adding or replacing languages or tools to the stack</li><li>are in doubt of whether you should write one</li></ul>

Deciding when to RFC is difficult

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.

Trust issues become more evident

If you see a low participation rate, you team members may be dealing with the following challenges:<ul><li>😵 They have too much going on.</li><li>😱 They are not interested.</li><li>🔨 Tools used for process management are not providing them great UX.</li><li>🕰 They may need better personal time management.</li></ul>

Participation in RFCs

We needed a way to make decisions as a team that would allow us to:<ul><li>enable individual contributors to make decisions for systems they’re responsible for</li><li>allow domain experts to have input in decisions when they’re not directly involved in building a particular system</li><li>manage the risk of decisions made</li><li>include team members without it becoming design by committee</li><li>have a snapshot of context for the future</li><li>be asynchronous</li><li>work on multiple projects in parallel</li></ul>

Goals of an internal RFC

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…

Participation in RFCs

Similar ideas to Participation in RFCs

The Best Question To Ask

Don’t Over-Promise And Under-Deliver

Types of people