Embracing an RFC-based decision making culture at Delivery Hero
Introduction
As a recent addition to the Delivery Hero (DH) family in the role of a Principal Software Engineer, I’ve been presented with a unique opportunity to delve into and learn from a modern and diverse work culture. Amid various best-practices and methodologies, one practice that prominently stands out at Delivery Hero is the RFC (Request For Comments) approach to decision making, present across engineering, product and management levels.
Coming from an Amazonian background, this culture contrasts somewhat with my previous experience at Amazon Web Services (AWS). AWS fosters a more agile, high-velocity work environment, fueled by rapid experimentation and the ethos of quickly learning from failure. In contrast to the RFC model, Amazon utilizes a distinctive PR/FAQ (Press Release/Frequently Asked Questions) approach.
The comparison of these two approaches makes me reflect on the diverse ways decision-making can be effectively structured in the tech industry.
RFCs at Delivery Hero
At Delivery Hero, the use of RFC documents is often more expansive, providing detailed specifications and substantiating proposals with robust data. This typically requires the creation of Proof of Concepts (PoCs) and comprehensive analyses to accurately measure and validate projected benefits or cost impacts. This methodical approach guides RFC owners and engineers to adopt a more holistic mindset, including expected milestones and major considerations, ensuring well-grounded and thoroughly evaluated decisions.
Case Study: Kafka Adoption Attempt
While I’ve driven several successful RFC initiatives at DH to date, I believe it’s important to reflect on a case where, despite my high motivation and engineering excitement, the RFC process led us to take an alternative path. This particular case centers around an initiative I led where we explored the feasibility of adopting Kafka over SNS/SQS for our internal messaging needs within the Optimization Tribe’s routing solutions.
At first glance, Kafka seemed to promise substantial technological improvements. Particularly, it appeared capable of reducing our “message propagation delay”, increase durability, simplify Pub/Sub requirements and, when implemented at scale, potentially lowering costs. This initiative was an exciting prospect, especially given Kafka’s reputation for efficiency and power in the realm of real-time data streaming.
Nevertheless, the RFC process steered us towards a different conclusion. Through detailed analysis of the pros and cons, backed by data-driven facts and considerations, we realized that cost savings would only materialize in the future as our architecture evolved. Interestingly, our cost review process led us to optimize our current SNS/SQS usage instead, through distinct optimizations and increasing cost awareness among the teams. Furthermore, considering the technology risks and efforts associated with adopting Kafka in the middle of several innovation projects, our tribe squads (Software Engineering teams) proposed to delay its integration until our new architecture was fully established and the lower latency offered by Kafka became a crucial requirement.
This outcome, while unexpected, was also positive and perfectly valid, considering our tribe’s product and engineering roadmap.
Areas for Improvement in RFC-Based Decision Making
Despite the numerous benefits, our RFC-based decision-making process is not without room for improvement. We are constantly exploring ways to streamline the process, such as keeping the list of reviewers concise yet effective, and ensuring a timely review process under 14 days, especially when it involves external (cross-tribe) reviewers.
Conclusions
As I look back on my initial five months at DH, I find myself fully embracing the RFC culture that defines the organization. With a deeper understanding now, I can see that this framework provides a solid foundation for fostering collaboration, endorsing consensus-based and data-driven decisions, and emphasizing the importance of thorough analysis, design and collective decision-making.
Read more about RFCs: Why you should use RFCs
