Everyone at Level does a little bit of everything. We have a research, data engineering, and our investment team collaborating on initiatives, where the only consistency is the sheer variety. One practice that we've settled on is the use of Request for Comments (RFCs) to build consensus on technical initiatives across the firm.

RFCs come from a deep technical history for the development of the Internet. Although we have grand ambitions, we aren't developing something like the Internet, but the general concept and nomenclature is on point. We've adapted the RFC process for our own and, as a nod to this tradition, have kept the term.

We use RFCs to communicate on and build consensus for technical decisions that affect a large portion of our technology stack. They serve as authoritative specifications (i.e. specs) for these decisions and we mostly (though not always) implement technology against an RFC. RFCs need not provide exact details on a specific implementation, but they should include clear guidelines on expected and intended usage of various tools (whether code libraries, packages, technical tools, 3rd party tools, or otherwise).

Our RFC Process

Any person may write an RFC. The current owner of an RFC is responsible for managing the RFC process. The steps are as follows:

1. Someone should create an RFC page in our notion page with an appropriate number, a preliminary status, a working title, and an owner (usually the person who wrote it).
2. Once the RFC is written, its status should be updated to in progress and circulated (typically via Slack). Anyone may read through the document, leave comments, or make edits and the owner should drive the process of editing the RFC.
3. After appropriate discussion and editing, one of the following actions should be taken: the owner can accept the RFC if the RFC achieves consensus or the owner can reject the RFC.
4. If accepted, the owner should ensure that a plan (with timeline) is created for implementing the RFC and this plan should be documented appropriate (both within the RFC and through other necessary task/project management processes). Once the RFC is implemented, its status can be set to implemented.
5. The owner should periodically verify the RFC. If the RFC is no longer in use, it should be marked as deprecated and marked as indefinitely verified.

RFC Statuses

We currently have the following color-coded status for our RFCs:

• ⚪ Preliminary: an RFC that is still a draft
• 🔵 In progress: an RFC that has been issued for review and is being edited, modified, and discussed. Note that this status refers to the content of the RFC, not the status of any implementation.
• 🟢 Accepted: an RFC that has achieved consensus and will be implemented or is being implemented.
• ⚫ Implemented: an RFC that is active and to which we have conformed our technology.
• 🔴 Rejected, or 🟠 Deprecated: an RFC that was either rejected or an RFC that was implemented but has been replaced, abandoned, or substantially removed.

Building Consensus

RFCs are accepted via consensus. Consensus does not mean that everyone believes that the RFC is the best idea, but rather that there are no major issues and that everyone can live with the RFC as it stands. We should not let perfect be the enemy of the good: rather, we should make practical technical decisions that we can all commit to. By the nature and structure of our process, we inevitably build consensus by writing our RFCs and having a robust conversation about cross-cutting technical practices.

Our RFCs are authoritative. They specific how things should work, but sadly, reality may not always conform to our will. Sometimes, our actual technical practices or implementations will conflict with an RFC; any conflicts with an RFC are formal bugs or errors. This principle lets us distinguish between technical practices that develop out of habit vs. carefully made decisions.

If a technical practice conflicts with an RFC, then either the practice or implementation needs to change through our change control process or the RFC needs to be updated via the consensus process to reflect an actual change in how we do things.

Conclusion

Contrary to other RFC usage, our RFCs are living documents. It is appropriate for the owner to edit an RFC to reflect current implementation status, make things more clear, address additional questions as they arise, or otherwise keep the document up-to-date. The owner may make minor amendments from time-to-time about specific details if need be; the document history in Notion will reflect such changes and, as such, may not be explicitly called out.

By using this RFC process, we can build consensus for cross-cutting technical decisions across a highly multifunctional team.