They are different skills, but people can have many skills. Having a team that considers adding features with operations in mind from day one results in much m

They are different skills, but people can have many skills. Having a team that considers adding features with operations in mind from day one results in much more reliable services. The only reason people look for specialists is so that they can scale their org by having separate teams. But whenever you split things like this, incentives for individual teams diverge from the end goal of "give users reliable software". Ops will reduce risk at the cost of features. The most reliable software is no software at all. Dev will want features at the cost of operational ease. The most featureful software is software that doesn't have to authenticate users and deal with pesky real-world concerns like running on servers that cost money. I don't think it can be made to work. I think when you need to scale up, a better model is to treat shared infrastructure like it's own business. You have products that customers can buy, rather than saying "operations manages the servers" and "dev manages the code". I have worked at places that do that, and the results were very good. I have also done the "dev manages everything up to the end user", and that's also great (but requires a training investment for team members that haven't done operations before). Finally, I worked at a place that split dev and operations as hard as possible and ... I don't think in the years that I worked there we ever ran anything in production. The process for putting code into production seemed to take on the order of years, so people just ran it on their workstation. Sometimes implemented inside an Excel spreadsheet. Now that I think about it, most of my time was spent debugging that and not delivering features. I wouldn't recommend it.