Two excellent posts from my colleagues Rachel (DevOps: Tools Can Lead The Culture Change) and James (Tools lead culture change: Happy Birthday DevOpsDays) have contributed to an ongoing conversation about the relationship of culture and tools in the emergence of DevOps and the related adoption of software development practices and processes. Both lead with the premise that tools lead culture change (and go on to address how the relationship is more complex).
In this post I take a closer look at the idea of culture itself. While we tend to speak of culture as if we are all speaking of the same thing, this is not always the case. Likewise, while we often frame related concepts such as “culture fit” and “culture change” as positive, they can also be used as tools for gatekeeping and exclusion.
Considering culture
My day-to-day has shifted far enough into tech spaces that I now almost automatically process “culture” as “company culture” (or even more specifically as “tech industry company culture”). For those of you who do not have such an internalized meaning at the ready, I offer Emily Freeman’s definition from her recent book DevOps for Dummies (which I highly recommend):
Company culture is best described as the unspoken expectations, behavior, and values of an organization. Culture is what tells your employees whether company leadership is open to new ideas. It’s what informs an employee’s decision as to whether to come forward with a problem or to sweep it under the rug.
Company culture is often described in terms ranging from “vibrant” to “healthy” to “toxic”. In some contexts (especially for startups) company culture has been leveraged as a recruiting tool. While Freeman characterizes it as unspoken, some companies have attempted to articulate aspects of company culture through explicit mission statements, lists of values, or codes of behavior.
And yet culture more broadly takes on a number of other meanings that can be useful to those of us in the tech industry. The term often denotes some combination of practices and artifacts (art, music, writing) through which we understand groups of people: something that you can soak up or understand by visiting a museum or eating at a properly local restaurant. Conversely, for sociologist Ann Swidler, “culture” works by “shaping a repertoire or ‘tool kit’ of habits, skills, and styles from which people construct ‘strategies of action.’” In other words, it is so pervasive that it helps us navigate our everyday life.
“Culture” is also used to construct categories of socially produced materials. Theorist Theodor Adorno, for instance, decried popular culture—which he calls “the culture industry”—as an antithesis to cultural products that he considered to be “high art”. The concept of art itself is often associated with an even more restricted concept of “culture” constructed around elitism (and the question of who gets to decide what counts as “art” can be just as fraught as the question of who gets to decide what/who counts as “technical”).
Culture is so ubiquitous and yet so contested a term that we have an entire interdisciplinary academic field of cultural studies dedicated to it. It is used to mark things that we think should be preserved, practices that define groups of people, and—perhaps even more importantly—reasons for excluding people from those groups.
The culture fit trap
It is this last use of culture that brings us back to tech. As much as even a medievalist like myself has begun to internalize “culture” as “tech industry company culture,” there is also a part of my mind that immediately processes “culture” as a tool of exclusion or gatekeeping, especially through the hiring criteria known as culture fit.
The process of hiring for culture fit, roughly defined in this Forbes piece as “seeking out individuals who align with your company’s unique culture and values” sounds (and can be) beneficial and is often accompanied by the qualification of also prioritizing diversity. In practice, however, culture fit can also become a justification for excluding otherwise qualified candidates and perpetuating a monoculture. Or, as this Harvard Business Review piece on hiring argues:
What most people really mean when they say someone is a good fit culturally is that he or she is someone they’d like to have a beer with. But people with all sorts of personalities can be great at the job you need done. This misguided hiring strategy can also contribute to a company’s lack of diversity, since very often the people we enjoy hanging out with have backgrounds much like our own.
Hiring for culture fit all too often becomes hiring people who are like us or who we think will easily follow established practices and customs. Another instance that has popped up recently on Twitter (based on a student’s notes on Max Levchin’s guest lecture in Peter Thiel’s class at Stanford):
https://twitter.com/SaddestRobots/status/1184885797419401216
The above example, in which candidates are seen as culture mismatches because they play basketball or do not fit a very precise combination of “nerdiness + alpha maleness,” nicely illustrates how some organizations justify exclusion by privileging certain perceived aspects of their company culture when hiring for culture fit.
While it is tempting to think of such practices as happening “somewhere else,” there are few things (aside from being the candidate who has been excluded under such circumstances) more anger-inducing than having insight into your own company’s hiring processes and seeing very qualified candidates dismissed because of “cultural fit” concerns that amount to “they do not look and speak like the people in charge.” In such cases, culture fit has become a trap whereby companies can, among other consequences, severely limit their candidate pool (while likely blaming a pipeline problem), further alienate current employees who may already feel marginalized, and cultivate a reputation for exclusion.
But what about culture change?
When we talk about “culture change” in the tech industry in general and in the context of DevOps in particular, we almost automatically assume that culture is understood and that change will be positive, thus resulting in greater velocity, more efficiency, and happier teams. Indeed some of these articulations of culture surrounding DevOps are particularly appealing to me, such as Freeman’s prescription for culture as “collaborative and customer centered.” And yet, I wonder how easily even concepts as seemingly lovely as collaboration and customer empathy can result in unforeseen consequences, especially if cherry picked out of contexts that explicitly call out the importance of diversity (as Freeman and many other DevOps proponents rightly do).
Emphasis on collaboration as a component for a DevOps-motivated culture change, for instance, could quite easily result in the adoption of the same type of exclusionary practices we have seen with culture fit and hiring, yet under a different guise. Furthermore, while we have begun to identify and talk about considerations of culture fit as potentially adversely impacting hiring, the obvious corollary in considering team formation—in this case that we could end up with less diverse DevOps teams because they were created with a “who would I like to have a beer with” version of collaboration in mind—is not often considered.
Likewise, the customer empathy prescribed by DevOps is, to my mind, an obvious strength, but is there also a sense that it can go too far? Too often in tech we are reductive about the customer: while we might explicitly say that we are considering a diverse range of customers, implicitly we may be concerning ourselves primarily with the needs of a 28-year-old white male software developer living in San Francisco. We hear about how more diverse teams can lead to tackling problems differently and seeing the market from new and different perspectives. We never seem to talk about the inverse, which is “What is the impact on teams when you have so narrowly defined your market/audience that it leaves little room for different perspectives to feel welcome on the teams building the product?”
Because “culture” itself can be understood in so many ways, I argue that we should refrain from automatically assuming that the concept of culture is singular and that processes labelled as cultural change are necessarily positive. We have seen the concept of culture used in exclusionary ways before: culture fit in hiring, categorizations of what counts as art, reductive thinking around who we would like to get a beer with (and, indeed, any time folks in our industry insist that it must be beer).
And yet, as my colleague Stephen argues, culture is important (and certainly valued here at RedMonk). He suggests that when hiring we “whittle down the huge, unmanageably broad definition of culture down to just those few characteristics that do matter” and then make those criteria clear and explicit. To my mind, the practices surrounding culture and culture change in DevOps would benefit from the same type of care and clarity. I would also like to see diversity and inclusion loudly and consistently prioritized; otherwise the impact of promoting culture change may become yet another culture trap.
No Comments