Can We Bridge The Dev Ops Culture Divide?

Within the last two decades, a lot has changed for the IT industry. Once upon a time, IT teams were ironically disconnected from each other. There was a team for dev, another team for infrastructure, another team for operations, and so on. The system was sluggish and ineffective.

The good news is that it’s all in the past. These days, IT has gone small, micro even. Instead of large, unwieldy organizations with multiple skill-based silos, DevOps has evolved into dedicated cells with an emphasis on improving flow.

So how do you create a high-performance DevOps team from the ground-up? We reached out to two IT professionals, John Vella, Back-End Team Lead at MindArc and Chris Harwood, Service Director at Healthdirect Australia, to share their thoughts on how to create a successful and efficient DevOps team. We’ll share their insights below.

How The IT Culture Has Changed

Chris Harwood notes how backend development teams now enjoy a more prominent position in many companies. “Over the last 20 years I’ve seen the definition of ‘IT’ change many times, and it is still evolving.  What was once seen as a ‘back-of-house systems’ team that supported business processing, reporting and desktop users, etc. has transformed dramatically to become a critical part of a business.

“Over recent years, tech culture has evolved rapidly as agile stopped being a process and became a way of learning & interacting with the market you serve.  This test >> learn >> adapt culture pushed all the way back into the processes and ethos we now apply to product delivery.  When the ‘IT’ team can outpace the marketing of the products, you know that they have to be working in the business and not for it. This has changed dev and tech culture for the better.”

John Vella of MindArc agrees. “The culture has taken a huge shift in regards to team collaboration by opening up development to the greater team. Backend development and software engineers usually have this expectation of being isolated and locked down into a dark corner of the office, however, as of late they are being exposed a lot more and working with teams more directly to tackle issues and problems with some being exposed to client meetings.”

Vella continues, “The culture has shifted in so many ways but the ability for DevOps to be more front facing has provided us with the advantage of developers to understand both the technical and see the client perspective so that they get a greater understanding than the task itself but also the purpose and context of that task. Developers will have more of a sense of ownership and will more drive to complete the task that way.”

Different Work Styles of Development Teams and Operational Teams

One of the most important things to consider when creating a DevOps team is work style and philosophy. Is it true that development and operations have different styles of approaching a project?

For Vella, there is a difference, and it’s with the way the two teams approach and tackle problem-solving. “The key difference between the two teams is usually the way that the two teams treat an issue. The solution breakdown for each comes from two aspects of thinking and you begin to get a better understanding of the issue since you’ve got both teams investigating from two different angles.

He continues. “The Operations team takes the approach of understanding client requirements and needs whereas the DevOps team takes the approach of understanding the technical capability of the software and limitations and formulating a solution that can work within those bounds.”

For Harwood, however, his mindset has evolved over time. “Up until 2015, I would have said, ‘Very yes!’ Since then, the only reason to operate teams separately like this is the legacy expectation, old organisational design and a company that still pushes a project and not product culture. The teams we run today now take as much responsibility for the operational state as they do for the new features on the roadmap.”

Harwood explains the difference between the two teams.

“In the past, Dev was feature driven and deadline focussed, built on the premise that feature delivery had to hit dates and that stability was someone else’s concern.”

This mindset toward stability was one of the biggest complaints for the Ops team. For Ops, stability was absolutely critical.

“In the past, Ops was the stability and process focused team, built on the premise that change was risky and to be minimised.”

“Now that Dev is no longer a separate team from Ops and the two work together, the product teams own the customer experience and commercial/service outcome.” Harwood continues, “Ops works alongside developers to help improve the visibility of application performance and measurements of commercial/service outcomes.”

Collaboration Between Teams

When it comes to managing collaboration between the two teams effectively, Harwood suggests a conceptual shift in terminology. “Calling them ‘two teams’ perpetuates the historical divide between change vs. stability! This is no longer the case.

“Sets supported by automated delivery pipelines means that those small changes can occur rapidly ensuring that the system resilience improves and risk is reduced. This is the biggest conceptual hurdle for traditional ‘IT’ organisations.”

Vella is a strong supporter of funneling. “As the Team Leader for the Backend Developers, I do like to try and funnel information down to the developers to ensure they are led on the correct path for issue tracking and solution driving.”

But too much funneling can be a bad thing as Vella warns, “Limiting information with too much structure can begin to cause more issues. Effective communication and information are lost when you funnel it too much.”

What’s the solution? Vella shares his strategy, “There are times where the developer can freely collaborate with Account Managers to ensure that information isn’t lost in translation and they can directly receive the information they need to begin their work. I believe opening up this area more allows for developers to work freely and give them the right tools they need to complete the task at hand.”

Key Challenges to Creating a Successful DevOps Team

According to Harwood, the biggest challenge is overcoming the traditional mindset and embracing radical transparency. He explains, “Ninety percent [of the problem] is people and culture. The rest is ensuring they agree on the tooling and languages. Most importantly, it is giving your teams appropriate permissions to own the products and the services they provide which means delegation of decision authority over tooling and feature priority.

“The only way leaders can do this is with radical transparency: The teams need context for the business model, customer experience & financial targets, and the impact they are having on these as they improve the products. Limiting their view of these things means they cannot make effective decisions or be held accountable to the results.”