This article is based on analysis originally published on TechTarget.com.
The Culture vs. Technology Debate Has Run Its Course
When DevOps first emerged as a concept, many engineers assumed it was a passing trend — another buzzword destined to fade as quickly as it arrived. More than a decade of sustained industry conversation has proven that assumption wrong. DevOps is not a fashion; it is a structural shift in how software is built, tested, released, and maintained.
Yet widespread adoption remains uneven. Organisations like Google, Amazon, Facebook, and Netflix are routinely cited as high-performing examples. Many others continue to struggle. The barriers range from team size and organisational politics to budget constraints and deeply entrenched ways of working. But one underappreciated obstacle is conceptual: the persistent belief that DevOps is, at its core, a culture.
Calling DevOps a culture is not wrong. But it is incomplete — and that incompleteness has real consequences for how teams try to adopt it.
Why Reducing DevOps to Culture Causes Problems
When organisations focus exclusively on culture, they tend to undervalue the tools, automation pipelines, and technical practices that make DevOps work in practice. Continuous integration, continuous delivery, infrastructure as code, observability — these are not nice-to-haves layered on top of a cultural shift. They are the mechanisms through which cultural change becomes observable and measurable.
The opposite failure mode is equally common. Teams that focus only on tooling — standing up a CI/CD pipeline without addressing communication norms or shared ownership — find that the technology alone does not produce the outcomes they expected.
The result is a fruitless binary: DevOps is a culture versus DevOps is a technology. Neither camp is fully right, and debating the framing consumes energy that could be spent on actual improvement.
What the Facebook Analogy Reveals
A useful way to think about this is to look at the history of social networks. Facebook and Twitter fundamentally changed how people communicate globally. MySpace, despite being an earlier entrant in the same space, did not achieve the same lasting impact.
The reason is not purely technological and not purely cultural. Facebook succeeded because the product was designed in a way that aligned with how people naturally want to connect and share. The technology was inseparable from the behaviour it enabled. Neither the platform nor the social habits it created can be understood in isolation.
DevOps works the same way. Culture and tooling are not competing explanations — they are co-dependent forces. The question is not which one matters more. The question is how to structure their interaction so that adoption is practical, measurable, and sustainable.
DevOps Adoption Is Growing — But Slowly
The annual State of DevOps Reports, produced by Puppet in partnership with the DevOps Research and Assessment (DORA) team, tracked self-reported DevOps team membership over several years. According to the 2017 edition of that report, the figures looked like this:
- 2014: 16% of respondents identified as working in a DevOps team.
- 2015: 19% of respondents identified as working in a DevOps team.
- 2016: 22% of respondents identified as working in a DevOps team.
- 2017: 27% of respondents identified as working in a DevOps team.
Importantly, the same report noted that 90% of those DevOps teams were operating within medium- or high-performing IT organisations. Despite the well-documented risk of DevOps silos — where a dedicated DevOps team inadvertently becomes another handoff boundary — the data suggests that structured DevOps adoption correlates strongly with better overall IT performance.
Growth from 16% to 27% over three years is meaningful, but it also reveals how much room for improvement remains. The culture framing, on its own, has not been sufficient to accelerate that pace.
The Case for a Standards-Based Approach
A more productive frame for DevOps is to treat it as a transformation process and a collaboration philosophy — one that benefits from concrete, shared standards rather than aspirational cultural statements.
Standards serve several functions that culture alone cannot:
- They are technology-agnostic. A well-written standard applies regardless of whether your stack runs on Kubernetes or bare metal, whether your team uses GitHub Actions or Jenkins.
- They are team-size-independent. A five-person startup and a five-hundred-person enterprise can both work toward the same deployment frequency or change failure rate targets.
- They create shared language. Standards give developers, operations engineers, security teams, and business stakeholders a common vocabulary for evaluating progress.
- They support iteration. Standards can be adopted incrementally, refined based on feedback, and updated as the industry evolves — much like software itself.
Rather than framing DevOps adoption as an all-or-nothing cultural transformation, organisations can decompose it into specific, measurable objectives. This reduces the risk of paralysis in conservative environments and gives teams something concrete to work toward.
Existing Standards Worth Studying
Several established frameworks already demonstrate what standards-based thinking looks like in practice:
- The Twelve-Factor App methodology provides a set of principles for building software-as-a-service applications that are portable, scalable, and operationally sound. Its twelve factors — covering configuration management, dependency isolation, logging, and more — are concrete enough to audit and adopt incrementally.
- Cloud Native principles, as promoted by the Cloud Native Computing Foundation (CNCF), define how applications should be architected to take advantage of modern infrastructure. These include containerisation, dynamic orchestration, and microservices design.
- Consortium for IT Software Quality (CISQ) standards provide automated measures of software quality based on structural characteristics such as reliability, security, performance efficiency, and maintainability.
None of these frameworks requires an organisation to first achieve a particular culture before they become applicable. They offer entry points that teams can use from wherever they are today.
Start Where Your Teams Are
The most effective DevOps adoption paths are not the ones that most closely match a textbook definition. They are the ones that begin with an honest assessment of current practices and introduce targeted improvements in manageable increments.
This means resisting the temptation to impose a single model wholesale. It means identifying the friction points between developers and operations — handoff delays, environment inconsistencies, manual deployment steps — and addressing them with specific, standard practices rather than broad cultural mandates.
Standards create the conditions in which cultural change becomes possible. When teams share tools, processes, and expectations, collaborative habits tend to follow. The culture does not have to come first; in many cases, it emerges as a consequence of working within well-designed systems.
Key Takeaways
- DevOps is neither purely a culture nor purely a technology — both are necessary, but neither is sufficient on its own.
- The culture-first framing can lead to vague aspirations that are difficult to measure or act on, particularly in large or conservative organisations.
- A standards-based approach gives teams concrete, technology-agnostic goals that can be adopted incrementally and refined over time.
- Existing frameworks such as the Twelve-Factor App, Cloud Native principles, and CISQ standards offer practical starting points.
- Successful adoption begins from where your teams are today — not from where a definition says they should be.