DevOps is hard to roll out, hard to scale, hard to get everyone on board, and hard to sustain. Yet something must be approachable about it, or organizations would never start the journey at all. We gathered perspectives from seven practitioners and analysts — originally curated by TechTarget — on the parts of DevOps adoption that are genuinely within reach. Their answers converge on a surprising theme: the technology is usually the easy part.
1. You Can Start Slowly
Jeffrey Hammond, vice president and principal analyst, Forrester Research
“It’s easy to get started on the road to DevOps improvement by asking a very simple question: ‘If we changed one line of code in this application, how long would it take to get it into production using our normal processes and tools?’ Once you get that answer, ask: ‘Why? What’s the first easiest thing we can change to shorten this cycle?’ Then repeat that question each time to remove a roadblock, automate a manual process, or change a tool. The journey of 1,000 miles begins with a single step.”
Hammond’s approach is deliberately low-risk. You do not need a transformation programme, a new org chart, or executive sponsorship to ask one diagnostic question. Measuring your current lead time — even informally — creates a baseline that makes every improvement visible and defensible.
2. Technology Is Your Friend
Matthew Heusser, managing consultant, Excelon Development
“Usually, putting a basic CI harness in place and an automated deploy system is relatively easy. It’s the people, culture, and risk-management pieces that are hard.”
Heusser’s point is frequently validated in practice. Tools such as Jenkins, GitLab CI, GitHub Actions, or CircleCI can be configured to run a build and test suite within hours. Automated deployment to a staging environment adds a day or two of work at most. These wins are concrete, measurable, and do not require anyone to change their professional identity — which is why teams reach for tooling first.
3. DevOps Can Be an Easy Sell to Management
Torsten Volk, senior analyst, Enterprise Management Associates
“The perspective of freeing up a large share of the approximately 30% of developers and operators absorbed by constant release preparations makes it at least easy for management to motivate staff to adopt DevOps. Additional motivation for both operators and developers is that they get to work with leading-edge technologies that will look good on their résumés, and that their entire group will become much closer to the business.”
The business case for DevOps tends to write itself once you quantify release overhead. Automating repetitive release work frees engineering time for feature development. That argument resonates with finance and leadership alike, giving teams an easier path to budget and organisational support.
Note: The “approximately 30%” figure quoted by Volk is an analyst estimate, not a universally verified benchmark. Your organisation’s overhead will vary depending on release cadence, team size, and existing automation maturity.
4. Is the DevOps Process Really That Hard?
Theresa Neate, test consultant and quality analyst
“I beg to differ that everyone says or even thinks that the DevOps process is hard. But if anything is ‘easier’ than the rest, it is likely the tooling — that includes all forms of automation. Tooling is one of the first things teams implement when doing transformations to the DevOps way of life, because it is not only more visible than some other changes, but also because technology solutions are mostly easier than process and people solutions. As DevOps is, in reality, ‘Agile infrastructure,’ I do need to remind readers that this Agile tenet still holds true: ‘Individuals and interactions over processes and tools.’ So yes, the tools might be easier, but we still need to address processes and especially individuals and interactions in our DevOps transformations.”
Neate’s pushback is worth taking seriously. Teams that treat DevOps as a tooling exercise — installing a CI server and calling it done — often stall once they hit the first cross-team coordination problem. The Agile Manifesto’s emphasis on people over tools applies just as much in an infrastructure context as in software development.
5. Easy to Begin, Hard to Continue
Bob Reselman, developer, system architect, and columnist
“Yes, agreeing to commit to working and growing in the DevOps paradigm is pretty easy. Actually doing the ongoing work required to meet the commitment is a lot harder, particularly as external forces pressure teams to incur technical debt in order to meet short-term goals and quarterly profits.”
Reselman identifies one of the most common failure modes: DevOps enthusiasm fades under delivery pressure. When a deadline looms, the manual workaround feels faster than maintaining the pipeline. Over time, those shortcuts accumulate into the same fragile, hand-cranked release process that DevOps was meant to replace. Sustaining DevOps practices requires deliberate investment — protected time for pipeline maintenance, blameless post-mortems, and a culture that treats automation as a first-class deliverable.
6. The Cloud Lowers the Entry Barrier
Gordon Haff, technology evangelist, Red Hat
“Technology is easy. It’s people who are hard. Integrated container-as-a-service and platform-as-a-service cloud services may not give you something tailored to your exact production requirements out of the box. But they can give you a surprisingly easy on-ramp to development environments, build tools, monitoring, and other tooling that’s ideal for DevOps workflows and cloud-native app development. You can fine-tune later, but get started surprisingly quickly.”
Managed cloud platforms — whether that means AWS CodePipeline, Azure DevOps, Google Cloud Build, or an OpenShift cluster — package up the infrastructure concerns that used to consume weeks of setup time. Teams can have a working CI/CD loop and ephemeral environments running in a day. That speed of experimentation removes one of the most common excuses for not starting.
7. Win Hearts and Minds First
Rob Lambert, owner and founder, Cultivated Management
“DevOps is essentially bringing together people from potentially different teams, with different skills, to enable a more seamless and friction-free delivery of value to production. At a technical level, it’s often a challenge, but not something a group of like-minded, talented people cannot solve. The technical challenge, for some people, can be reasonably straightforward and really engaging. One of the hardest aspects of DevOps can be influencing hearts and minds about this new change, especially in environments where the roles of dev and ops have traditionally been separate. Of course, if you don’t have hearts and minds to influence around a new change, then the journey will be all the smoother and, in some cases, reasonably easy.”
Lambert’s observation reframes the difficulty: in a greenfield team, or one with no entrenched silos, DevOps can feel almost natural. The hard cases are organisations with long-standing cultural divisions between development and operations — where each side has different incentives, metrics, and professional identities. In those environments, no tool will substitute for patient, sustained work on relationships and shared goals.
Key Takeaways
- Start with a diagnostic question. Measure how long it takes to push one line of code to production today, then remove the first obstacle.
- The tooling is genuinely the easy part. A basic CI pipeline and automated deployment can be operational within days using modern managed services or open-source tooling.
- Sell the business case with time savings. Quantify how much engineering time is currently consumed by manual release work and use that to justify the investment.
- Don’t mistake tooling for transformation. Automation without culture change addresses symptoms, not causes.
- Plan for sustainability, not just launch. Protect time for pipeline maintenance and resist the pressure to take manual shortcuts under deadline pressure.
- Cloud platforms dramatically lower the barrier to entry. Use managed CI/CD and container platforms to get a working DevOps loop running quickly, then customise as you learn.
- Invest in people as much as pipelines. The hardest and most durable work in a DevOps transformation is cultural — shared ownership, psychological safety, and cross-functional collaboration.
Original expert perspectives sourced from TechTarget. Analyst roles and affiliations reflect the original publication date of April 2018.