Request for Comments

Request for Comments are very useful tool for articulating proposals how to address particular problem and to solicit feedback.

Staff+ responsibilities include defining technical vision and building great engineering culture around it. None are possible without articulating the principles, strategies and plans, while being transparent, inclusive and open to feedback.

One of great tools to achieve exactly that is: Request for Comments (RFC).

RFCs have been used in the software engineering since seventies, mostly by the standards-setting bodies like IETF, IAB, etc. Due to sheer magnitude of proposed changes, those RFCs are very formalised and have high density of information, often in hundreds of pages of content. An example can be found here.

A less formalised version of RFC has been used by Staff+ / Engineering Leadership to drive change across organisations.

It is mostly used for technical matters, for example:

• architecture (re)design
• new messaging topology
• monolith decomposition
• database scaling strategy
• etc.

However, it can be used also for product-related matters (e.g. defining feature limits, validations, etc.), technical excellence standards (e.g. code coverage, documentation, etc.).

Although the structure and wording varies, every RFC should consist of the following key sections:

Introduction

Should provide enough context for the reader to understand where the topic fits in overall scheme of things. It is not intended to be place for onboarding people who have zero context on the matter.

Problem Statement

Should provide a concise list of essential problems this RFC tries to solve.

Success Criteria

Based on the Problem Statement, should provide a list of clear criteria that all available options are evaluated on.

Proposal and Alternatives

Should describe the proposal and alternatives with explanation how they fit success criteria.

Decisions

Should list decisions as outcome from the document. Eventually those should be transformed into Architecture Decision Records (where applicable) and linked inside.

The focus should not be on the structure but matter itself, i.e. is the problem properly articulated, is the success criteria complete, have all options been reviewed and evaluated.

Bonus: RFC template