Service responsibility with Full Service Ownership

Full Service Ownership makes teams responsible for the end-to-end lifecycle of their services.

This includes:

• Product Ownership, User Experience/User Research
  • Product Owners, together with research and user feedback, establish a roadmap and a backlog of features to work on. It’s the product owner’s job to translate customer requirements into actionable work, and to prioritize customer requests against work other work like R&D, addressing of technical debt, improving reliability, etc.
• Design
  • Designers typically work ahead of implementation because they try out different possibilities, perform experiments on mock interfaces and iterate.
  • However, software development should be closely involved because design decisions impact the implementation, and some designs are considerably more costly to implement than others.
  • Additionally, Design & UX have a lot of “customer use-case knowledge” that is very beneficial for software developers to have. By encouraging close collaboration between design and implementation, this knowledge is more easily transferred.
• Software implementation
  • This is the typical implementation work we think of when talking about software development. “Writing code”, in other words.
• Quality Assurance
  • Adequate testing/QA is needed to validate implementations.
  • While it may be necessary to have have a QA structure in place with a reporting line up to a different manager than the engineering/software development manager for compliance purposes, the day to day QA process should be owned by the service team.
• Infrastructure and operations
  • Full Service Ownership teams run their own software in production.
  • The service team is responsible for deploying their application, all the operational day to day work which comes with running a service on some piece of infrastructure, as well as setting up monitoring and alerting to be able to observe the health of the service (focus on ensuring SLOs).
  • An on-call rotation should be the responsibility of the service team itself, as making another team or set of people responsible for responding to alerts for a service they are not familiar throws up all kinds of barriers.
  • You can have service teams which completely own all of their infrastructure, or you can have a support team which provides expert knowledge, helps coordinate or provides organization-wide support services, but the service team itself should be able to operate their service independently and without help in day to day operations.
• Documentation
  • Teams are responsible for all of the documentation related to their service. This includes both “internal” and “external” documentation.
  • Internal documentation: what does this do, who uses it, how do you set this up locally?
  • External documentation: user guides, helpdesk/knowledge base, etc.