This article draws on perspectives shared by Viktor Farcic in DevOps Paradox, a book in which Farcic interviews industry colleagues about what DevOps means to them in practice. The original source was attributed to gotechdaily.com.
The Definitional Problem at the Heart of DevOps
Ask ten engineers what DevOps is and you will likely get ten different answers. That ambiguity is not a sign of immaturity in the field — according to Viktor Farcic, it is baked into the nature of DevOps itself. Farcic, a long-time DevOps practitioner and author, explores this tension at length in DevOps Paradox, a book structured as a series of candid conversations with practitioners across the industry.
The core irony is pointed: DevOps exists to bring order and collaboration to the chaotic, siloed world of software delivery — yet it cannot agree on what it actually is.
What DevOps Actually Is, According to Farcic
Farcic’s answer to “What is DevOps?” is deliberately minimal:
“Almost everyone gives a different answer to the question ‘What is DevOps?’ — there is a big discrepancy between the idea and the implementation. In my opinion, the main goal of DevOps is to enable self-sufficient, product-oriented teams that are able to take complete control of their products.”
Viktor Farcic, DevOps Paradox
The traditional software delivery model fragments an application’s lifecycle across isolated groups: business analysts define requirements, architects set guidelines, developers write code, testers validate it, and operations teams release it. Each group belongs to a different department with different — and often competing — incentives. Collaboration suffers because teams optimise for their own departmental goals rather than a shared product outcome.
DevOps, in Farcic’s framing, attempts to replace that structure with cross-functional, product-oriented teams that own the entire application lifecycle and report through a single line of accountability. The goal is collective ownership and empathy — not a prescribed workflow.
DevOps Is Neither a Process Nor a Technology Stack
A common misconception is that adopting certain tools — CI/CD pipelines, container orchestration, infrastructure-as-code — makes an organisation “DevOps.” Farcic pushes back on this directly:
“DevOps is neither [a process nor a set of technologies]. There is no prescribed process that has to be followed. Likewise, there is no technology that we can adopt to transform ourselves into ‘DevOps’ teams. It’s just an idea that developers, operators, and everyone else have to work together instead of being isolated in different silos.”
Viktor Farcic, DevOps Paradox
That does not mean tooling is irrelevant. Farcic makes a subtler point: every technology reflects the culture and processes of the team that built it. If an organisation adopts a tool that does not align with its own culture and processes, results will be sub-optimal at best. Teams must either choose technologies that fit their existing culture or use technology deliberately as a lever to shift that culture. Neither element can be ignored in isolation.
Does the “DevOps Engineer” Role Actually Exist?
The job title “DevOps Engineer” has become ubiquitous on job boards and org charts. Farcic is sceptical of what it usually represents:
“I don’t think there is such a thing as a ‘DevOps Engineer.’ The term was invented by people who were unwilling to apply the changes that DevOps leads to. Most of the time, a ‘DevOps Engineer’ is just another name for someone who works in shared services, operations, or infrastructure — in the department that was simply the first to be renamed DevOps.”
Viktor Farcic, DevOps Paradox
This is a provocative but coherent observation. If DevOps is about dissolving silos between development and operations, creating a dedicated “DevOps team” simply adds a new silo — one responsible for automation and pipelines — without changing the underlying organisational dynamics.
Is DevOps Experiencing an Identity Crisis?
Given how widely DevOps is misunderstood and misapplied, it is reasonable to ask whether it is in an identity crisis. Farcic’s answer is that it cannot be, because it never had a fixed identity to begin with:
“No one has defined the process behind DevOps. There are no steps that need to be followed daily or weekly. It’s just an idea that we should work together and not throw things over the walls of the department. The way there is therefore open to interpretation. DevOps never had a clear identity, so there can be no identity crisis.”
Viktor Farcic, DevOps Paradox
Compare this to Agile, which — despite being a set of values and principles — spawned concrete frameworks like Scrum with clearly defined ceremonies, roles, and artefacts. DevOps produced no equivalent. That openness is both its strength (adaptable to many contexts) and its weakness (easy to co-opt or dilute).
The Biggest Challenges Facing DevOps Today
Farcic identifies the core challenges as cultural and organisational rather than technical:
- Cosmetic rebranding: Companies rename existing departments — shared services, infrastructure, operations — as “DevOps teams” without changing how they work. The label changes; the silos do not.
- Middle management resistance: True DevOps reorganisation flattens hierarchies and eliminates some managerial layers. Those whose authority depends on the current structure have strong incentives to resist.
- Expertise and identity threat: Engineers who have spent years specialising in one domain — operations, QA, networking — can feel that a cross-functional model devalues their career path and credentials.
These are not technical problems that can be solved by deploying a new tool. They require deliberate organisational design, executive sponsorship, and a willingness to disrupt existing power structures.
About DevOps Paradox
Farcic conceived DevOps Paradox after noticing that the most valuable conversations at conferences happen informally — in hallways, at dinners, between sessions — rather than in planned talks. He wanted to capture that unstructured, exploratory dialogue and make it accessible to practitioners who cannot attend conferences in person.
“I had no real goals for this book other than talking to people about any subject as long as it was DevOps related. I have not prepared any questions in advance. Instead, I only brought together people I would want to speak to if I met them at a conference.”
Viktor Farcic, DevOps Paradox
The result is a deliberately diverse collection of viewpoints: interviewees from large enterprises and startups, veterans and emerging practitioners, friends and first-time acquaintances. The breadth is intentional — Farcic wanted conflicting opinions, not a unified manifesto.
Key Takeaways for DevOps Practitioners
- DevOps is an idea, not a framework. There is no canonical process to implement. Each organisation must define what collaboration across the software lifecycle looks like for its specific context.
- Tooling follows culture. Adopting DevOps tools without addressing organisational culture produces marginal improvements at best. Culture and process must evolve together with the technology.
- “DevOps team” is often a misnomer. A team called DevOps that sits between development and operations may simply be a rebranded operations team. True DevOps thinking embeds operational responsibility into product teams.
- The hard problems are human. Resistance from middle management and specialists whose identity is tied to the old structure are the primary barriers to DevOps adoption — not tool selection or pipeline design.