This article is based on reporting originally published at searchcio.techtarget.com. Statistics cited reflect surveys conducted in 2015–2016 and should be treated as historical context rather than current benchmarks.
DevOps Has Moved Past the Hype Cycle
By the mid-2010s, DevOps had firmly established itself as a mainstream enterprise discipline rather than an emerging trend. Survey data from that period illustrated rapid adoption: the 2016 RightScale State of the Cloud survey reported that 74% of 1,060 IT professionals had adopted DevOps in their organizations, up from 66% in 2015. A separate Vanson Bourne report commissioned by Appvance found that 73% of 200 IT decision-makers had adopted some DevOps processes.
The compensation story was equally striking. Puppet’s 2016 DevOps Salary Report found that 58% of practitioners earned more than $100,000 annually—up from 47% the prior year—while 43% of managers exceeded $150,000, compared with just 26% in 2015.
This growth created intense demand for DevOps engineers and raised an important strategic question: how should an organization actually staff a DevOps transformation?
The Core Insight: It’s Not Build vs. Buy—It’s Build and Buy
A common instinct among CIOs is to treat DevOps adoption as a recruiting problem: find experienced DevOps engineers, hire them, and the transformation follows. IT staffing experts and analysts push back on this framing. You can’t build a DevOps environment simply by purchasing talent. Equally, you can’t retitle existing staff as “DevOps engineers” and expect the culture and practices to appear on their own.
James Stanger, senior director of products at CompTIA, framed it directly: “People who just want that trained DevOps person are kind of barking up the wrong tree. What they need are people who are in operations or development who have a willingness to learn about each other.”
The practical answer is a deliberate combination: hire externally for specific hard-to-build technical skills, then use those new hires to accelerate the upskilling of existing staff who bring irreplaceable organizational knowledge.
What DevOps Actually Requires
DevOps is a methodology—roughly a decade old at the time of the original reporting—in which software development and operations teams collaborate closely throughout the entire software lifecycle: building, testing, and releasing software frequently and in small increments. The goals are faster delivery, higher quality, and better security. DevOps depends on both cultural change and specific enabling technologies.
An organization adopting DevOps therefore needs two distinct types of capability:
- Collaborative mindset and cross-functional fluency: Developers who understand operations constraints, and operations engineers who understand the development lifecycle.
- Specific technical skills: Proficiency with the tools and platforms that make continuous delivery and infrastructure automation possible.
Where to Buy: Technical Skills That Are Hard to Build Quickly
Connor Leech, a senior technical recruiter at tech-staffing agency Mondo, identified the technical areas where external hiring typically makes the most sense. Organizations moving to DevOps commonly need people who can:
- Automate infrastructure provisioning and application deployment pipelines
- Design systems that automatically scale in response to demand fluctuations
- Work fluently with major cloud providers such as AWS
The specific tools and technologies that map to these needs include:
- Configuration management and automation: Puppet, Chef
- Application performance monitoring: New Relic
- Scripting and general-purpose programming languages: Python, Ruby, PHP
- Containerization: Docker (container runtime for packaging and deploying applications consistently across environments)
The reason external hiring makes sense here is pragmatic. These tools are complex, and hiring managers consistently want candidates who have used them in large production environments—not just experimented with them in sandboxes. Training existing staff to production-level proficiency in multiple platforms simultaneously is slow and risky when a transformation is underway.
“It’s definitely possible to retrain existing engineers in these areas, but because the tools are kind of complex, [CIOs] want people who have used them rather than have to teach people on them. It’s a common theme with hiring managers: They want someone who has not only played around with these, but have used them in a large production environment.”
— Connor Leech, Senior Technical Recruiter, Mondo
Using Contract Engineers as a Force Multiplier
One effective model is bringing in experienced DevOps engineers on short-term contracts—typically three to six months. These contractors come in, establish automation pipelines, define standards, and actively upskill the existing team. They are expensive, but they function as a force multiplier: when they leave, the permanent team is meaningfully more capable than it was before.
“What’s really common is bringing in DevOps engineers as contractors. You bring in people on contract for six months, and they come in, help automate and ramp everyone up and then go and do another contract. They’re generally pretty expensive, but they’re incredibly valuable. They can turn a company’s existing engineers into DevOps engineers.”
— Connor Leech, Mondo
Where to Build: Mindset and Organizational Knowledge
Technical skills are necessary but not sufficient. DevOps depends on a fundamentally collaborative way of working—the deliberate dismantling of the wall between development and operations. This requires a different kind of capability that is much harder to hire for and much easier to cultivate in existing staff.
Stanger identified the key characteristics of good internal DevOps candidates:
- Curiosity about the other side of the dev/ops divide, even if their primary expertise leans one way
- Familiarity with project management disciplines to keep iterative delivery cycles on track
- Comfort working within agile and Scrum frameworks, which are common structures in DevOps environments
- Willingness to share responsibilities that were previously siloed
Critically, Stanger argued that many existing IT professionals already possess the raw material for this. Developers have often had some exposure to operations concerns, and operations engineers frequently have development experience. The gap is not as wide as it might appear—what’s often missing is not knowledge but permission and encouragement to apply it.
“Many of the people who have been working in programming for years, if they have the right mentality, are already DevOps people. Anyone could easily be turned into that DevOps person. Most people have the seeds of DevOps in them, but the seeds haven’t been nurtured.”
— James Stanger, CompTIA
Why Existing Staff Are Not Optional
Jay Lyman, a principal analyst covering DevOps at 451 Research, reinforced this dual approach from an analyst’s perspective. Organizations need an infusion of new skills from external hires, but they also depend on the organizational context and institutional knowledge that existing staff carry. No external hire will understand the business’s specific systems, constraints, and history as well as a long-tenured internal engineer.
There is also a practical alignment benefit. IT professionals who understand that DevOps skills increase their market value are generally motivated to participate in training and upskilling programs. This makes change management easier—staff become advocates for the transformation rather than passive recipients of it.
The Leadership Imperative: Understand and Sell DevOps
Staffing strategy is only one part of the equation. CIOs and engineering leaders must themselves develop a genuine understanding of DevOps—not just at the conceptual level, but operationally. They need to be able to articulate what DevOps delivers for the business (speed, quality, reduced risk) and why it requires changes to how teams are structured and how work is measured.
Not all staff will embrace the transition. Some IT professionals are more comfortable in traditional, more sequential delivery models. This is not necessarily a problem—some projects and contexts do suit more structured, phased approaches. But organizations moving fully toward continuous delivery may eventually face a mismatch between those delivery expectations and staff who resist the required way of working. In those cases, external hiring may eventually be necessary not just to add skills but to replace resistance.
Summary: A Practical Staffing Framework
| Dimension | Buy (External Hire) | Build (Internal Development) |
|---|---|---|
| Technical tooling | Configuration management (Puppet, Chef), containers (Docker), cloud platforms, monitoring | Gradually, with coaching from experienced hires |
| Scripting/programming | When production-level proficiency is needed immediately | For staff who have foundational skills and willingness to deepen them |
| Cross-functional fluency | Less effective—culture cannot be hired in | Primary approach; identify staff already curious about both sides |
| Organizational knowledge | Cannot be bought; takes years to develop | Primary advantage of existing staff |
| Agile/Scrum practices | May need external coaching initially | Can be taught relatively quickly to motivated staff |
The organizations that successfully form a DevOps environment are those that resist the false choice between hiring and training. They hire deliberately and specifically for the hardest-to-build technical skills, use those new hires to accelerate team capability, and invest simultaneously in developing the collaborative mindset and cross-functional fluency that no job posting can deliver.