Shared Ownership Model: Bridging the Dev/Ops Divide

WHY IT EXISTS: The traditional split between development and operations teams creates inherent conflict. Developers are incentivized to ship new features quickly, while operations is tasked with protecting the stability of the production environment. This leads to friction, blame, and a cycle of swinging between too much risk and too much caution.

THE MENTAL MODEL: Shared ownership reframes the relationship from a handoff to a partnership. Instead of two teams with opposing goals, dev and ops (often in the form of an SRE team) share a single objective: delivering a service that is both reliable and evolving. Both disciplines are seen as essential specializations working toward a common goal, rather than adversaries.

HOW IT WORKS: The model is put into practice by establishing shared goals and a common language, typically through Service Level Objectives (SLOs) and error budgets. These tools provide a data-driven framework for making trade-offs. If a service is meeting its reliability targets, the team can prioritize feature releases. If the service is becoming unreliable, the focus for everyone shifts to stability. This replaces subjective arguments with objective, customer-focused metrics.

WHEN TO USE IT: This model is most effective in organizations where the friction between dev and ops is actively hindering progress. It's a powerful solution for companies aiming to increase engineering velocity while maintaining service quality, especially during periods of growth or migration to the cloud. It's ideal for moving past a "throw it over the wall" mentality.

WHEN NOT TO USE IT: Shared ownership can fail in organizations with deeply entrenched silos and a culture that resists cross-functional collaboration. Without strong leadership buy-in to enforce shared accountability, teams will likely revert to their old behaviors. For very small startups where developers naturally own the full lifecycle, a formal model may be unnecessary.

ONE CANONICAL EXAMPLE: Evernote experienced the classic ops/dev split, where the development team felt constrained and the operations team was frustrated by production issues. After trying both a "You wrote it, you run it" model and a "You wrote it, we run it for you" model, they adopted an SRE-centric approach. This created a happier medium, balancing feature development with the ongoing delivery of a reliable service to their users.