I've watched many IT trends come and go in my 30+ years in the business. I always know that we are in trouble when a trend becomes less a practice that brings true value to organisations, and more a marketing buzzword. This gives rise to an endless proliferation of vendors, tools, conferences, certifications, videos, and literature - much of which is merely opportunism without adding value. And this has happened to DevOps.
A key indicator of this for me is that in the past 5 years I've noticed a significant drop in the quality of many DevOps engineers. I put this down to one single factor: they increasingly do not have a mindset built over years of experience, focused on delivering long-lasting solutions and tuned to the technical, business, product and customer needs of organisations.
I started doing DevOps long before the term existed; hand-crafting automation tools for what we now call IaaC and CI/CD. A lot of people I knew were doing the same thing. The reason was practical: manual, repetitive tasks are not good for accuracy, consistency, delivery velocity, product reliability nor the organisation as a whole.
Over time I found that the DevOps role is more central to an organisation than people realise. It ultimately supports three crucial areas of an organisation: its products, its customers and its technology. To do it right, the very design of DevOps practices and solutions must rely on communication and feedback loops from product, customers, and IT teams. This is the only way to ensure that products are built consistently and delivered faster, that customer-facing infrastructure is reliable, performant and available, and that IT teams have a reliable and frictionless process mechanism to support their work.
Taken together, this is what I call the "DevOps Mindset": a deep technical capacity, a sensibility to the needs of the organisation, the ability to understand the needs of customers, developers and product teams, a truly holistic approach to solving problems.
Today I see many people calling themselves DevOps engineers do not have this mindset. They do their work without thinking deeply. They plug and chug. They rely on certifications for legitimacy and AI to tell them what to do, without reference to the wider context. They certainly do not actively engage, to whatever extent is possible, in getting crucial feedback from product, customers and teams.
As a result, their "solutions" at best have a limited shelf-life, but at worst they introduce more problems than had they not done anything at all.
By contrast, many of my DevOps installations have lasted years after I left a client because they worked and kept on working. I've worked with many like-minded DevOps engineers who've done the same. These are people who know not just how to solve complex problems, but to do so in a holistic way that brings greater value to their organisations.
In conclusion: if you are in a hiring position, dig deeper in interviews. Ask "soft" questions that assess the mindset of the candidate. Do they understand how their work relates to product? Do they have a track record of collaboration, by which I mean, taking the time to properly understand the needs of customers, developers and product teams BEFORE designing a solution? Can they understand and appreciate the needs of different IT teams? Do they know how to choose technologies that fit with the IT culture? Do they have the capacity to take the long view of their work or do they only focus on quick-and-dirty fixes? From my experience across many interviews, I find that these sort of questions will very quickly weed out people I wouldn't want touching my infrastructure.
Lajos Moczar - 31/10/2025