6 Lessons I learned while implementing technical RFCs as a decision making tool

You should write an RFC if you:

• are building something from scratch. New endpoint, component, system, library, application, etc.
• the need rewrite has crossed your mind
• 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 to the stack
• are in doubt of whether you should write one

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 great UX.
• 🕰 They may need better personal time management.

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.

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.