DevOpsDays in Boston vs. Kansas City

DevOps culture differences

Recently, I had a chance to attend the same DevOpsDays conference, but in two different locations: Boston and Kansas City. I was interested in any demographic differences between attendees in each location. Here are some findings I thought would be interesting to share from a user research perspective.

At each conference, we proposed a discussion topic about monitoring best practices. About 30–40 people in Boston gathered with us, and 15–20 people in Kansas City. We talked generally about people’s monitoring experiences, on-call rotations, tools, and explored insights into monitoring best practices. I noticed a distinct difference in the answers between these two different cities. In Boston, most of the folks I talked to described their process as something like this: “We tried XYZ, but it didn’t work well so we decided to do ABC.” I’ve added the emphasis on we myself, but I truly got the sense that they felt part of a team.

In contrast, in Kansas City I witnessed people mostly saying “I did XYZ for my company.” The use of I vs. we caused me to wonder — “Are you the only one who is responsible, or do you talk to anyone else while you go through these issues?”

Another interesting behavior that caught my attention was the attitude differences towards postmortems. When we discussed the postmortem processes in Boston, most SREs spoke about sharing their learnings from all incidences across everyone in their business. It seemed to me like their postmortems were genuinely taken as a learning opportunity.

On the other hand, I was mildly surprised that Kansas City attendees have had a rockier path towards achieving blameless postmortems. Unfortunately, I even heard several of them describe postmortems as a place to get blamed. One SRE voiced his postmortem situation as “I’m going to get blamed, so I don’t like ’em. Or, we end up not even doing postmortems even though we know we should.” My interpretation is that no one wants to be seen as having done something wrong, and this results in drastically less information sharing. However, this potentially costs the organization dearly if it leads to repeated encounters with problems SREs fix over and over.

I don’t yet have comprehensive data on these two observations across many geographies, but I’ll continue to focus on these two axis of discovery. Please drop me a line or respond below if you have any similar regional experiences, or if you completely disagree with my observations.

This article was originally posted for kaizenOps.io on Oct 9, 2017