The term “DevOps” was formally introduced around 2009, but the practices it describes are far older. Countless engineers were collaborating across development and operations boundaries, automating repetitive tasks, and shortening release cycles long before anyone called it DevOps. If that sounds like your career history, you are not alone.
The Idea Behind the Observation
The observation that practitioners were doing DevOps before the label existed comes from a common experience shared across the industry. Engineers reading early DevOps literature — books, conference talks, case studies — frequently recognize patterns from their own past work. The methodology did not emerge from a vacuum; it was distilled from practices that already existed in high-performing teams.
This point was made clearly in a post originally published on the Quest community blog: You may be doing DevOps and not even know it. The author recalled finishing a DevOps book and realising that the journey described inside mirrored their own experience from nearly a decade earlier — not as a claim of invention, but as a moment of recognition.
What DevOps Actually Describes
DevOps is not a product, a job title, or a tool. At its core it is a culture and a set of practices aimed at reducing the friction between software development and IT operations. The foundational ideas include:
- Collaboration across silos: Developers and operations engineers work together from design through deployment and ongoing monitoring, rather than throwing work over a wall.
- Continuous integration and delivery (CI/CD): Code changes are integrated frequently, tested automatically, and delivered to production in small, low-risk increments.
- Infrastructure as code (IaC): Servers, networks, and configuration are defined in version-controlled code rather than managed through manual, undocumented steps.
- Fast feedback loops: Monitoring, alerting, and observability tools give teams immediate insight into how software behaves in production so problems are caught and fixed quickly.
- Shared ownership: Teams take responsibility for the full lifecycle of a service — building it, running it, and improving it — rather than handing it off after deployment.
- Blameless post-mortems: When incidents occur, the focus is on systemic improvement rather than individual blame.
Signs You Were Already Doing DevOps
Before checking whether any of the following applies to your past work, consider that many of these practices were common in smaller teams and startups years before enterprise organisations formalised them under the DevOps banner.
- You wrote shell scripts or used tools like Make or Ant to automate builds and deployments before CI platforms were mainstream.
- You sat next to — or regularly talked to — the people who ran the servers your code would land on.
- You had on-call responsibility for services you wrote, not just services someone else handed you.
- You used configuration management tools such as CFEngine or early versions of Puppet or Chef to keep environments consistent.
- You pushed for smaller, more frequent releases rather than large quarterly deployments.
- You set up monitoring and alerting for your own applications rather than waiting for an operations team to do it.
- You treated infrastructure configuration as code and stored it in version control.
Why the Label Still Matters
Recognising that you were already doing DevOps is not just an interesting personal observation. It has practical implications for how teams communicate, hire, and improve.
When an organisation decides to “adopt DevOps,” it often already has engineers with deep, practical experience in the relevant practices. Identifying and elevating those people — rather than assuming DevOps is something entirely new that must be imported from outside — accelerates adoption and avoids the trap of treating a cultural shift as a tooling purchase.
The label also provides a shared vocabulary. Once your team agrees on what continuous delivery, blameless post-mortems, or infrastructure as code mean, it becomes easier to discuss improvements, measure progress, and onboard new engineers into a consistent working culture.
DevOps as a Formalisation of Good Engineering Practice
Perhaps the most useful way to think about DevOps is as the formal codification of practices that effective engineering teams had already discovered on their own. The movement gave those practices names, documented them, and made it possible to teach and spread them more deliberately.
If you have been in software engineering for more than a few years, there is a good chance you contributed to or benefited from DevOps principles long before you heard the word. That experience is valuable. Use it to help your team move forward rather than treating DevOps as something that only arrived recently.
Original insight sourced from: You may be doing DevOps and not even know it — Quest Community Blog.