This article is based on reporting originally published by InformationWeek, drawing on survey data from the Puppet 2016 State of DevOps Report, the RightScale 2017 State of the Cloud Report, a CA Technologies study titled “Accelerating Velocity and Customer Value with Agile and DevOps,” a Sauce Labs / Dimensional Research report titled “Testing Trends in 2017,” and the SDxCentral 2016 Cloud Automation and DevOps Report.
Why Getting DevOps Right Matters
DevOps adoption has grown substantially across organizations of all sizes, with a large proportion of enterprises and small-to-medium businesses reporting that they have adopted at least some DevOps practices. The promised benefits — greater agility, improved customer satisfaction, higher employee morale, and measurable business growth — make the approach attractive. But adoption alone does not guarantee results.
Survey data from Puppet’s State of DevOps research highlights a stark performance gap: high-performing DevOps teams deploy code far more frequently than low performers, recover from incidents significantly faster, and experience lower change failure rates. Workers at those high-performing organizations are also notably more likely to recommend their employer as a great place to work.
The CA Technologies study reported that organizations with more advanced DevOps practices saw meaningful improvements across IT costs, business growth, operational efficiency, application quality, employee productivity, customer experience, and talent retention — compared to less mature peers.
The difference between thriving and struggling frequently comes down to a handful of avoidable mistakes. Here are nine of the most common ones.
Mistake 1: Emphasizing Speed Over Quality
The primary draw of DevOps for many organizations is faster delivery. However, chasing speed while letting quality slip defeats the purpose. Releasing broken or poorly tested code faster simply accelerates the delivery of problems to production.
The antidote is shift-left testing — integrating testing as early in the development lifecycle as possible, ideally writing tests alongside code at the point of check-in. Despite widespread awareness of this practice, adoption remains low. The Sauce Labs / Dimensional Research “Testing Trends in 2017” report found that only 19% of development teams follow the best practice of writing tests when they check code in.
Key action: Treat test coverage as a first-class deliverable, not an afterthought. Make it a gate in your CI pipeline so that untested code cannot proceed.
Mistake 2: Deploying Too Infrequently
The flip side of the speed problem is not moving fast enough. Puppet’s research found that high-performing teams averaged roughly 1,460 deploys per year — multiple times per day — while low-performing teams might deploy as rarely as seven times per year. The resulting difference in lead times was orders of magnitude apart.
Infrequent deployments mean larger batch sizes, which in turn mean more risk per release, harder rollbacks, and longer feedback loops. Small, frequent releases are safer and easier to reason about.
Key action: Build a deployment pipeline that makes releasing small changes routine, safe, and boring — not an occasional high-stakes event.
Mistake 3: Staying Permanently in the Experimental Stage
Starting small with DevOps is sensible advice. Piloting the approach on a single team or project lets organizations learn without widespread disruption. The problem arises when the pilot never graduates into broader adoption.
RightScale’s 2017 data showed that only 30% of organizations had adopted DevOps company-wide. The Sauce Labs study put company-wide adoption even lower, at 10%. The CA Technologies research concluded that only around a third of businesses had achieved any real maturity in their DevOps practice — and that lack of maturity translated directly into higher costs, slower growth, and lower customer satisfaction.
Key action: Define a deliberate roadmap for expanding DevOps practices beyond the initial pilot. Set milestones for broader rollout and track them.
Mistake 4: Failing to Change the Culture
Tools and processes are the visible parts of DevOps transformation, but culture is the foundation. Without a genuine shift in how teams collaborate, share responsibility, and respond to failure, the tools will not deliver their potential.
In the CA Technologies survey, 34% of respondents identified organizational culture and mindset as too resistant to change, and 28% pointed to a lack of senior management commitment. Leadership must actively model the behaviors they want to see — a willingness to experiment, to learn from failure, and to break down silos between development and operations.
Key action: Treat blameless post-mortems, cross-functional collaboration, and shared on-call responsibilities as non-negotiable cultural practices, not optional extras.
Mistake 5: Moving Forward Without Sufficient Training and Expertise
Culture change requires capable people. DevOps tooling and practices have a real learning curve, and teams that lack the necessary skills will struggle to realize the benefits — or will adopt tools superficially without changing their underlying workflows.
The SDxCentral 2016 Cloud Automation and DevOps Report found that 68% of organizations not using DevOps tools attributed this to a lack of expertise. The CA Technologies study found that 32% cited inadequate in-house skills as a key obstacle to implementation.
Key action: Budget for formal training, internal knowledge sharing, and where necessary, bringing in experienced practitioners to accelerate the learning curve across the team.
Mistake 6: Relying on Manual Deployment Processes
Manual steps in deployment pipelines are a source of risk. A widely cited example is the 2012 Knight Capital incident, in which a manual software deployment to eight servers went wrong on one of them — reportedly because an employee missed a step. The resulting runaway automated trading caused losses of approximately $440 million and effectively destroyed the company’s stock value within hours.
Puppet’s research supports the case for automation, noting that the use of continuous delivery practices — including deployment automation, continuous integration, continuous testing, and version control for all production artifacts — predicted lower deployment pain, higher IT performance, and lower change failure rates.
Key action: Automate every repeatable step in your build, test, and deployment pipeline. Treat manual deployment steps as technical debt to be eliminated.
Mistake 7: Using the Wrong Tools — or No Tools at All
In the CA Technologies survey, 36% of respondents cited integrating the right tools and techniques as a major obstacle, and 35% pointed to tool availability as a problem. Tooling matters, but the relationship is more nuanced than simply buying a continuous deployment platform or adopting container technology.
The wrong tools — or tools that teams resist using — will not drive improvement. The best tool is one that fits the team’s actual workflow, integrates cleanly with the rest of the pipeline, and that practitioners understand well enough to maintain and extend.
Key action: Evaluate tools against your team’s specific requirements and existing stack. Involve the engineers who will use them day-to-day in the selection process.
Mistake 8: Allowing Too Many Long-Lived Branches
Teams transitioning from traditional waterfall environments often carry over the habit of working in long-lived feature branches. In a DevOps context, this creates integration problems, delays feedback, and makes continuous integration effectively impossible.
Puppet’s State of DevOps research identified trunk-based development practices as a meaningful contributor to high performance: specifically, branches or forks with lifetimes of less than a day before being merged into the trunk, fewer than three active branches in total, and daily merges into trunk or master.
Key action: Adopt trunk-based development or, at a minimum, enforce short-lived branch policies. Use feature flags to decouple code deployment from feature release rather than relying on long-running branches.
Mistake 9: Treating Security as an Afterthought
Security is consistently the top-cited obstacle to DevOps maturity. The CA Technologies survey found that security concerns were identified by 38% of respondents as their primary DevOps barrier. Yet Puppet’s research also found that high-performing DevOps teams spend significantly less time remediating security issues than low performers — suggesting that when security is integrated into the development process early, it becomes less of a burden, not more.
The emerging practice of DevSecOps addresses this directly, embedding security reviews, automated security testing, and policy enforcement into the CI/CD pipeline rather than layering them on at the end.
Key action: Shift security left alongside testing. Introduce static analysis, dependency vulnerability scanning, and infrastructure-as-code policy checks as automated pipeline stages from the start.
Summary: The Common Thread
Most of these nine mistakes share a common root: treating DevOps as a set of tools to deploy rather than a continuous improvement discipline that touches people, process, and technology equally. High-performing teams automate aggressively, release frequently, test early, keep branches short, integrate security throughout, and invest in the skills and culture that make all of it sustainable.
Avoiding these pitfalls will not happen overnight, but recognizing them is the necessary first step toward building a genuinely high-performing engineering organization.