How service ownership makes your product more reliable

Making your engineers responsible for their code in production may impact their development velocity, but will make your product more reliable.

The history of binaries

Before the SaaS era, developers used to code and deliver binaries, configuration manager use to wrap those binaries into installer files and to ship them, and customers to install them.

This model is called binary shipping where developers loose ownership as soon they deliver their binaries internally and therefore they couldn’t be held accountable unless involved in a support case.

Now in the SaaS era, developers still code and deliver binaries but the product team controls those binaries deployment as as cloud workloads (VM or Kubernetes Pod) allowing developers to access those binaries for monitoring and support.

The ownership evolution

Moving from binary shipping to SaaS product means developers and companies need to adapt to provide a better service for their customers. Product team can choose from two models:

• Service shipping: this model is the analogy of binary shipping. Developer codes, QA tests, DevOps deploys and Tier1 supports. The ownership of the service is broken down in silos making no one really accountable.
• Service ownership: this model puts developer accountable for his/her service. Developer codes, tests, defines part of the deployment, defines monitoring and provides support.

Choosing service ownership model will shape your R&D strategy

When you choose the service ownership model, you build your R&D strategy that supports this model.

• No QA structure: if a developer own a service, he/she is responsible also for all its testing aspects and therefore makes QA redundant.
• Multiple Subject Matter Experts (SME): if more than one developer owns a service, then we increase maintainability and support while reducing burden and burn-out.
• R&D on-call rotation: developers are part of the on-call rotation (24/7) that responds to monitoring alerts or customer complaints and therefore makes Support Tiers redundant.
• Continuous improvement: when developers monitors and support their services, they are able to provide quick feedbacks to improve code quality, monitoring definition alerting handling

Benefit of service ownership over Total Cost of Ownership (TCO)

Service ownership cost per developer is high because developer does more and there is a capacity limit for every developer, therefore make this model TOC more expensive, but the fact that this model doesn’t need QA or Support anymore to operate while making the product more reliable will allow to hire more developers to balance the cost of service ownership over more developers/teams.