DevOps is political.

I’m making an assertion here: that a lot of us think that technology and working on it is inherently apolitical, but that is not the case. I’m going to try and make my case over the next 10 minutes, and hopefully some of it sticks.

Let me further clarify: When I say politics, I don’t mean politics in the “I vote for Greens!” or “I’m a libertarian!” kind of way. I mean it in the sense that from an organizational perspective, we have certain tradeoffs that we are willing to make.

The crux of an argument is this: the technology that we create is an expression of our internal belief systems. How we build things is indicative of our own value systems in a nontrivial way.

DevOps as a not-paradigm.

The word DevOps gets bandied around a lot, with different answers depending on who you’re asking. Jez Humble defines it as a way of operating that caters for rapidly changing systems (I.E., CI/CD, fast feedback loops) — and some people define it as operations people using developer paradigms to actually run systems and deploy things faster. For the most part, what’s true is this: there’s a pseudo-consensus that it has to do with enabling organizational agility.

What’s not said is that agility means different things to different organizations. There’s no canonical way of implementing it from an organizational perspective. And if this seems a bit high level, let me unpack further.

Words mean different things to different people.

So I’m going to do something here: I’m going to outline what I mean by “different implementations” without providing my own opinions on it. There’s a couple of pivot points that an organization usually moves by:

• Team Managed Infrastructure vs. Centralized. Do teams have their own infrastructure? Or does someone run it in the middle?

A.) If it’s the former, do development teams have to learn operations? Does this mean that developers are responsible for their own infrastructure? Does this also mean that they go oncall? Does this mean that they can run their applications in any way they want?

B.) If it’s the latter, then does that mean that there will be a centralized operations team? Does this mean that developers are only responsible for their application? What does this mean for after-hours support — and conversely, what does this mean when it’s unclear if the source of an issue is unclear from an application vs. infrastructure perspective?

• Organizational input and direction on tech choices? Does your company pick or “bless” a particular set of technologies?

A.) If the organization has zero input, does that mean that teams can run whatever they want? If so, is there a mechanism to make sure that everyone knows what everyone has been doing? What does this mean from liability, when another team can affect another service from a security or availability perspective?

B.) If the organization has some input, how is it determined if a team can deviate? And if a team decides to deviate, do the decision makers have sufficient context (business and technical) to make the decision? How do we make sure of this?

C.) If the organization has autocratic input, does this mean that there’s a business unit which innovates on newer, better technology choices? If so, do they have sufficient support? Conversely, are other teams bottlenecked by their delivery speed?

And depending on what we value and how we value things, we’ll choose one.

There are no right choices, only deliberate ones.

I do apologize if I’m not really offering a solution here — the best I’m willing to offer is considerations. These are important considerations to make when choosing one way or the other — and in an ideal world, these choices would be transparent and considered. For the most part however, they’re accidental — or rather, incidental.

These choices are made by people.

It’s vulnerable to how much people know and which part they know about it. Maybe they’ve been to an organization that chose a path and it didn’t work out well. Maybe they’ve been working in the organization for years and have seen all other approaches break down — maybe as a direct result of the choice, but maybe not.

It’s vulnerable to personal relationships, as much as I hate to say this. It’s vulnerable to people being more likely to listen to someone they have a good relationship or rapport with. And I sympathize to this in a degree — I prefer hanging with people that don’t stress me out. And the frequency of our conversations (and who we’re having conversations with) affects my own decisions.

It’s vulnerable to our own personal tendencies to hold on to opinions. I’d like to make the distinction between a strong opinion and a tightly-held one — it’s entirely possible to feel strongly (and be strongly informed) about an opinion, but be able to let it go once sufficient evidence surfaces.

It’s also vulnerable to our internal value systems within the context of an organization. If we allow teams to manage their own infrastructure, does that mean we trust them? If we don’t, does that mean that we want teams to be able to deploy safely?

So: a personal choice, which can vastly differ from person to person, informed by what we know, who we surround ourselves with, and our ability to change our stance. And it’s grounded by our personal belief systems.

Sounds like politics.

This is not really novel.

Different aspects of this topic have been covered before, with probably better ways of elaborating on the fact. Conway’s Law says that the software an organization creates is a synecdoche of the organization’s communication patterns. Edgar Schein argued that our values influence our culture, which influence the artifacts that a system creates.

And as Andrew Cosgriff says (painfully, repeatedly), everything is a tradeoff. The only thing I’m suggesting is that we become acutely aware of these factors before we start talking.

What does this mean?

I know I’m not really providing for a set way forward, but I submit that the political bent of DevOps means that a couple of things are important.

Strong opinions, loosely held. It’s not wrong to have strong opinions. It encourages us to inform ourselves, to arm ourselves with knowledge so we can defend our opinions. This falls apart when we don’t let go of what we think in the face of evidence to the contrary — or sometimes, if we become selective in our selection of facts (“Infrastructure Y worked for Company X, so surely it will work everywhere!”)

Empathy is everything. “Othering” describes the reductive action of labelling someone else (and conversely, their opinions) as not belonging to the group. “Don’t listen to Saul, he says so much shit.”

This has an effect of exclusion, and creating bias in the defaults by which we parse their opinions. In the context of DevOps, it’s easy to slide into the tendency to automatically discount the opinions of someone in the opposing faction: instead of parsing their opinions as an effect of their collective experiences (and possibly interrogating those experiences).

Constant communication is key. Opinions have to be tested, aired out, and defended in public. The more reprehensible parts of our society flourish when they have echo chambers of people with the same opinions; truth flourishes in the light. This in turn, informs everyone else — including people who haven’t made their minds up yet (the fence-sitters).

Don’t try to make right choices, but try to make deliberate ones. At least, within the context of DevOps, there will be no choice that is ultimately right. And this, really, will be the hardest one. We must try and keep sure that what factors into our choices are fair; that it is not nepotistic, that we are mindful of our biases.

In a world where there is no objectively “correct” way to do something, the best we can do is to make sure that we are informed, we are fair, we remain humble, and we keep being good to each other.