The move toward DevOps adoption accelerated dramatically in the mid-to-late 2010s, and with rapid adoption comes a predictable side effect: teams pick up shortcuts, misconceptions, and anti-patterns that quietly erode the value they were trying to create. The following ten habits are among the most commonly cited by DevOps practitioners and engineering leaders. If any of them sound familiar, now is a good time to course-correct.
Practitioner quotes below were originally compiled by enterprisersproject.com. Attribution has been preserved.
1. Trying to Copy High-Scale Unicorns
It is tempting to look at organisations like Netflix or Amazon and try to replicate their release cadence — shipping dozens of times a day — regardless of whether that pace creates real business value for your users.
“DevOps professionals need to kick the habit of trying every fad, tool, and trick to deploy several times a day like Netflix and Amazon are famous for doing. There is no business value in continuous deployment if your company doesn’t observe the impact of each small change on the way end users behave. Ultimately, DevOps has to move away from being ‘cool’ to being ‘relevant.'”
Vinayak Joglekar, CTO and co-founder, Synerzip
Continuous deployment is a means to an end, not an end in itself. Before optimising deployment frequency, establish the feedback loops and instrumentation needed to measure real user impact. Without that foundation, faster releases just mean faster accumulation of unvalidated changes.
2. Treating Speed as the Only Metric
“One DevOps habit to drop is the constant focus on releasing faster, without improving quality. For example, you should not drive deployment automation without any automated tests. It’s a sign that everyone understands the automation aspect of DevOps, but often misses the necessary cultural groundwork, like having developers, testers, and operations teams building automation collaboratively.”
Ian Buchanan, Developer Advocate, Atlassian
Automation without quality gates is just a faster path to production failures. A healthy DevOps pipeline pairs deployment automation with a comprehensive automated test suite — unit, integration, and end-to-end — so that speed and reliability improve together rather than trading off against each other.
3. Bolting Security On at the End
“There’s a tendency among many product organisations to be myopic about how they approach DevOps; the emphasis is on pushing product fast, but that comes at the cost of ignoring security throughout the development lifecycle and into production. DevOps and SecOps should cross-pollinate and sprinkle their expertise throughout, which would result in an improved approach: DevSecOps.”
John Martinez, VP of Customer Solutions, Evident.io
When security reviews happen only after code is written, teams spend cycles on rework and are permanently in catch-up mode. The DevSecOps model integrates security checkpoints, automated scanning, and threat modelling into every stage of the pipeline — from design through deployment. This is not just a tooling change; it requires hiring practices and role definitions to evolve so that security expertise is distributed across the engineering organisation.
4. Allowing Development Silos to Persist
“The most common roadblock I’ve seen in working with Fortune 2000 organisations is that development isn’t just one team but many. Everyone is solving their own problems within their own silo, so operations struggles to unify the activity into a consistent, repeatable process.”
TJ Randall, VP of Customer Success, XebiaLabs
Agile and CI/CD improvements implemented team-by-team, without cross-team coordination, produce a patchwork of incompatible processes. Operations ends up manually bridging the gaps. Breaking down silos requires explicit organisational investment: shared standards, cross-team working groups, and incentives that reward system-wide outcomes rather than local optimisation.
5. Over-Standardising Tooling
“Creating too many standards around tools and not letting teams experiment with their own tools limits success. You should set some guardrails around architecture and how infrastructure is configured, but allow teams to choose technologies that will be the most effective for their particular needs.”
Matthew Perry, Director of IT Operations, WWT Asynchrony Labs
There is a meaningful difference between architectural guardrails — which protect interoperability and compliance — and mandating every tool a team uses. Lean principles emphasise enabling flow through the value stream, which sometimes means letting a team choose a build tool or testing framework that fits their workflow, even if it differs from another team’s choice. Experiment within guardrails; standardise where it matters.
6. Believing a Single Tool Is Your “DevOps Solution”
“One of the worst habits keeping companies from succeeding at DevOps is when they think a tool is their ‘DevOps solution.’ DevOps is a mix of culture, process, and tools — with the tools acting as support for both culture and process.”
Justin Rodenbostel, Executive Director of Open Source Application Development, SPR
Purchasing a CI/CD platform, a monitoring solution, or a container orchestration system does not make an organisation DevOps. Tools are enablers. Without cultural alignment — shared ownership, psychological safety, blameless post-mortems — and mature processes, even the best toolchain will fail to deliver its potential.
7. Failing to Automate Security Processes
“Security’s still too much of a silo in DevOps. Automate security processes as much as possible — shifting them ‘left’ (earlier) in the development pipeline. And work to create a security mindset in your developers. Most will never become true experts in security but, by involving them in security exercises, you can help to encourage an environment where security is everyone’s job.”
Gordon Haff, Technology Evangelist, Red Hat
Manual security gates are a bottleneck that teams learn to work around. Automating static analysis, dependency scanning, secrets detection, and infrastructure compliance checks directly in the CI pipeline removes friction while raising the baseline security posture. Inviting security engineers to design these checks collaboratively with developers accelerates adoption and builds shared ownership.
8. Assigning DevOps Responsibility to One Person or Team
“The leading derailment factor is assigning DevOps responsibility to one person or team. For DevOps transformation to truly succeed, everyone should be involved and engaged. Redefine success from ‘feature shipped’ to ‘satisfied customer.'”
Ofer Karp, Senior VP of Engineering, Perfecto
A “DevOps team” that acts as a separate unit — handing off pipelines and infrastructure to product teams — recreates the very silo that DevOps was designed to eliminate. Genuine transformation means developers take on broader responsibility for deployment, monitoring, and operational support, while operations teams participate earlier in design and architecture decisions. This is an organisational change that spans planning, architecture, testing, deployment, and customer support.
9. Not Following Through on Process Discipline
“Our worst habits are not defining requirements to the core, not following sprints, and not understanding delays in the dev cycle. We’ll be following an agile process and assigning time for feedback and suggestions from the right parties at the right stage in the project.”
Thomas Varghese, DevOps Manager, Day Translations
Speed pressure frequently causes teams to skip requirements definition, sprint ceremonies, and retrospectives — the very practices that make iteration sustainable. Underdefined requirements generate rework; skipped retrospectives allow recurring delays to go unanalysed. Building structured feedback time into every sprint protects long-term velocity even when it feels like overhead in the short term.
10. Failing to Secure the Entire Delivery Pipeline
“Secure the supply chain too. It’s not just about worrying that your product in production is secure from attack, but that the supply chain of third-party components and tools in the DevOps pipeline are also secure and deployed and maintained securely. Also, the idea of anti-fragility is important — not deploying systems that are incapable of breaking, but assuming they will, and even purposefully making them fail, so as to see how the system responds and self-heals. Think of Kubernetes autoscaling or auto-relaunching failed pods.”
William Henry, Open Source, DevOps, and Cloud Strategist, Red Hat
Production application security is well understood, but the build pipeline itself — source repositories, CI runners, artifact registries, third-party dependencies — represents an equally critical attack surface. Supply chain compromises can introduce malicious code before it ever reaches a security scanner that inspects production. Beyond hardening the pipeline, designing for anti-fragility means proactively testing failure scenarios (chaos engineering) so that self-healing mechanisms, such as container restarts or autoscaling, are proven to work before an incident forces the issue.
Key Takeaways
- Relevance over mimicry: Match your release cadence and tooling choices to actual business needs, not industry celebrity.
- Quality and speed together: Automated testing must accompany deployment automation or you are simply accelerating failures.
- Shift security left: Integrate security into every stage of development; do not treat it as a final checkpoint.
- Break silos deliberately: Cross-team collaboration requires explicit organisational effort, not just goodwill.
- Guardrails, not handcuffs: Set architectural standards where interoperability demands it; give teams autonomy elsewhere.
- Culture and process first, tools second: No tool alone constitutes a DevOps transformation.
- Distribute ownership: DevOps is an organisational model, not a job title or a team.
- Process discipline enables speed: Sprint ceremonies and requirement definition are investments, not overhead.
- Secure the supply chain: The delivery pipeline is as important a security boundary as the production environment.
- Design for anti-fragility: Assume components will fail; build and test the recovery mechanisms proactively.