The word "DevOps" was coined around 2009 at a small conference in Ghent, and the entire point of it was subtraction. There was a wall in every engineering org: developers threw code over it, operations caught the code and got paged when it broke, and each side blamed the other. DevOps was the argument that the wall should not exist — that the people who write the software should also own how it runs. Fifteen years later, you can hire a thriving industry of DevOps consultants whose core product is, functionally, building you a wall and charging you for it. We took the one idea whose whole purpose was to dissolve the ops silo and turned it into a billable silo you rent by the month.
The pitch everybody has heard
The standard DevOps consulting engagement has a shape you can recite before the sales call ends. A statement of work, a fixed list of deliverables: we'll stand up your CI/CD pipeline, containerize your services, provision a Kubernetes cluster, write your Terraform, wire up Datadog or Sentry, and hand you a runbook. A shared Slack channel for six or twelve weeks. A go-live. Then the team rolls off to the next client and you are, the slide deck says, "DevOps now." The deliverable is a stack. The implicit promise is a transformation. Those are not the same thing, and the gap between them is where the money quietly goes to die.
None of the individual pieces are wrong. CI/CD is good. Infrastructure as code is good. Observability is non-negotiable. The problem is the model — the idea that DevOps is a thing that can be installed by an outside party and handed over, like a kitchen renovation. It can't, because DevOps was never a set of tools. It is a question about who owns the consequences of a deploy. And ownership is the one thing a roll-off engagement is structurally incapable of transferring.
The handoff is the bug, not the feature
Here is what the runbook doesn't capture. The day the consultants leave, the knowledge leaves with them. The pipeline they built becomes a black box your team is afraid to touch. The Terraform describes the infrastructure but not the forty small decisions behind it — why that subnet, why that retry policy, why the deploy fails on the third Tuesday of the month. So the first time something breaks at 3am, the page goes to an engineer who has never seen the inside of the system that is now on fire, holding a document written by someone who is no longer answering. That is not a DevOps culture. That is the old ops-gets-paged-for-someone-else's-code wall, rebuilt by people you paid to remove it.
The tell is in the incentive. A consulting engagement priced on deliverables is rewarded for handing over artifacts, not for the far slower, far less glamorous work of making your engineers fluent in the thing they now own. Teaching is unbillable. A cluster is billable. Guess which one most engagements optimize for.
What DevOps actually measures
Strip away the tooling and the discipline reduces to four numbers that the industry's long-running research has converged on: how often you can deploy, how long a change takes to go from commit to production, how often a change breaks something, and how fast you recover when it does. Notice what is not on that list: how many tools you bought, whether you run Kubernetes, how thick your runbook is. The metrics are about flow and recovery — properties of a team that owns its own delivery end to end. You cannot buy a good change-failure rate. You can only build the ownership that produces one, and ownership is not for sale by the hour.
This is the part the conventional engagement gets exactly backwards. It treats the tooling as the goal and the ownership as a happy side effect that will somehow materialize once the cluster is up. In practice the causation runs the other way. Teams that own their infrastructure adopt good tooling because they feel the pain that the tooling fixes. Teams handed tooling they don't own treat it as a fragile artifact to be feared, and quietly route around it.
Where this lands for us
At EltexSoft we made one structural decision that settles most of this: DevOps is owned by the engineers who write the application code, not by a separate department. There is no ops team to throw a release over to. The person who gets paged when a deploy goes sideways is, as often as not, the person who wrote the deploy. That sounds like a staffing detail. It is actually the whole argument. When the author of the code is the one holding the pager, the incentives align without a single process document: nobody ships a brittle release to a system they personally have to babysit at 3am.
It is also why we are skeptical of selling a DevOps engagement as a clean handoff. Our DevOps work — CI/CD, Terraform and Pulumi, Kubernetes when it's warranted, monitoring and on-call tooling with the likes of Datadog, Sentry and PagerDuty — lives inside the same team that builds the product, and it stays with that team. The value isn't the pipeline we wired up. It's that the engineers running it afterward have run it the whole time. An engagement designed to leave is one where, by the time we go, there is nothing to hand over because nothing was ever held apart.
The Kubernetes tax
The single most reliable way to spot a DevOps engagement that is selling complexity rather than solving a problem is to watch how fast it reaches for Kubernetes. Kubernetes is superb at one job — orchestrating a large fleet of services across many nodes — and it is brutal overkill for the company that has eight services and forty engineers. But it is gloriously billable. It generates clusters to configure, manifests to write, an ongoing operational burden that conveniently requires the people who installed it. A team that genuinely needs Kubernetes knows it from concrete pressure — node counts, scaling events, multi-region requirements. A team that adopts it because a consultant put it on the roadmap has just bought itself a second full-time job. As a rough rule, most teams below roughly fifty engineers running a handful of services are better served by boring, managed platform services, and the thing that moves that line is real scale and real multi-service complexity, not ambition.
Platform engineering is the same argument, rebranded
The current vocabulary is "platform engineering" — Gartner has forecast that by 2026 the large majority of software engineering organizations will run internal platform teams. There is a genuinely good idea inside that trend: build a paved road so product engineers can self-serve infrastructure without becoming infrastructure experts. There is also a counterfeit version, which is the old ops silo with a new business card, a team that owns the platform so thoroughly that product engineers are once again strangers to how their code runs. The honest version increases the number of engineers who can ship and operate independently. The counterfeit decreases it and calls the resulting bottleneck "governance." DevOps consulting splits along exactly the same seam, and the rebrand has not changed which side is worth paying for.
When DevOps consulting is actually worth the money
This is not an argument that you should never bring in outside help. It is an argument about what you are buying. The defensible engagement is the one that treats your own engineers as the deliverable. You hire it to rescue a legacy deployment process and leave your team able to run the replacement. You hire fractional, CTO-level oversight to set architecture and vendor strategy and to build the on-call discipline — the kind of work that, priced sensibly, runs in the low-thousands to mid-five-figures a month rather than a six-figure transformation program. You hire it to transfer a capability you don't have yet. In every case the success condition is the same: when the engagement ends, your team is more capable than it was, not more dependent.
That is also why we start clients on a free discovery week and a paid pilot with no lock-in rather than a twelve-month managed-ops retainer. A retainer that renews because your team still can't run its own infrastructure is not a sign the relationship is working. It's a sign the knowledge transfer never happened — which, for a managed-service vendor, is the business model, and for a DevOps consultant, is malpractice.
The one test
So judge any DevOps consultant by a single question, and ignore the rest of the deck: when you leave, can my team run what you built without you? If the honest answer is no — if the pipeline is a black box, the cluster is a mystery, and the runbook is a hostage note — you did not buy DevOps. You bought a dependency, billed monthly, dressed as a transformation. Real DevOps consulting is the kind that works to make itself unnecessary. The good ones are trying to leave you with engineers who own their own systems. The rest are quietly rebuilding the wall, and charging you rent on it.
Last updated July 15, 2026