“We are far more united and have far more in common than the things that divide us” — Jo Cox MP

Unless you’ve been living in a cabin in the woods for the past few decades, you’ll know that tech can be a pretty tribal industry. People are sorted and categorised according to the technologies they know and use, the roles they are employed into, the depth and breadth of their knowledge, their preferred frameworks… In an industry where knowledge is power — specifically, earning power — it’s hardly surprising.

The Agile movement seemed to give us an opportunity to address this, with its core principles of business people and developers working together, of building projects around motivated individuals, and of self-organising teams. However, it eventually gave rise to yet more tribes; Product Owners, Scrum Masters, pigs and chickens…

Out of Agile grew DevOps, an explicit call to include more people in the complex process of delivering value through the use and development of technology. At last, a rallying cry for Software Engineers and Operations Engineers to unite! For us to bring together Developers and Release Engineers! For us all to cast aside our different roles and work as one tea- oh, wait.

Kids, we’ve done it again. We’ve taken what was supposed to be a unifying principle and used it to create even more ways to divide ourselves into exclusive clubs, each with their own identities, languages, tech and attitudes. Site Reliability Engineers, Cloud Architects, DevOps Engineers (even the existence of this as a job title generates heated debate in some circles) — somehow, “DevOps” is becoming another label to distinguish some roles and people from everyone else.

Does this get us where we need to be? Does it make our products and services more valuable? Do we deliver stuff better and faster? And does it make working in tech fun?

Nope, nope, nope and nnnnnope.

I’ve seen so many conflicts happen where the various tech tribes are pitted against each other, and it’s neither productive nor happy (and here I have to fess up to contributing to these conflicts on occasion, much to my shame). I’ve also seen people unnecessarily excluded from projects where they could have added real benefit, which is both wasteful and hurtful. We can do better than this, but it’s going to take more than those of us in Dev and Ops getting over ourselves.

Some people have begun to talk about DevSecOps, which is a start, but it doesn’t go nearly far enough. If we’re going to produce the awesome tech we all know we are capable of, we need everyone in it together. We need DevSecRelBATestProdHRProjFinITSupUsrOps, which is a bit of a mouthful and still bound to have left some people out, so let’s just call it DeveryoneOps. Get the right people involved in the early stages of a change, and you can shorten feedback loops considerably. Have enough different perspectives in the room at the start, and you can avoid rework when those less obvious non-functional requirements come to light later on.

How we achieve this Utopia is a huge challenge — clearly, it’s not practical to have someone from every conceivable discipline on every single team. Nor is it reasonable to expect everyone to be consulted on everything that’s going on. Each organisation has its own unique culture and communication patterns, and will need to develop its own strategies for ensuring just the right people are included, and at just the right time. A reasonable place to start is probably Ron Westrum’s ‘Typology of Organisational Cultures’, which should give a steer on where we can improve collaboration within our own contexts.

Beyond that, we all need to be the change we want to see in our world. It may seem counter-intuitive, but if we want someone to understand our own team’s difficulties, we should ask them what their challenges are. If we want to know what another team are working on, we should share our own plans first. When we demonstrate openness and curiosity about other people’s experiences, we invite the same in return; and if we can offer solutions to other people’s problems, they are more likely to want to help us to solve our own. Under it all, we’re all human and all just trying to do the best we can — and that puts us all on the same team.