Technical Decision Making
Technical decision making happens differently based on the size and scope of the technical project. For smaller technical decisions, such as how to shape a data payload, where to hydrate a component, etc, decisions can be handled in a quick tech spec either via a ticket, discussion, or diagram (or combination of the three). If the decision requires the input of technical leadership or the broader team, an RFC should be drafted and shared with the appropriate parties. Finally, for large technical projects, such as platform migrations, new system builds, or major feature updates, a tech design document should be created.
Discussion/Diagram
When a team member needs to choose between a few different approaches or a needs some quick feedback decisions can be made via quick discussions, diagrams, or tech specs. These can be facilitated via pair programming sessions, Round 2, adhoc meetings/huddles, Slack chats, or tech specs in tickets. Even though these are smaller decisions and tend to move more quickly, they should still be documented somewhere (PR, codebase, internal docs, ticket, etc).
RFC
The RFC template is in the Eng Wiki in Google Drive. This allows for easy commenting and updating while decisions are being made. Anyone can create an RFC and assign it to reviewers. Typically engineering leadership uses RFCs to discuss and align on an approach for larger pieces of work or processes. The RFC should clearly state the problem, the proposed solution, how success will be measured, and what other options were considered but ultimately not chosen. Reviewers should comment async and a meeting should be scheduled to align on next steps. Previous RFCs are listed in the Eng Wiki for posterity and review. Once a decision has been made the subject of the RFC is a strong candidate for discussion in Engineering Collab.
Tech Design
Tech design docs should be blueprints detailing how software systems or features will be built, translating high-level requirements into a concrete, actionable plans with specific architecture, components, data flows, and APIs. It should serve as a shared guide for developers, stakeholders, and future teams to ensure clarity, alignment, and identify edge cases early. These should also be stored in the Eng Wiki in Google Drive.