The relationship—for lack of a better word—between developers and operations engineers, is more important than many businesses are aware. High-performing teams seem to operate in an easy, DevOps bliss, but for many enterprises, forging new connections to deliver the promise of DevOps ends in frustration and squabbling.

Even the basics, like creating and maintaining useful feedback loops between teams, requires changing attitudes of staff across the organisation. And the requirement for human enlightenment, not simply a yet another technology refresh, is the most critical and overlooked barrier to DevOps success. It’s anathema. We’ve built a world conditioned to seek technical “fixes” first.

The rise in the popularity of DevOps creates excitement—then concern—in boardrooms across enterprises, who hear the hype and fret they’ll fall behind the competition if they don’t embrace this new way of working. Leadership teams the world over have called shotgun weddings between developer and operational teams, many of whom had not only never worked together, but had even been rivals. In the weeks that follow, the scale of the cultural problem becomes apparent.

Developers and ops teams are fundamentally different: they work in different ways, they have different priorities, and they approach problems from different angles. Of course, this means there’s potential for brilliant collaboration, but without the foundations in place to achieve harmony between these disparate teams, “doing DevOps” is doomed to fail.

However, like any great relationship, many organisations discover DevOps teams grow over time, becoming stronger, and encourage a mindset where communication, integration, and real collaboration between dev and ops is welcome. But most significantly, it encourages IT pros and the business to accept a few necessary failures and continually improve—together.

While brilliant for spurring innovation and accelerating transformation, DevOps adoption usually includes some rough patches of disagreement, finger-pointing, and tension. But ask IT team members who’ve made the transition, and most will tell you they’re far more flexible, less stressed, and have higher customer satisfaction than before. Many go further to say they won’t ever go back to a job in a waterfall operation.

The tools for collaboration

While changing team culture is a prerequisite, close on its heels is a reassessment of the DevOps tools your team uses to drive technology change. A well-designed DevOps toolchain frees up software and infrastructure engineers to spend more time working on moving the business forward, like new projects, features, or improvements to architecture, systems, and quality end users notice.

As is always the case with automation, the more time you spend improving your systems, the more they improve. And with DevOps principles, those improvements become data-driven and repeatable, not based on hunches and opinion. Right-tasking your tools will help you break the cycle of primarily fixing things and not preventing incidents in the first place.

The tools employed will vary according to the nature of each organisation. However, some basic principles apply to ensure effective measurement, evaluation, and insight. Because DevOps is relatively new to many technology teams, it’s an opportunity to reintroduce disconnected teams using the tools they already count on, by using them more methodically. Consider tools which emphasise communication, collaboration, and integration first. When software developers, QA engineers, and IT operations all point to the same data in a common dashboard, you’ll likely already see a reduction in friction and faster MTTR.

But what does this look like at scale? With the right tools, developers have easy access to the same performance data operations relies on to monitor effects of their changes on performance.

Almost organically, dev and ops begin incorporating application performance monitoring (APM) tools to move past the limits of estimating user performance from infrastructure metrics. Further, they’ll incorporate APM tools into the development cycles, allowing them to confirm performance and scalability well before code makes its way down the delivery pipeline. Better still, scarce resources like DBAs aren’t pulled in for every CPU or memory alert and instead focus on service indicators like wait time and are free to collaborate on overlooked query or table optimization developers need.

At the production end of the spectrum, IT operations need tools to make collaborating with the extended IT organisation easier. It’s much easier to maintain control over production infrastructure, workloads, and storage with a unified view into application performance. DevOps-focused teams watch application behaviour for changes, anticipated or otherwise, from dev, through QA and perf test, to production. If there’s one driver for unplanned work in ops, it’s being handed an alien application or system with no idea how it’s expected to perform. And Ops hates unplanned work.

It’s important for leaders to ensure the tools supporting the engineers feel natural and valuable to them or they won’t be adopted. While we all have a preferred instrument, the underlying teamwork will discourage bespoke processes, hacks, or brittle workflows. There’s a cultural shift from “what works best for me?” to “what works best for our team?” As an added benefit, teams often incorporate security policy as another monitoring dimension, ensuring governance as business-critical data is dispersed across different dev and ops teams.

As in any relationship, successful DevOps teams have shared more than a few moments of one step forward, and two steps back. You’ll hear some war stories about passionate disagreement, and even occasional disruption between teams. And that’s okay; culture change and individual progress is usually messy, even when you know the endeavour is important.

But when leaders and IT pros alike take steps to minimise the risk of failure by addressing people first, and then the technology, you’re far more likely to use DevOps to full benefit. When colleagues can see the bigger picture and the motivation for change, changing working patterns and habits becomes natural because they all share in the result.

DevOps takes time

A DevOps culture enables most organisations to modernize, and some to even reinvent their use of technology and processes. High-performing, low-friction teams are much more likely to earn freedom to chart their own destinies, shifting from cost centre-like facilities to an agile partner for business growth. When DevOps adoption fails, it’s generally because a few initial failures scare us into retreat, and back to traditional approaches. It’s important to remember that a few rollercoaster moments are important and part of the growth process. Only by personal trial and error in your unique environment can you teams determine how to adapt DevOps principles to your organisation.

A Gartner report entitled New Insights into Success with Agile in Digital Transformation shed light on this. It found that teams with under 12 months experience with a new development process are successful only 34% of the time. By contrast, teams with between one and three years’ experience are successful 64% of the time, while those with more than three years saw that figure jump to 81%. In sum, DevOps requires patience, commitment, and the passage of time.

When we look to the second decade of DevOps, it’s possible we’ll see a rebirth of IT operations as a competitive advantage, not unlike the initial adoption of business computing. Those machines, coupled with a more academic approach to their use, allowed businesses to express their unique value with more speed and less resources. They were successful not simply because of all the tech in their room-sized cabinets, but because they were high-profile, with corresponding investment.

DevOps is a tool like any other, but one which may connect and transform understandably risk-averse, change-resistant teams into a versatile, responsive business partners. And nobody likes living on a cost centre budget.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.