Trusting Trust
The tech industry is an interesting place. On the one hand, we have the old guard, the 80s-driven “hacker culture” that drips with contempt culture and ivory tower silo mentalities.
On the other hand, we’re seeing a revolution in our culture in the form of DevOps. a DevOps is interesting in that it looks like it’s about tools, but in a complete head fake we see that nothing about DevOps is about our tools, but instead everything about how we work and how our teams function, both internally and externally.
The mechanisms of contempt culture drive us towards silos, islands of cultural isolation where our tools and ways are “the best”, and anyone outside is lesser. Less smart, less capable, less worthwhile as a human being. These silos have been the dominant force in the tech industry almost since its inception, from the original MIT “lusers” insult through the self-fulfilling prophecy of “PHP is bad”.
DevOps, by contrast, is a cultural push to dismantle the silos between developers and operations. We recognise these silos are harmful or reductive, and place us in combative situations where we are unable to achieve our goals. We’re learning to trust each other, even if we don’t fully. We still expect the mechanisms of contempt to rear their head, for people to treat us badly for our ignorance or failures.
But these silos are more than just the silos between ourselves, they are the silos that isolate IT from the rest of the company, and isolate our communities from the broader world around us.
We don’t trust our users, the people that our jobs exist to serve. We still treat them as an isolated silo, as lesser, as knowing less than we do and consequently being unable to contribute.
They don’t code, after all. Their contributions can’t possibly matter.
More importantly, more harmfully, people outside our silos don’t trust us.
The Untrusted Many
We all have stories about the users we hold in contempt. The people who click links in their email (as though we don’t). The people who don’t take care of their systems the way we think they ought.
The people who choose to use devices that just work, and our contempt flows from us that they would dare use tools that enable their goals without our permission and gatekeeping.
I use “gatekeeping” intentionally, for that is what we do. We blame the victims of our failures, accusing the user of clicking the wrong link, not running the right antivirus, of buying the wrong device. We make them ashamed of asking for help, insisting that they should have known better and that they are not worth our time, and we demand obsequience before we will lower ourselves to helping them.
And we say we don’t do this.
The broader public doesn’t trust us because we are cruel, isolationist and harmful not just to them but to each other. Through language that demonstrates our contempt for outsiders, such as RTFM, PEBKAC, and ID10T errors, we assert that our skills are the only ones that matter. Our central tools, such as GitHub, spent years treating code as the contribution. We treat the clients that pay for our time with contempt because they don’t know how to ask, or express what their goals are.
We may claim otherwise, but culture is not what we say, it is the actions that we permit.
We permit the Linux kernel community to be a toxic wasteland, a technology which is a vital driving force of modern computing. We say we do not value contempt and hostility, but our actions show otherwise.
Outside of our community, we are untrusted. We are the risk, we are the toxic person to many people who know us. We may never have performed contempt culture, never have shamed our family, friends or colleagues, but we benefit from contempt culture. We benefit from the idea that all IT workers are hostile, that the technical are “wizards” and that they should come to us in supplication.
That when they come to us they should beg, and make us feel superior before asking for our help.
I’ve seen this countless times. People become deferential to me when I say I work in technology, because they are so used to people in tech treating them badly, of being made to feel bad for their ignorance.
Empathy Systems
DevOps is starting to change this world, for the better. As a head fake, we are offered new and shiny tools to help us do things better, tools that fit well into the Agile workflows that dominate our industry. We discuss how our software fits into the broader ecosystem of a reliable deployment, how we can better deliver the goal of “working software”.
As a dev, there’s nothing more satisfying than delivering software, of making something work and delighting those who have asked my help.
But what we’re learning with DevOps isn’t tools, it’s empathy. It’s teaching us what silos look like, and as a dev, teaching me that ops people don’t trust me, they see me as a risk, a threat, a source of anxiety.
DevOps is teaching our culture to see that our isolationist attitudes prevent doing great work.
This must not be the only step, but the first step. We are discovering empathy and with it how to look at other points of view, other needs and concerns, and delivering “better software” as a result.
But our definition of better remains flawed, incomplete and hostile, because our culture still isolates us from our users of our software. Better remains better for us, for the elite, where we deliver our features faster but still demand obsequience and reject an understanding of what our users need, of what their goals are.
Improvement Plans
It doesn’t have to be this way. DevOps is showing us how to respect other needs, other goals and priorities. It is teaching us a culture of respect and inclusion, but only for those who already share our elitism.
We can go further. Entire fields of study exist to understand user needs, to improve their experiences and deliver tools that aren’t just stable, or easy to deploy but delight and inspire, to make people feel great and powerful on their own, without the false ideal that they must be able to code.
We must choose to admit that our culture is exclusionary, that the system of it performs exclusion, and that we think this is ok, and we must choose to explicitly act to include those who have been excluded. The design experts, the writers, the user experience experts. The people whose skills make a project live, the people we look down upon. The people who aren’t like us, who show us different needs that we keep overlooking.
The users, the very people we make these tools to serve.
And just maybe, we can rebuild the trust that has so long been shattered, build communities that respect all needs, and work to serve more people.