Continuous Delivery starts with being responsible for the software. As mentioned earlier, for the DevOps movement, it is not sufficient for developers to just build their software and let other teams deal with potential errors. The development team that creates and owns the application knows about its responsibilities, used technologies, and troubleshooting in case of potential errors.

Imagine a small startup that has only a single developer who responsible for the application. This person obviously has to deal with all technical issues, such as development, builds, deployment, and troubleshooting the application. He or she will have the best knowledge about the application's internals and will be able to fix potential issues effectively. Obviously, this single point of responsibility approach is the opposite of scalability and only works for tiny teams.

In bigger companies, there are more applications, more developers, and more teams with different responsibilities. The challenge with splitting and shifting responsibilities is to transfer knowledge. The knowledge is ideally spread within a team of engineers who closely work on the same software. Like in small startups, the mantra for developing applications should be: you build it, you run it. For a single team, this is only possible with the support of central, well-defined and automated processes. Implementing Continuous Delivery pipelines implement these processes to reliably ship software.

Managing and refining these processes becomes the responsibility of the whole team of engineers and is no longer an ops problem. All developers are equally responsible for building and shipping working software that provides value to the business. This certainly involves some duties, or team habits.