Ownership: "You Build It, You Run It"

In 2006, Amazon CTO Werner Vogels gave an interview to ACM Queue about the architecture decisions behind Amazon's services. One line from that interview became one of the most quoted phrases in the DevOps world: "You build it, you run it." His fuller explanation is worth reading in full, because it's easy to reduce this to "engineers should be on call," which misses why he thought it mattered:

Notice the reasoning: it's not about punishing developers or saving on headcount. It's a feedback-loop argument, directly connected to Module 4. Nothing teaches a developer to write operable, debuggable, resilient code faster than being the person who gets woken up at 3 AM by their own bad assumption. And nothing kills that lesson faster than a wall that lets the same developer sleep soundly while someone else — someone who didn't write the code and doesn't fully understand it — absorbs the pain instead.

Ownership is a feedback mechanism, not a punishment

It's easy to hear "engineers should be on-call for what they build" and think of it purely as a burden being shifted onto developers. That framing misses the actual mechanism. On-call isn't valuable because suffering is good for engineers. It's valuable because it's the fastest, highest-fidelity feedback loop that exists between a design decision and its real-world consequences. An engineer who writes a service with a confusing failure mode and then personally has to debug that failure mode at 2 AM will make different design decisions next time — not because they were punished, but because they now have first-hand knowledge no design document could have given them.

Compare that to the old wall model: a developer writes a confusing failure mode, an operations engineer gets paged, restarts the service because that's the only lever they have, and files a ticket that may or may not ever get prioritized. The developer never directly experiences the consequence of their own decision. The lesson simply doesn't get learned, and the same class of bug tends to recur.

What ownership requires to actually work

"You build it, you run it" is often adopted as a slogan without the supporting structure that makes it humane and sustainable, which is how it gets a bad reputation. For ownership to work without just burning people out, an organization needs to actually provide:

• Real authority to fix things — an engineer on-call for a service needs the access and autonomy to actually change it, not just watch it break and escalate.
• Sustainable rotation — on-call needs to be shared across a team, with enough people in rotation that no one is permanently exhausted, and compensated appropriately where that's the norm.
• Good tooling — Module 4's observability investment isn't optional here; being paged for a problem you have no visibility into is torture, being paged with clear dashboards and logs is manageable.
• A blameless response to incidents — ownership without psychological safety just turns into fear of being blamed for the next outage (this is exactly what the Blameless Postmortems module addresses).
• The authority to say no — a team that owns what it runs also needs the standing to push back on unrealistic deadlines that would compromise operability, not just the obligation to clean up after them.

Ownership scales differently than you'd expect

A common worry is that this model doesn't scale — surely a company with hundreds of services can't have every engineer on call for everything. It doesn't need to: ownership is usually organized around specific services or systems ("you're on-call for the payments service you and your team own" — not "you're on-call for the entire company's infrastructure"). This is one of the reasons DevOps-practicing organizations tend to favor smaller, more autonomous teams that fully own a bounded piece of the system, end to end — which is also exactly the organizational shape Conway's Law, in the next module, says naturally produces cleaner architecture.