This article is based on a case study originally published by TechTarget, featuring the consulting firm Sodo (Ship On Day One) and their approach to DevOps adoption.
The Real Problem: Culture, Not Tools
When organizations ask how to start with DevOps, the instinct is often to reach for tools — adopt containers, migrate to the cloud, stand up a CI/CD pipeline. But according to Eric Schoonover and Robert Duffy, co-founders of the consultancy Sodo (Ship On Day One), that instinct misses the deeper issue.
Duffy, who brings experience from Amazon and Time magazine, and Schoonover, who has worked at Microsoft, Netflix, and the U.S. Department of Defense’s Digital Service, argue that the cultural transformation is the hard part — and the part most organizations underestimate.
“A lot of companies are still doing engineering delivery like 1800s manufacturing was done. It’s a craft-based system, parsing work out to different teams. We want to help non-tech companies think about the cultural transformation. It’s not just about moving to the cloud and installing Docker.”
— Robert Duffy, co-founder, Sodo
Notably, Duffy points out that neither he nor Schoonover used the term “DevOps” during their time at Amazon and Netflix. The practices were simply how software engineering was done. That framing is useful: DevOps is not a product you install, but a set of behaviors and capabilities that high-performing teams exhibit naturally.
Small Plans Work Best: The 15-Capability Framework
To create a repeatable starting point, Duffy and Schoonover interviewed approximately 150 high-performing software development teams, documenting observations and patterns. From that research, they distilled their findings into 15 capabilities, each broken into four stages of maturity.
The goal of this structure is deliberate: avoid overwhelming the organization. Instead of presenting a sweeping transformation roadmap, the framework identifies the highest-priority items and sequences them so that early wins build credibility with business stakeholders.
“We try to get to a small set of very actionable items that we helped select that justify the ROI calculations and case studies. We help companies recognize the size of the problem and attack it in small identified chunks to gain credibility with the business.”
— Robert Duffy, co-founder, Sodo
This approach mirrors advice found throughout DevOps literature: start with a value stream mapping exercise, identify bottlenecks, pick one constraint to improve, and demonstrate measurable progress before expanding scope. The specifics of Sodo’s 15 capabilities were not publicly detailed in the original source, but the principle — narrow focus, visible momentum — is well-established in DevOps practice.
Key Principles for Starting a DevOps Transformation
Whether you engage external consultants or pursue transformation internally, the following principles reflect what high-performing teams consistently do:
- Start with culture, then process, then tools. Technology is the easiest part to change. Organizational habits and incentive structures are the hard part.
- Identify your value stream. Understand how work flows from idea to production, and where it gets stuck. This surfaces the highest-leverage improvement opportunities.
- Pick small, visible wins first. Early successes build trust with leadership and reduce resistance from skeptical engineers. Don’t attempt to transform everything at once.
- Make CI/CD a baseline expectation. Continuous integration and continuous delivery pipelines are not optional extras — they are the foundation that enables everything else, including fast feedback and safe deployments.
- Treat legacy systems as a continuum. Not every system is equally amenable to DevOps practices. Some will adopt CI/CD quickly; others, particularly those involving custom hardware or highly regulated environments, require more time and creative approaches. Acknowledge this spectrum explicitly rather than pretending all workloads are equal.
- Ship something. The discipline of getting working software out the door — even incrementally — creates real feedback loops and real learning. “Something shipped out the door is really what we preach,” Duffy said.
DevOps in Non-Traditional Environments: The Legacy and Defense Context
One of the more instructive aspects of the Sodo case study involves a defense contractor — an environment about as far from a Silicon Valley startup as possible. A senior engineering manager at that organization described the challenge plainly: the organization wanted a consistent software delivery process across all systems, but the range of environments was enormous, from straightforward web applications to custom hardware with deeply embedded software.
“We want to look at software development as a continuum. But at one spectrum, we have the low-hanging fruit that it’s easy to see how to make changes to, and on the other spectrum we have custom hardware and software that is not low-hanging fruit. We want to have the same kind of systems in place for both so that we can have CI and CD running. That’s the area we’re a little concerned about.”
— Senior engineering manager, defense contractor (anonymous)
This is a real and common challenge. Organizations in aerospace, defense, financial services, healthcare, and manufacturing all face legacy systems that resist easy automation. The practical answer is not to exclude those systems from DevOps thinking, but to apply the same principles at whatever pace and with whatever constraints the system imposes — while capturing quick wins on the more flexible parts of the portfolio.
The same manager noted that the Sodo team’s willingness to work alongside engineers — rather than simply diagnosing problems and leaving — was a key factor in acceptance. Engineers, who are often skeptical of outside consultants, responded positively precisely because the consultants did not arrive claiming to have all the answers.
The Role of External Help: When Consultants Make Sense
Bringing in external consultants to help start a DevOps transformation is not the only option, but it is a legitimate one — particularly for organizations where internal advocates lack the organizational authority or cross-functional visibility to drive change on their own.
The value a good DevOps consultancy brings is not primarily technical knowledge (your engineers likely already know what CI/CD pipelines and infrastructure-as-code are). The value is in:
- Providing an outside perspective that internal politics cannot easily dismiss
- Translating engineering improvements into business ROI language that resonates with executives
- Offering a structured, repeatable approach that prevents the team from getting lost in tool debates
- Creating accountability and momentum through regular check-ins and visible milestones
The Sodo team explicitly declined to simply deliver projects for clients. Their stated focus was on teaching organizations how to sustain DevOps practices independently — which is the right model. A transformation that depends indefinitely on external consultants is not a transformation.
Patience and Momentum Are Both Required
Duffy’s framing of “patience is important, but so is momentum” captures a genuine tension in DevOps transformations. Moving too fast burns out teams and produces fragile systems. Moving too slowly allows organizational inertia to kill the initiative before it gains traction.
The practical resolution is to run a short, focused pilot — a single team, a single service, a single pipeline — and make that work well before expanding. Document what changed, measure the outcome, and use that story to justify the next step. This is the pattern that works in organizations of all sizes and industries.
DevOps is not a destination you reach; it is a direction you move in. The question of how to start matters less than the decision to start — and the discipline to keep going.
Original reporting by TechTarget. This article summarizes and expands on the source material for a DevOps engineering audience.