This article is based on a piece originally published on InformationWeek, authored by RJ Jainendra, VP and GM for ITBM and DevOps at ServiceNow.
The Challenge of Moving to DevOps
DevOps has matured significantly since it emerged roughly a decade ago as “Agile Operations” — a movement driven by sysadmins who needed to keep pace with product development teams shipping software at an increasingly rapid cadence. What began as a cultural push for collaboration between Development and Operations has grown into one of the defining organizational models in modern software engineering.
The core promise of DevOps is straightforward: when development, operations, security, QA, and product teams work in close coordination, software ships faster, with fewer defects, and problems in production are resolved more quickly. High-performing DevOps teams benefit from faster deployment cycles and significantly lower change failure rates compared to teams that operate in traditional silos.
Yet the transition is rarely smooth. It demands cultural change, process redesign, and investment in tooling — often simultaneously. Many engineering leaders find the execution far harder than the business case. If you are planning or mid-way through a DevOps transformation, the three steps below can help you avoid the most common traps.
Step 1: Set Manageable, Measurable Goals
The first rule of a DevOps transition is to start with a pilot program. Your immediate objective is not to replicate Netflix or Amazon overnight. Instead, treat the pilot as a controlled experiment: a sandbox where the team can iterate, occasionally fail, and learn without putting the entire organisation at risk.
Define a small set of goals that are directly tied to broader business objectives but are specific enough to be measurable and achievable within the pilot timeframe. For example:
- If the strategic objective is higher product quality, set a concrete target such as reducing the open defect backlog by 40% within the quarter.
- If the objective is faster time-to-market, aim to cut deployment lead time by a specific number of hours or days.
- If the objective is improved reliability, target a measurable reduction in mean time to recovery (MTTR) for production incidents.
Make sure every team member understands what the pilot is trying to achieve. Shared, clearly articulated goals reduce ambiguity, make it easier for people to self-organise, and provide a constructive frame of reference when things go wrong — which they will.
Step 2: Focus on People, Not Just Tools
DevOps is frequently discussed in terms of pipelines, containers, and automation toolchains. But the people dimension is where most transformations succeed or fail. Continuous delivery requires close, ongoing collaboration across developers, testers, UX designers, security specialists, product managers, and operations engineers — from initial design through to production support.
Define Roles Clearly Before Combining Them
A common early mistake is blurring role boundaries in the name of “full-stack ownership.” While cross-functional skills are the long-term goal, asking individuals to simultaneously carry developer and operations responsibilities before the team has matured is a reliable way to create bottlenecks. In practice, a developer stretched across both domains quickly becomes the single point of failure for everything.
In the early stages, give each person a clearly defined primary role. As the team builds muscle memory and the processes stabilise, it becomes natural — and productive — to expand individual ownership across the stack. Trying to shortcut that maturity curve typically backfires.
Address the Dev-Ops Culture Gap Directly
Development and Operations teams have a long history of assigning blame to each other when deployments fail or services degrade. This dynamic does not disappear simply because an organisation adopts a DevOps label. Meet it head-on from the start by establishing a culture of blameless post-mortems.
A well-run post-mortem focuses on systemic causes rather than individual fault, documents what was learned, and produces concrete action items. Over time, this practice shifts the team’s default response to failure from defensive blame to collaborative problem-solving — which is exactly the mindset DevOps requires.
Step 3: Market the Benefits and Celebrate Progress
A DevOps transformation is not a purely internal engineering exercise. Sustainable organisational change requires visible evidence of value — for the team doing the work, for stakeholders funding it, and for the broader organisation that will eventually adopt the model at scale.
Show Metrics, Not Just Anecdotes
When communicating progress to leadership or peer teams, lead with data. Track and surface specific metrics such as:
- Deployment frequency — how often you are releasing to production.
- Change failure rate — the percentage of releases that require a hotfix or rollback.
- Mean time to recovery (MTTR) — how quickly the team resolves production incidents.
- Lead time for changes — the elapsed time from a committed code change to it running in production.
These four metrics — popularised by the DORA (DevOps Research and Assessment) research programme — are widely used as benchmarks for DevOps performance. Tracking them consistently over time tells a far more compelling story than qualitative claims about improved velocity.
Amplify the Human Impact
Numbers resonate with technical audiences, but stories resonate with everyone else. Gather testimony from business stakeholders about how faster, more reliable releases are affecting their ability to serve customers. If you have customer-facing evidence of improvement, share it. Invite a senior leader to speak about the DevOps initiative during company-wide meetings — visible executive sponsorship signals organisational commitment and helps protect the programme during difficult stretches.
Celebrate milestones publicly, even small ones. Recognition motivates the team and reinforces the behaviours you want to scale across the organisation.
The Long View
DevOps transformation is not a project with a defined end date — it is a sustained shift in how an engineering organisation thinks about building, deploying, and operating software. The companies most often held up as examples of DevOps excellence did not get there through a single initiative. They built on incremental improvements, learned from failures, and maintained a culture of continuous delivery over years.
Starting with a well-scoped pilot, keeping role definitions clear, running blameless retrospectives, and measuring what matters gives your organisation the best foundation for making that journey successfully.
Original article by RJ Jainendra, VP and GM for ITBM and DevOps at ServiceNow, as published on InformationWeek. Jainendra has over 20 years of experience in technology, including senior product roles at Oracle and Electric Cloud, where he led product development for the ElectricFlow Deploy and Release platform. He holds an MS in Computer Science from the University of Wisconsin and a BS in Computer Science from Angelo State University.