DevOps was a word that meant different things to different people in 2015, and that confusion was both its weakness and its strength.
The weakness: half the conversations about DevOps were really conversations about tools. Teams would adopt Chef or Puppet or Ansible and announce they were doing DevOps now. Then nothing much changed. The deployments were still slow, the developers still threw things over a wall to operations, and the on-call schedule was still a nightmare.
The strength: because nobody agreed on a precise definition, the word created space for genuinely different conversations. Teams that got it right used "DevOps" as cover to try things that would have been shot down if they had come with a more specific label. "We want to let developers deploy to production" was a scary proposal. "We are implementing DevOps practices" was acceptable.
The teams that succeeded with DevOps in 2015 shared some characteristics that had nothing to do with which tools they chose.
They broke down the deployment pipeline. The old model was: developers finish code, hand to QA, QA tests, hand to operations, operations deploys. Each handoff added time and created blame-shifting opportunities. The DevOps model was to make developers responsible for the full path from code to production. This created accountability but also speed. When you own the deployment process, you have strong incentives to make it fast and reliable.
They invested in automation. Not as an end in itself, but because manual processes are slow, error-prone, and do not scale. Every manual step in a deployment was a potential failure and a bottleneck. Automation turned deployments from events (scary, infrequent, done by hand) into processes (routine, frequent, done by machines).
They changed the on-call culture. In the old model, operations ran things and got paged when they broke. In the DevOps model, developers ran what they built. This changed how software was designed. When you know you will be woken up at 3am if your code fails, you write code differently. You add monitoring. You think about failure modes. You make things observable.
The tools mattered, but they were downstream of the culture. A team with the right culture could make almost any toolset work. A team with the wrong culture would fail with any toolset.
By the end of 2015, the companies that had genuinely transformed their engineering culture around these principles were starting to see compounding benefits. Faster deployments, fewer incidents, better developer experience, and the ability to iterate on products at a pace that competitors could not match. The tools were never the point. The loop between writing code and seeing it run in production: that was the point.