Table of Contents

• The Core Idea: Understanding the W, X, Z layers and their functions
• Healthy Relationships: How these teams collaborate effectively
• Common Problems (And Solutions): X-Z Mixing, Z-Z Mixing, W-Z Mixing, Horizontal Disconnects

> If you’re curious about the missing “Y”: Initially, Brian Stoler, Reza Behforooz, and I identified X, Y, and Z layers, but later discovered a W layer existed, while the Y layer was nonexistent. Thus, we settled on W, X, and Z.

The Core Idea: Systems Have Three Layers

The Z layer represents the user-facing aspect of the system, encompassing a multitude of features. New Z components are frequently tested while older ones are phased out.

The primary challenge for teams involved in the Z layer is to discern what customers genuinely want (often referred to as product-market fit). Consequently, those engaged with the Z layer prioritize rapid experimentation and customer adoption metrics. Their focus tends to be short-term, often spanning months rather than years, and while they utilize infrastructure, they may lack expertise in it and often prefer not to delve into it.

The X layer serves as the infrastructure supporting the Z layer, communicating in the same terminology — for instance, using concepts like “users” or “feeds” instead of “integers” or “cores.”

The X layer’s responsibility is to streamline experimentation for Z teams, ensuring that they can pursue customer-centric inquiries without being bogged down by unrelated issues, excessive coordination, or the risk of one Z component disrupting the entire system.

Consequently, X layer professionals emphasize isolating issues and gauging success through the flexibility of Z teams. Their perspective is long-term, spanning years, unlike the Z teams who focus on shorter timelines.

The W layer, situated beneath the X layer, often presents primitives that differ significantly from those relevant to the Z layer. For example, it may involve storage systems that manage bytes, while Z teams concentrate on users and feeds. In many respects, the W layer operates similarly to the X layer, but its clientele consists of a smaller number of infrastructure-savvy teams that share a similar long-term perspective.

W layer teams cultivate close relationships with their clients, emphasizing performance and reliability, measuring success through the ability of X teams to scale seamlessly. Unlike the X layer, W-layer infrastructure can be procured from third parties.

Distinct from these three layers are horizontal functions like security, privacy, legal, health, and site reliability. These functions don’t constitute layers per se but rather act as custodians of shared resources within the organization (such as reputation or security). They collaborate closely with W and X layer teams to ensure that critical behaviors are incorporated into the infrastructure, allowing Z layer teams to focus on their respective tasks without needing to address these concerns directly. They aim to ensure that the system can gracefully handle failures, measuring success by the health of the resources they oversee.

> The concept of “three layers” is not exhaustive: each layer can contain sublayers. For example, an X layer might have its own foundational layer (the “W of the X”) that facilitates building higher X layers, a mid-layer of shared primitives (the “X of the X”), and a top layer (the “Z of the X”) that embodies Z layer logic, reused by multiple Z teams. Furthermore, if you’re sourcing a W layer externally, that provider will also have W, X, and Z layers within their organization, making you a customer of their Z layer.

Healthy Relationships

When operations run smoothly, the dynamics resemble this:

• W-layer teams concentrate on scalability, reliability, and security, maintaining close communication with X-layer teams and anticipating future demands. They monitor system performance metrics, ensuring that while overall load increases, negative impacts remain minimal. If acquiring technology rather than developing it, they focus on seamless integration into the X-layer ecosystem.
• X-layer teams increasingly adopt a mindset akin to W-layer teams, considering aggregate load from their users. They categorize customers into large accounts with intimate relationships and smaller ones with more self-service interactions. They closely observe the types of experiments Z teams wish to conduct and develop new features to facilitate those endeavors.
• Z-layer teams engage in extensive experimentation, often unaware of the W or X layers, focusing primarily on numerous ideas for product enhancements and a relentless pursuit of product-market fit. Occasionally, they encounter concepts necessitating fundamentally new infrastructure, leading to frustration when it’s not available.
• Horizontal teams evolve into central reviewers and embedded support within W, X, and Z layer teams, ensuring collaboration and communication. They actively assist teams in navigating potential failure scenarios and managing escalations effectively.

> Remember: Escalation is a healthy practice!

Escalation is often misconstrued as a negative indicator or something to be avoided. However, it serves several important functions: it brings decision-makers together, facilitates resolution, and clarifies the issues at hand.

If escalation is avoided during prolonged discussions, it merely prolongs indecision, causing stress and inefficiency. Therefore, it’s crucial to escalate matters promptly for the benefit of your team, management, and overall project success.

Common Problems (and How to Handle Them)

This model reveals four prevalent issues — and strategies for addressing them. Most stem from inadequate separation between layers: X-Z Mixing, Z-Z Mixing, W-Z Mixing, and Horizontal Disconnect.