I had a completely different experience with DevOps at a large MANGA than the author. Where I was, DevOps meant that the team that wrote the code, maintained i

I had a completely different experience with DevOps at a large MANGA than the author. Where I was, DevOps meant that the team that wrote the code, maintained it in production. The thinking and upside of this was that quality wasn’t an externality. If your code sucked, then you had a bad experience with ops, and you were motivated to fix it. Where that could fail is when managers didn’t have skin in the game- it’s important that managers have to feel some of the ops pain personally to prevent psychopaths from destroying a team just so they could look good schedule-wise. Note also that “tech debt” either became an ops problem, which self-corrected as described above, or it became an agility problem, where it took forever to make changes to code. DevOps as I saw it didn’t have a good answer to the latter. We had lots of different teams for different projects; having one team know everything about everything wasn’t a thing. Perhaps the problem is that DevOps is not well suited to smaller or less differentiated organizations.