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.