I’ve been inaugurated with my first DevOps Days. It was a fantastic, exhausting weekend where I probably gained more perspective on the DevOps community in 2 days than most of my working career.

What’s a DevOps Day anyway?

If you’re not familiar with the concept of the DevOps Days conference, it’s sort of like an industry conference injected with extreme participation. The attendance is kept intentionally low (although we were at about 425 attendees) and a major focus of the event is the Open Space meeting. Even the Keynote Speakers are encouraged to be new voices in the community over the existing and previous-years’ speakers. This leads for an awesome overall message of “your voice matters.” The only downside is that you meet a ton of people and do a lot of brain-stretching in a short period of time; my introverted side was totally spent by Saturday morning.

Technology can’t fix a people problem

My first major takeaway from the convention was this: People are important. If you find yourself “Rubbing DevOps on it” but the rash just won’t go away, it’s not a technology problem, it’s a culture problem. I could repeat this over and over, but helping people is why I fell in love with technology. The primary motivating factor behind leaving my previous jobs has been a culture issue. It was never that I didn’t love the work, it was that I hated the way the organization’s culture permeated their workforce. Culture matters. Your people matter. If you focus on your people, your product will reflect that.

Automate your 💩

Secondly, it’s all about technical debt. This was a new term for me, personally, but the concept isn’t new. The idea focuses mainly on opportunity costs for any task. Every time you cut a corner, there’s work that you’re not doing that needs to be completed. This work can manifest suddenly as unplanned work when multiple band-aid fixes inevitably go wrong, or when something breaks and there’s not enough documentation and the on-call tech has to troubleshoot the entire issue from scratch. Except that tech doesn’t even have information about what the system is supposed to do. So it was crystalized like this for me:

1. If you can automate it, automate it. If a human doesn’t have to be involved, why make the work for them? This task is important because it frees up man-hours for more important work.
2. If you can’t automate it, you need documentation. For incidents, Minimum-Viable Runbooks are crucial. There should be no guessing what systems do and how to fix them at 3am.
3. Any task that improved quality of life for your employees is critical. Getting paged after hours interrupts sleep and reduces quality of life. Removing unplanned work takes priority even if that means your planned feature release gets delayed.

DevOps CT: Challenge Accepted

All in all this was an awesome conference that greatly encouraged me to build a similar community in Connecticut. Dave and I have already begun by planning our first DevOps CT Meetup. So if you are interested in getting connected with the DevOps community, please sign up and join us in conversation. I would love to talk about all the pie-in-the-sky ideals and discuss all of the realistic challenges that we face daily when trying to affect real culture change in CT. It’s a huge challenge to take on major monolithic organizations like the insurance giants in Hartford, but I leave it to Barney Stinson to share my thoughts on this: “Challenge Accepted.”