We just finished Raleigh's ninth DevOpsDays conference. In the years we’ve organized this conference, we’ve had some milestones - sold out the entire McKimmon center, have seen a ton of great talks, donated $10,000 to the kids over at Wake Ed STEM for multiple years, and it's again been a great experience. Huge thanks and props to our organizing team, especially the mighty Katie Cothran who takes point as our organizer lead.
I thought now would be a good time to reminisce on how we started DevOpsDays Raleigh in 2015. Next year will be our tenth anniversary!
If you visited from out of town and are considering starting your own DevOpsDays, learn from our lessons. We’ve gotten better as the conference has grown, but those original lessons hold true.
In the fall of 2015, Katie and I worked at a tech training firm called ASPE. We were developing a lot of learning solutions in the DevOps space and decided we wanted to host and market a DevOps conference of some sort. I had created and was directing ASPE’s Techtown division as a special project for emergent technology training topics and tools. That division had quickly become profitable and it was super clear that we were the only major learning services company who really "got" what was going on in the IT profession in terms of DevOps and the larger lean IT and many ”transformation” trends. Our curriculum on stuff like enterprise cloud engineering, automation, upstream decision making, integrated QA, shifting left, and all things DevOps was maturing. The timing was perfect for a conference.
We're a commercial business and at first we considered a for-profit DevOps type conference. But I had been attending the Triangle DevOps Meetup for almost two years at that point and it seemed like instigating a "real" DevOpsDays would be much more in the spirit of DevOps. Although we wouldn't be allowed to profit from a DevOpsDays, it would give us a lot of great exposure while showing people that the skills and values we endeavor to teach our customers really are aligned with the original DNA of the DevOps movement. I wanted to demonstrate that we could be proud of having built a valuable product which was worth paying for, but without avarice - in a way that maintained alignment with the values of the thought leaders who had informed (and still inform) so much of the content that we build for our customers.
I dropped a line to a contact at Chef, who in 2016 was one of the main Triangle DevOps meetup organizers, and shared the idea. Mark told me that I wasn't the first one to want to do DevOpsDays in the Raleigh area, and he connected me to Triangle DevOps members from Red Hat and IBM. It was just before Christmas and we got together for lunch. They had long been interested in organizing a DevOpsDays here, but had some hurdles that had prevented it.
It turned out that the main reason DevOpsDays hadn't already happened in our area was that these guys just didn't have the bandwidth to do all the administrative work it takes to put together a conference. Not surprising for a group of senior technologists. We explained that we organize events, classes and conferences all the time because it's just our job, so we would be happy to sponsor and do the legwork of organizing and marketing a DevOpsDays. We agreed to let the engineering experts on the team have full control over content and editorial decisions, speaker selection and such, and we would take care of anything administrative, including marketing and logistics etc.
We had to reassure the group that we were not looking to directly profit or use the list of names of people who attended for marketing. This was a pretty easy case to make, since the Triangle area is rich with large technology-driven companies who need learning services and the upside for us would be huge just by demonstrating our alignment with the local DevOps community and getting exposure for our firm.
We all agreed to work together, and DevOpsDays Raleigh was on. Over the next nine months we collaborated to organize and run the conference. From my point of view, if you are a commercial sponsor who also wants to be involved in organizing DevOpsDays, these are the most important lessons I took away:
The team is key. Putting together a DevOpsDays is a lot of work, and we all have day jobs. I can’t take any credit for how great our team was – in effect we got lucky that there was already an existing group of people who were already quasi-organized. Regardless, you have to have a team and teams operate on trust. In our case, the original conference advocates knew each other well, but they did not know us. We had to be blatantly honest and transparent from the start about our motivations and make sure they understood that we were OK with the not-for-profit model of DevOpsDays and why we’d want to do it anyway.
Stay true to the DevOpsDays format. DevOpsDays is specifically intended to be community-driven, relatively local, and for the benefit of the technical pros who attend. To that end, the sponsors shoulder the vast majority of costs, and tickets are kept cheap for the folks who attend. One of our key duties was to be the money-handler for the event. We proactively drew up a simple contract right at the start which assured the organizers that we would not profit from the event, and that if the event generated any profit we would be responsible custodians of it until the committee decided what to do with it. Any commercial organizer needs to understand this from the start, and make sure they protect the event from anyone inside their company who might be tempted to capitalize on their involvement in the conference in a way that isn’t appropriate (i.e. marketing to attendees or attempting to directly profit from the conference).
How our committee collaborated. We started out having meetings every other week to touch base on our progress. One of our committee members allowed us to use her Red Hat Bluejeans account for hosting online meetings. We used a set of Google docs editable by any of us to organize our goals, set milestones, develop and track the budget, and manage the conference agenda/speaker topics. We also used the docs just as a general repository for anything that came up (i.e. assigning volunteer tasks, making decisions about catering and menus and lots of other stuff). As the conference drew closer (like, 6 weeks away) we began to have meetings every week. We made sure we were clear about which committee member was responsible for which duties, and we tracked them constantly with our docs. Throughout the whole process, I don’t think we ever went over our 30-minute meeting slot one time, even right up to the date of the event. The people on our committee worked hard – especially Katie, who really put their shoulders into it and put in a lot of time making things happen. The engineering reps on our team were amazing at facilitating the content selection, communicating with presenters and submitting pull requests to update the DevOpsDays website. Katie spent many full work days on the conference in the weeks leading up to the event, and her office became a warehouse full of boxes containing swag, t-shirts, and so forth.
Keep everything transparent. Since we were very sensitive to the fact that we are a for-profit business heavily involved in a conference that’s not for profit, we were fastidious about keeping all the financials continuously updated and always visible to the entire committee. As I mentioned, we also proactively made sure we contractually bound ourselves to follow the DevOpsDays code of conduct and money handling protocol so we’d have a backstop guaranteeing good corporate citizenship in the DevOps community. Any budget decisions or stuff which required us to spend money, we always made sure we discussed with the committee and reached consensus before moving forward. Before every weekly check-in, we made sure the financials were up to date and we’d review them during the meeting.
Market your conference. We always expected that our event would probably sell out, but as I continually told our team, “We will have to take an active role in helping that happen.” We actively called on potential sponsors, and the team stayed in sync on who had contacts at various companies who might want to be a sponsor. Katie was also super-responsive and helpful any time we had an organization express interest in being a sponsor. In terms of people signing up to attend, there was a huge social and word-of-mouth factor to promoting the conference. We talked up the conference continually at meetups and user groups, and a lot of the folks on our committee were pretty well connected in the RDU tech community, so that helped. But we also advertised our DevOpsDays with a few PPC and targeted Google Adwords campaigns, a LinkedIn advertising campaign and some limited email marketing. We also advertised with our local public radio station. At the end of the day however, I don’t think any marketing activity we undertook was probably as important as just the social component.
Have fun and enjoy DevOpsDays! Our conference has been a success and I’m very proud to have been a part of it. Last week we took all our presenters and organizers out to a fun speakers’ dinner, and as I sat around a table full of eminent technologists and engineers, inventors of amazing tools (stuff you’ve heard of and/or probably use every day) it struck me what an honor it is to have been one of the organizers of an event like this.
If you’re considering organizing a DevOpsDays in your area, do know that it’s a lot of work and takes a lot of preparation – any conference does. But DevOpsDays is definitely a special kind of conference. I’ve been to others, but putting on our own here at home was immensely rewarding. As with pretty much any work that’s worth doing, the most important things boiled down to: a great team, a worthy cause, and people who were willing to work hard.
Thanks to everyone who helped execute and all who participated in DevOpsDays Raleigh 2024!