Service responsibility with Full Service Ownership
Full Service Ownership makes teams responsible for the end-to-end lifecycle of their services.
- 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.
- 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.
- 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.