This article draws on an interview with Moshe Kranc, CTO of Ness Digital Engineering, originally published on ZDNet (2017).
The Business Already Wants DevOps—But Doesn’t Fully Understand It
Ask most enterprise technology leaders about DevOps adoption and the conversation rarely starts with resistance. According to Moshe Kranc, CTO of custom software development firm Ness Digital Engineering, the demand is already there—especially from the business side of organisations.
“I meet with a lot of customers and I hear from them a lot about DevOps,” Kranc told ZDNet. “It’s not something I need to sell them. They have read about it, there are all kinds of statistics out there on the web about how it reduces deployment time from seven days to a half a day, reduces incident volume by a factor of twenty, and other amazing improvements that any company would want.”
The business case is compelling, and decision-makers are aware of it—often because they are watching competitors move faster. But awareness of DevOps benefits is not the same as understanding what DevOps actually requires. That gap is where many transformations stall.
Culture Is the Starting Point, Not an Afterthought
Kranc is direct about the limits of recommending a DevOps approach without proper preparation: “I can’t recommend a DevOps approach to every customer because it requires that you have done a decent amount of homework beforehand. You have to do a lot of groundwork in your organisation to implement DevOps.”
That groundwork is primarily cultural, not technical. The process starts with breaking down organisational silos—the longstanding divisions between development teams (who write code) and operations teams (who deploy and maintain it). Those groups have historically operated with different goals, different metrics, and different incentives. Developers are rewarded for shipping new features quickly; operations teams are rewarded for maintaining stability. Without alignment at the cultural level, introducing CI/CD pipelines or infrastructure-as-code tooling simply adds friction to an already dysfunctional relationship.
“That process starts with the culture—breaking down silos, changing attitudes, and so on. Helping Dev and Ops to work together. Breaking down those walls between engineers is a process that takes time. That’s the hard part.”
What “Cultural Change” Actually Means in Practice
Cultural change is one of the most overused phrases in technology transformation discussions, but in a DevOps context it has concrete, operational meaning. It typically involves:
- Shared ownership of the delivery pipeline. Developers take responsibility for the operational characteristics of their code—monitoring, alerting, on-call rotations. Operations engineers contribute earlier in the development cycle, informing architecture and deployment design.
- Blameless post-mortems. When incidents occur, the focus shifts from assigning blame to understanding systemic causes. This requires psychological safety, which is itself a cultural property.
- Cross-functional teams. Rather than handoffs between separate Dev and Ops departments, teams are structured so that the skills needed to build and run a service sit in the same group.
- Continuous feedback loops. Metrics from production—latency, error rates, deployment frequency—are visible to everyone and used to drive ongoing improvement, not just reactive firefighting.
- Leadership alignment. None of the above is sustainable if senior leadership continues to reward the old behaviour. Cultural change requires explicit endorsement and role-modelling from the top down.
Why the Business Side Pushing DevOps Can Be Both an Asset and a Risk
Kranc’s observation that it is “usually the business side that is pushing” DevOps is worth examining carefully. Business sponsorship is genuinely valuable—it provides budget, removes political blockers, and signals organisational priority. But business-driven DevOps initiatives carry a specific failure mode: the pressure to show quick results can lead organisations to invest in tooling without completing the slower, harder work of cultural alignment.
An organisation that deploys a new CI/CD platform while leaving Dev and Ops in separate reporting structures with separate KPIs has not adopted DevOps. It has adopted a deployment tool. The efficiency gains will be marginal, and the investment will be difficult to justify in retrospect.
Helping business stakeholders understand that DevOps is a process—not a product—is one of the most important conversations a practitioner or consultant can have early in an engagement.
The Groundwork That Has to Happen First
Before any tooling decisions are made, organisations benefit from conducting an honest audit of their current state. Key questions include:
- How long does it currently take to go from a committed code change to production? Where are the bottlenecks?
- Who is responsible when a production incident occurs, and what happens next?
- Do development and operations teams share any common metrics or goals?
- Is there a culture of blame, or a culture of learning from failure?
- Does leadership understand and actively support the change that will be required?
The answers shape a realistic change programme. Organisations that score well on the cultural dimensions are ready to accelerate with automation and tooling. Organisations that do not need to invest in the people and process work first—and that takes time.
The Long View
Kranc started his career working on Arpanet in the 1970s. The perspective that comes with that kind of experience is relevant here: transformations that matter take time. DevOps is not a sprint. Organisations that treat it as one—launching a “DevOps initiative” with a six-month timeline and a tooling budget—typically achieve modest, short-lived gains.
The organisations that achieve durable improvements are those that commit to the slower work of changing how people think about their roles, their relationships with colleagues, and their shared responsibility for what ships to customers. That is the culture work. And it is, as Kranc puts it plainly, the hard part.