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?

• Take time to greet new members. Have them stand up and give an introduction at their first meetup. Scary, I know, but putting a name to a face is key here.
• Go the extra mile to invite and welcome non-engineers.
• Treat every interaction as unique. In a crowd, err towards having real conversations with a few people rather than a sentence with many. Don’t scan the room when people are talking to you.
• Prefer presentations that follow a learning curve. Start out basic and dive deep at the end. “X for beginners” is not a good presentation for a whole room - break that out into an open space.

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:

• Prefer topics that are not cut-and-dry. A Docker tutorial is good, but a roundtable on deploying Docker is better.
• Invite someone from outside your field to speak at your events. Their perspective is valuable.
• Cross-promote your event in creative ways. Go to a project management or IoT meetup, talk to people there about coming to your next event.
• Vary your format. It’s easy to get into a comfortable pattern. Hold some panels and open-space discussions.

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 willremember.

Some ways I’ve learned to avoid this situation:

• Set expectations in your first conversation, e.g., vendor pitches are not allowed and be consistent with everyone you talk to. No special treatment.
• Unless they are talking about the role of sales/marketing in DevOps, the presenters should be practitioners.
• The mailing list is sacred. Don’t hand it over, even temporarily. Set this rule early and stick to it.

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!