Guidelines for RFC’s

Communication is Key

Create a Request For Comment on any topic that impacts other teams or would benefit from feedback from other teams.

We are all working remotely and communicate mostly with members of our own team.

The RFC process is a collaboration mechanism that gives teams a common shared view of EBury Tech.

Iterate quickly

The RFC process supports fast, clear and transparent decision making.

Feedback and approval on a proposal can be completegit puld in a few days.

Proactively chase people for comments and, if required, approvals.

Rough and early is good

Late and ‘perfect’ is bad. This is a process of iterating the content in response to feedback. The first revision can be just a problem statement.

Iterating rapidly will deliver better solutions and is less painful than writing an inappropriate ‘magnum opus’.

Avoid sunk cost

The more work you have put into your document up front - the less likely people are to comment on it honestly.

There is a tendency to empathise with the author … “This is a terrible idea, but this person has put so much effort into it…“.

This leads to a focus on smaller, irrelevant details instead of addressing the elephant in the room.

Many eyes

Make it readable by a wide audience. Simple clear diagrams with supporting text are really useful. A picture is worth a thousand words.

Make the extra effort to write the document in a way people in other teams without your specialist knowledge can make sense of it.

Be extra careful with terminology. Be precise, descriptive and unambiguous. E.g. 'Entity' can be anything. 'EBury Legal Entity' is more descriptive.

Keep it as simple and clear as possible

RFC's are aimed at allowing people to share ideas, and receive feedback on them.

The easier they are to read - the better the feedback.

Share Ideas

Share Ideas, not implementation details.

Focus on the What and Why (not the How).

Request For Collaboration - it’s all about communication and feedback

RFC is primarily a request for collaboration and comment - not a request for approval.

The ‘approval’ phase just provides clarity on which stakeholders need to agree before implementation work commences.

It is a very small part of the process and is there to enable you to know who to chase and progress rapidly with an implementation, if required.

Confidence comes with practice

If you are uncomfortable sharing the initial draft with everybody, share it with a few colleagues first, then with your team, then with everybody as an RFC.

Collective Ownership

Even though someone may take the lead for creating an RFC and managing the feedback process -- the ownership of the RFC belongs with the team.

Technical Leads, Solution Architects, Staff and Principal Engineers, etc should be closely involved in coaching and helping to prepare RFCs.

Keep comments respectful

When commenting on RFC's, focus on the technical content. This isn’t about the author - it’s about the ideas.

Keep it objective, technical .. and kind.