Lessons learned running a DevOps meetup

I’ve been organizing the Boston DevOps meetup for almost two years now. When the organizer spot opened up I jumped at the chance. My experience DevOps-ing along in smaller organizations gave me a pretty narrow view of the movement and I wanted to educate myself. I also wanted to become better at public speaking (still working on that).

I’ve talked with a lot of people learning about, struggling with, and eventually getting somewhere with DevOps at different organizations. We’ve hosted presentations, panels and open spaces at several venues throughout Boston and Cambridge. Partnering with other local meetups, we’ve held discussions on everything from recruiting to wearables.

As always, YMMV, but here are some things I’ve learned organizing events for our community that weren’t obvious when I started.

 1. Being welcoming takes consistent effort

This really applies to any community, but welcoming new members involves more than providing a cool venue and pizza. You really have to take the time to encourage new people. Since we don’t agree on a definition of DevOps, most people starting out feeling uneasy and unsure how they can contribute.

Not every engineer is an introvert, not every marketer is an extrovert. Grouping people into archetypes based on their job function is not a good way to start new relationships. This is our human nature foiling us - we’re trying to pattern-match to save time and energy. It doesn’t work. The point of a meetup is to have real human interaction, not for everyone to simply play their role.

So what should you do?

 2. Don’t play it safe with topics

This is a trap I see a lot of meetups fall into. Sorry fellow organizers, but it’s true. Tailoring your content for the group you have instead of the group you want creates an echo chamber. When I took over Boston DevOps, we were operations folks talking about tools. We made a conscious decision to start talking more about alignment. Now we have active members from all roles of the organization.

It’s a bad sign if no one is arguing at your events. Especially with DevOps, where we are trying to hash out the motivations and constraints different groups face. Debates are wonderful. We get a glimpse into the real world, where not everything is black or white, 0 or 1. To that end, an organizer should encourage respectful debate. This also means handling it when someone crosses the line.

If you’re living in an echo chamber, here are some suggestions:

 3. Vendors: Trust but verify

There are a lot of great companies out there producing software to make collaboration easier. You need sponsors for a meetup and these companies are a natural fit. We’ve had many representatives give presentations at our meetup. Sometimes it’s great - they give new ideas on how to think about the problems we face. Sometimes it’s not so great - a shameless product plug.

I think the most interesting takeaway here is that shameless product plugs will not endear you to the DevOps crowd. They are probably more damaging than helpful. Reputation is king in this audience - if you betray the trust given to you, the members and organizers of the meetup will remember.

Some ways I’ve learned to avoid this situation:

My intention with this post is not to pick on other meetup organizers. This is rather my account of how I see the tech community evolving from the inside. I’m really grateful to be a member of the DevOps community. The honest conversations about hard problems we face is the best part of DevOps events.

Of course I haven’t been able to do this all myself. I have a great co-organizer, Dave Fredricks (@dfreddy76), who is really in touch with the executive perspective and great at logistics. I also have a number of people that help me to identify useful topics to talk about. Thanks all!

 
25
Kudos
 
25
Kudos

Now read this

DevOps: The skills that matter

What skill set is desirable for an engineer in a DevOps organization? Let’s take a look. Surveying DevOps job posts, you need to be intimately familiar with dozens of technologies you’d never use in a non-production setting. Reading... Continue →