A client called me in a panic. "Nobody's using it. We spent $180K on this thing, and teams are still deploying manually." Unfortunately, I wasn't surprised. I've seen this movie before, and the ending is usually the same.
The problem isn't Jenkins, GitLab, or any other tool they've purchased. It's that most companies treat CI/CD as a technical project rather than what it really is – a fundamental change in how teams work. This is precisely where decent DevOps consulting makes all the difference.
Last quarter, I visited a manufacturing company that had built a fully automated deployment pipeline. Sounds great on paper. In reality, they'd had three significant outages in six weeks and had turned off most of it.
The pipeline worked perfectly in demo environments. But their actual codebase had spotty test coverage, their environments were inconsistent, and nobody had bothered to test whether they could actually roll back changes when things went sideways.
Good DevOps consultants don't start by automating your current mess. They determine which parts of your process are stable enough to automate and which need improvement first. Sometimes the best first step isn't a fancy pipeline – it's boring stuff like standardizing your environments or improving test coverage.
I met with a bank's tech team who'd spent a fortune on CI/CD tools that nobody used. The tools worked fine, but they couldn't handle the company's actual development process.
Their developers were still working on branches that lived for weeks or months. QA still expected a dedicated four-week testing phase for each release. And operations still required change request forms with three levels of approval for every deployment.
No wonder the tools were gathering dust! The best pipeline in the world can't fix organizational habits that directly contradict CI/CD principles.
Nothing kills adoption faster than making simple changes complicated. A hospital IT team proudly showed me their pipeline, which consisted of 22 mandatory stages. Then they admitted developers were finding ways to bypass it for minor fixes because it was taking hours to push trivial changes.
Updating help text doesn't need the same process as changing your payment processing code. Competent consultants help you establish various pipelines for different types of changes, tailored to their respective risk levels.
A retail client asked me to implement Jenkins last year. Instead of jumping into configs, I spent two days watching how they actually worked. It turned out that their biggest problem wasn't a lack of automation – it was that their test, staging, and production environments were completely different, causing constant deployment failures.
If we'd just automated their existing process, we would have just made bad deployments happen faster and more often. Sometimes the least glamorous work (such as environment standardization) can deliver the most significant impact.
A tech company CTO showed me their elaborate pipeline diagram spanning an entire whiteboard. When I asked if delivery had improved, he looked confused. "We haven't measured that, but look at all these automated stages!"
I've learned to steer clients toward four metrics that actually matter:
These indicate whether your pipeline is delivering actual business value or merely technical complexity.
A media company called me after their previous consultants built a pipeline nobody on their team understood. When the consultants left, the pipeline gradually broke as their environment changed, and nobody could fix it.
I've started refusing projects where clients want us to "build it for them." Either we pair with your team from day one, or we're setting you up for failure. Effective DevOps consulting leaves your team stronger, rather than dependent on external experts.
Run away from consultants who start by recommending tools before understanding your problems. Good ones ask about your business goals, current pain points, and team structure before even mentioning technical solutions.
A consultant who suggests Kubernetes before understanding your deployment challenges is solving the wrong problem – probably the one they're most comfortable with, rather than the one you actually have.
Every CI/CD implementation faces pushback from teams comfortable with the status quo. Bad consultants either ignore this resistance or try to steamroll it.
Good people recognize that resistance usually stems from legitimate concerns that need to be addressed. I once worked with a QA team that was fighting the CI/CD adoption. Instead of dismissing their problems, we came to understand that they were concerned about the quality of pain with rapid deployment. Once we showed how automated testing could actually improve quality while enabling speed, they became champions of the new approach.
DevOps practices that work for a five-person startup won't work for a 5,000-person bank. A consultant who's only worked with small tech companies will struggle with a regulated healthcare provider.
Look for advisors who have solved problems for organizations like yours. They will understand your obstacles and know which approaches actually work in your context.
Successful CI/CD is not about the tool - it's about changing how your team works together to deliver software. Good DevOps consultants address this difference by starting with an honest evaluation, focusing on business results, and bridging the gap by enhancing their team's abilities instead of creating dependence. The result is faster, more reliable, and less painful software delivery for all.