I just got back from Devops Days Austin. It was a really good conference. I think I enjoyed the speakers and Open Spaces at this event more than I did at Devops Days Mountain View last year. Huge props to the organizers and speakers for putting together such a great set of topics.

One thing irked me a bit though, I heard a number of comments about how there was too much talk about culture.

I am confused – but I think I understand.

I attended one Open Space session called “Culture Hacks” which ended up not being so much about hacks as a plea for help. A number of folks expressed concerns about being in a difficult situation where they associate their problems with organizational cultural problems and they were looking for ideas on how to make things better. The suggestions that folks raised, myself included, sounded a lot like typical lean/agile tools – retrospectives, stand-ups, putting developers on-call, communicating metrics, providing incentives, hackathons. I think these are all good suggestions, the problem is that they only go so far. The unfortunate reality is that old saying – you can lead a horse to water, but you can’t make him drink. These are all tools but they don’t solve a problem in an organization that doesn’t want to change.

I think the topic of culture is pretty big and scary for many folks. It’s also very subjective, as John Willis raised in his talk – the culture in which a group of crooks thrive is very different than the culture in which a group of hippies would thrive (John didn’t use Hippies in his example). For each group though, there is a specific culture that allows those individuals to reach their goals in an optimal way. Is one culture right or wrong? Functional or dysfunctional? I think the answer is that if the culture is aligned with the team and makes them perform in an optimal way then it’s good – but it’s good for that group, not for everyone.

As such, if you haven’t defined an objective for your culture, if you’ve hired a mish-mash of people with different objectives and principles then you really aren’t going to find a culture that makes everyone achieve their goals. You can make it better for some, but it’ll likely not be better for others. Getting the folks off the bus who do not align with your desired culture is an important part of a change like this and is not something that an Ops person in one group can do. Here, I think, lies one of the main barriers to DevOps being about culture change – it’s driven by Ops people.

Ops working with Dev is great, we can all do that, but we are individuals who can only set an example and hope the organization follows suit. If they don’t – you can vote with your feet or suck it up, I’m not sure there are many other options. Setting an example often manifests as Ops folks trying get closer to Dev – the most natural way to do this is to write code, help with release engineering, enable developers to gain access to monitoring, logs, config management, etc. All the tools that we say aren’t actually what Devops is about… These seem to me to be a manifestation of ops folks doing what they can do get closer to Dev, that’s all.

Of course it isn’t culture, company culture is bigger than this, but it can change a small part of an organization & help set an example for the broader organization. Sometimes it can have a bigger impact – I love this one by John Allspaw as an example. Still, the change was isolated.

I recently read & really liked this TechCrunch article because I feel like it hits on an important point. If I work at a company where the CEO, CTO, COO, VP of Engineering or a variety of other high level positions push a culture that I don’t like – my chances of changing that are small. Further still, there is already a culture which is somewhat defined by the team you’ve hired. Unless you’ve worked very hard to hire for a specific person & team fit then no amount of effort is going to change the organizational culture.

So what is my point with all of this? While Dev & Ops collaboration is important to having a healthy development process – it is so easily undermined by problems with the larger organization. I don’t think that means you do nothing – I just think it helps clarify why talking about culture is hard. I also think having more actionable steps, more examples to replicate would be helpful. Right now the examples we have are of companies who have a good culture throughout – but what about companies who can’t do that? How do I fix my piece? How do I get my 10 person startup pointed in the right direction? How can I build a functional bubble inside a dysfunctional behemoth? What can I do to make my small corner of the world suck less?

There aren’t enough good examples for these questions – and this is why we need to talk about it. Talking about the little bits and pieces that work for you helps – so don’t avoid talking about it because you don’t have all the answers – share what you can. In that Open Space I attended, plenty of folks had little ideas about things that worked for them – they didn’t have a complete solution, but they had some ideas.

I shared my thoughts about how this may look when you start from the ground up and we’re implementing some of these ideas at my current company. Are they all the right things for this company? Probably not – the team will decide. Some of the things that worked at a past company wont work here – does that mean we are doomed? I don’t think it does.

Culture is very personal – but so are a lot of things that we have some established patterns for. We are homing in on some ideas that work – we need more ideas – and we need to talk about them more. I hope this comes up more at other Devops Days events in the future. It’s an important topic.