This article is based on perspectives originally summarized from IT Business Edge. Named individuals and their affiliated organizations are attributed as reported in the source material.
DevOps Is About People, Not Just Tools
Much of the conversation around DevOps centres on the tools, technologies, and platforms that help teams deliver software faster and more reliably. CI/CD pipelines, infrastructure-as-code, container orchestration — these dominate the conference circuit and vendor marketing. But at its core, DevOps is about getting people to work together more effectively and efficiently.
That shift is harder than it sounds. DevOps replaces the linear, stage-gated waterfall model with a continuous, iterative workflow. Releases are frequent, priorities change quickly, and the idea of a “finished” product gives way to ongoing delivery. In this environment, coordination between teams cannot be an afterthought — it has to be built into the culture from the start.
Collaboration as a First-Class Concern
Some leading DevOps practitioners argue that collaboration deserves equal standing alongside automation and scale when designing working environments. The analogy offered by BMC’s Chris Scruggs is instructive: just as an orchestrated piece of music creates order out of chaos by coordinating the role of each individual note, collaboration ensures that each step in a complex application lifecycle serves the broader business goal.
Even a seemingly straightforward task — migrating a legacy application to the cloud — requires tight coordination between multiple systems, platforms, and managers across different teams. Without deliberate collaboration, that coordination breaks down at the seams between groups.
The Concept of Ba: A Framework for Collaborative Culture
Uniting cross-functional teams — each with its own priorities, histories, and ingrained problem-solving approaches — is arguably the most difficult challenge in building a DevOps culture. Success is rarely total, in part because organisations rarely define what success actually looks like.
CA Technologies’ Mick Adcock advocates building collaboration around the Japanese philosophical concept of ba — loosely translated as a shared space for emerging relationships. Applied to DevOps, this philosophy emphasises:
- Trust between individuals and teams
- Knowledge sharing across functional boundaries
- Cross-pollination of ideas and practices between development, operations, QA, and the business
- Treating the business itself as the system being developed, rather than just the software
- A culture that encourages shared responsibility and experimentation
This framing moves the conversation away from org-chart restructuring and toward building the kinds of relationships and trust that enable genuine collaboration over time.
BizDevOps: Bridging the Business–IT Gap
Collaboration is not just a DevOps concern — it is often the deciding factor in whether any IT project succeeds. According to IDC estimates cited in the source material, roughly one-third of all IT projects fail outright, with many more salvaged only through significant additional effort.
A key cause of failure is the disconnect between what the business expects and what development and operations can realistically deliver. Mendix technology evangelist Nick Ford argues that closing this gap — by genuinely bringing business stakeholders into the delivery process — is one of the most impactful things an organisation can do. He refers to this as BizDevOps: an extension of DevOps that explicitly includes business teams as active participants rather than downstream consumers of software.
In practice, this means:
- Business stakeholders participate in sprint planning and backlog prioritisation
- Product owners translate business requirements into actionable development work
- Teams share visibility into deployment pipelines and production metrics
- Feedback loops connect end-user behaviour directly back to development priorities
Why Tooling Alone Won’t Fix Collaboration Problems
One of the biggest risks in any DevOps transformation is treating it as a magic bullet — the assumption that deploying the right tools will automatically dissolve long-standing friction between teams. Patrick Turner, CTO of technology consulting firm Small Footprint, warns that the deep-rooted conflicts between development, testing, QA, and operations often persist even after advanced collaboration platforms are in place.
Standardising collaborative practices helps, but it is not sufficient if standardisation leads to stasis or redundant process. The spirit of DevOps is to continuously pursue better ways of working — which sometimes means deliberately challenging established norms, not just codifying them in a new format.
Collaboration Cannot Be Fully Measured — But It Can Be Cultivated
Unlike deployment frequency or mean time to recovery, collaboration resists direct measurement. You cannot put a number on the quality of a conversation between a developer and an operations engineer, or quantify the degree of trust between a product team and its business stakeholders. Satisfaction surveys among team members, users, and stakeholders can offer a proxy, but they are inherently limited.
What is clear is that DevOps does not work effectively without it. The tools enable the process; the culture sustains it. The most technically sophisticated pipeline in the world will underperform if the people running it are working in silos, protecting their own domains, or communicating defensively.
The difference between teams that talk to one another and teams that talk at one another is not a small one. It is often the difference between a DevOps transformation that delivers real business value and one that simply rearranges the org chart while leaving the same underlying friction in place.
Key Takeaways
- DevOps is fundamentally a people and culture challenge, not just a tooling challenge.
- Collaboration should be treated with the same strategic importance as automation and scale.
- Frameworks like ba offer a principled way to build trust and knowledge-sharing across teams.
- BizDevOps — including business stakeholders as active participants — addresses one of the most common causes of project failure.
- Tools support collaboration but cannot replace the cultural conditions that make it genuine.
- Continuous improvement requires deliberately questioning established norms, not just standardising them.