DevOps Culture: An Ethnography


An ethnography is a holistic study of another culture conducted by an anthropologist. During the study, the anthropologist lives among the members of the foreign culture, takes notes, and collects data. From this data, the anthropologist develops theories and tests them cross culturally to determine if the source is genetic/biological in nature or enculturated. Determining the cause of behavior can be a tough business and is part of the larger Nature vs. Nurture debate. This observation comes from a systems administrator living among professional developers.

DevOps is a movement that has been going on for a while now. It follows in the footsteps of the Agile movement but applies to infrastructure. Basically, there seems to be a pattern in most web shops where developers try to institute change for the business, while operations try to prohibit change to avoid risk. The two camps, development & operations are often referred to as silos. The DevOps community believes that a system of shared understanding can mitigate the stagnation and consternation that comes from this pattern. In many ways, I might liken it to offence and defence in a war to make solid products and money.

Part of this understanding has come from tools such as version control and infrastructure as code, but recently the focus has moved to people & culture. This begs several important questions. Is this a cultural problem or a psychological problem. Is this a science? Is this an art?


The other day, I was plugging away writing some code for a cool little open source backup script. A couple of hours into writing, I realized, I was dreading the idea of implementing it in my production environment. I was a programmer for that split second. I felt almost blind to what would be necessary to implement it in production and I didn’t want to think about it. I just wanted to continue coding and hand it off to somebody else. The problem was, that somebody was me.

Strangely, the same thing has happened when I spend several hours making architectural drawings. In fact, the same thing happens when I get into network equipment or configuring servers, or writing documentation, etc, etc. If I work on one type of thing for a couple of hours, there seems to be some momentum which forms and it can be difficult to fight that feeling. I have observed this pattern with developers, systems administrators, architects and others. I suspect this silos thing may be more like a grid, which leads me to believe there may be some psychological component.

I have never been a for profit developer. I have never worked in a large team, developing a product which will be sold. This begs the question, how could I have this feeling well up inside me? Where could I have learned it from? I have always worked on the infrastructure side.


What if these silo’s form because at an individual level changing gears hurts and commiseration with others of your team positively reinforces the negative behavior over time? If this is true, than we must rethink how we are tackling this problem. It will take more than just open minded individuals who have worked as both developers and systems administrators. It will take more than just having passion for both. One will be required to constantly remain cognoscente of the psychological component which cannot just be trained away.


It can be hard to truly understand another person’s point of view, especially if they are from another culture. I spend a lot of time with developers at work, at meet ups, and at conferences. Some days I feel like E. E. Evans-Pritchard living among the Anuak (See picture above). Our technical body of knowledge & problem sphere can be so large that it feels like I am interacting with members of a different culture. As technology expands, this is going to become a greater threat to productivity. Also, I suspect that these silos, or grids, formed to allow most of us to participate as productively as we can. Nonetheless, I think it is a worthy goal to try and understand as much as we can about each other.

Leave a Reply

Your email address will not be published. Required fields are marked *