Starting with SRE? Why the Kitchen Sink Model Might Be Your First Step

The Kitchen Sink SRE model serves as a starting point for organizations that start their reliability experience. This approach differs from specialized implementations. It creates a single SRE team with an unbounded scope that covers almost all services and workflows across the organization. The model got its nickname because it contains "everything but the kitchen sink" – or maybe even the kitchen sink too!

Google developed this model during their early SRE days. The Kitchen Sink model grew naturally as their original SRE implementation before they created more specialized approaches. A centralized team of reliability engineers handles reliability concerns across the entire technology stack without strict boundaries on their responsibilities.

Organizations adopt this approach to test the waters when they set up their first SRE team. The team adapts quickly to emerging needs because they don't have a clearly defined scope. They handle any reliability challenges that pop up throughout the organization.

The Kitchen Sink model provides several key benefits that make it a great fit for organizations just starting with SRE:

• Complete coverage – Nothing slips through the cracks between teams because a single team handles all reliability concerns. Teams know exactly who's responsible for specific issues.

• Pattern recognition – Engineers spot similarities between systems that seem unrelated and apply solutions more broadly when they work across multiple services. Ideas spread naturally and lead to standardized approaches.

• Connective tissue – The SRE team acts as "glue" between different development groups and creates all-encompassing solutions from distinct software components. Teams break down their silos and work together more effectively.

Agile Analytics has shown how this model excels at connecting different reliability metrics across systems. Our platform helps organizations find these connections by linking data (like error budgets and SLOs) with developer experience feedback. We highlight meaningful correlations that might stay hidden otherwise.

The Kitchen Sink model has its drawbacks, especially as organizations grow bigger:

The biggest problem comes from not having a clear team charter. The team risks getting overloaded with responsibilities because everything could fall within their scope. System complexity makes this worse – what starts as deep, influential contributions becomes shallow involvement across too many areas.

Organizations don't deal very well with this model as they scale up. The team's impact shifts from revolutionizing the entire business to making small contributions in many areas. This reduced impact goes against SRE's goal of focusing on high-impact improvements.

Problems within a single Kitchen Sink team can affect the entire business. The lack of separate SRE teams means no isolation of risks or failures. This creates a single point of failure for reliability practices.

The Kitchen Sink model fits specific organizational contexts despite these challenges. Google suggests this approach for companies with few applications and user journeys.

This model works best when:

1. Organizations have grown beyond what they can handle without a dedicated SRE team

2. The scope stays small enough that multiple SRE teams aren't needed

3. Companies have all but one of these products or customer journeys

Technology providers like Relevant Software have successfully used this approach to cover all customer needs while providing end-to-end SRE services. Our Agile Analytics platform helps organizations track whether this model serves their needs by connecting quantitative reliability metrics with team feedback.

Organizations often implement a hybrid model as they grow. They combine specialized SRE implementations with their original Kitchen Sink approach. Some use service tiers to alleviate limitations while keeping the original structure.

Development teams should understand these structural limitations when working with Kitchen Sink SRE teams. This helps set realistic expectations. A single team might handle everything at first, but this approach needs to evolve as the organization scales.

The next sections explore alternative models. We'll see how they address the Kitchen Sink approach's limitations while keeping the fundamental benefits that make SRE valuable for developer experience.