DevOps is Transformative

Separation by function isn’t the best way to break up a company. People with similar areas of expertise work together and learn together, but they don’t understand the company, and nobody understands them. Functional separation leads to pedestals for some, and dismissal for others. In well run development and operations teams, people will tell you they’re pretty happy. They’ll also frequently tell you they wish they knew more about what was going on. This isn’t caused by poor communication, but by an inherent shortcoming in functional separation – nobody gets to feel like they own anything. Everybody is just a cog in a machine. For some people, that’s enough, but most people need more. Most people need to feel some control, some pursuit of mastery, and some purpose or sense of belonging.

DevOps Is About Communication

DevOps isn’t about technology. Technology is a part of it, but it’s not the root. DevOps has been, since its inception, a process by which Development and Operations (and the rest of the organisation) can learn to speak the same language and work together. Historically, Development has been responsible for delivering change, and Operations has been responsible for maintaining stability. To many people, these are fundamentally opposed remits – change creates the risk of instability, and stability prevents change. One of the things that DevOps does is it shares out responsibility for both change and stability to both groups. Developers become more responsible for stability, and operations become more responsible for facilitating change.

The most popular implementation of DevOps is in Operations staff delivering tools that make delivery happen faster – the move toward continuous delivery. It would be a shame, however, if people thought that continuous delivery is all there is to DevOps. When some of Development’s concerns about delivery and change leak into operations, concerns with stability leak back. This is inevitable, as rapid change requires stable releases. So with continuous delivery often comes a push toward testing first, automated testing, and ensuring that both positive and negative tests are well represented in the code (this change can equally start with QA, and spread from there). Without this improvement in automated testing, continuous delivery another name for shipping bad code.

As information starts to leak in both directions, communication improves, common ground increases, and a virtuous circle is created. Improvements in communications leads to more collaboration, which can lead to changing how teams work together. In some cases, it can lead to complete automation of infrastructure deployment (i.e. infrastructure as code), configuration management (e.g. configuration as code), or at the logical extreme, developers being paged when systems go down at night (i.e. developers being responsible for stability). Improved collaboration encourages more regular communication, which in turn suggests changing team structures. If Development and Operations staff work better together than they do when they’re separated, it makes sense to put them in teams together. But how are those teams structured? It’s at this point that the rest of the company needs to get involved.

Delivering What Customers Want

Continuous delivery can only take an organisation so far. It’s part of a transformative process, part of a way to improve things, part of DevOps, but not all of it. Reaching its full potential requires assistance. It requires organisational change, which is where things get difficult. Collaboration between Development and Operations can be done by two people who want to work more closely together, two managers who want their teams to work better together, or one more senior manager who sees things and wants to improve them. Progress beyond the purely technical arena requires senior management involvement, because the next step is to look at how customer needs move through the company, and how to improve it, which usually falls outside the sphere of control for technical staff.

Customer needs usually come into the company via sales, account managers, or customer service. These are people who are intimately familiar with customer needs, and what they’re willing to pay for (as well as what they hate). From there, someone prioritises them into things to do now, later, and not at all. And then someone works on delivering, testing, deploying, and supporting those needs. These people all help needs flow through the company, and therefore help money flow into the company. These people don’t have to be separated, each delivering part of the pie, without knowing what the benefit of their work is. Instead, they can work together, collaborating and communicating on the best way to meet demand, satisfy requirements, and deliver, with a minimum of fuss. By organising teams in this way, so that customers with a need are at one end, and satisfied customers are at the other, they are transformed from groups that are looking out for their own small part of an unknowable empire, to a group that’s working together to deliver something worthwhile.

Never underestimate the transformative power of giving people a purpose they can wrap their heads and hands around, of building teams they can share that purpose with, and of tearing down walls that stop people from talking to each other. Don’t be mislead, it isn’t easy. Compensation will have to change, management will have to change, and expectations will have to change. And when it’s done, nobody will want to go back to the way it was before.

Further reading

Change is Coming to IT
Agile Transformation
The Business Behind Microservices

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.