Running Hudl’s first engineering conference

Two weeks ago, we held our first conference for around 70 of our ~100 engineers and data scientists. We decided to call it “BitsConf”, a reference to our internal education program for engineers, “Bits”. The conference was a natural extension of this initiative; it allowed members of our growing engineering team to learn more about the work others are doing and the technologies they’re excited about. Hudlies gave presentations on diverse topics like the advantages of Docker for local development, applying generative adversarial neural networks to sports video, and thinking about work as platform development rather than feature development. It was a huge hit:

“I went into BitsConf with pretty high expectations, but it was still even better than I expected. It had the atmosphere of a conference, but all of the talks were relevant to me in some way. I hope we do more in the future.” — Eric Clymer, Senior Engineering Team Lead

We took inspiration from this excellent blog series by Klarna on running developer conferences for a team and scaled it back for our smaller group. In under three months, we managed to plan, execute, and collect feedback on our first conference. Below, I’ll walk through each of those phases. You can think of Klarna’s series as a reference manual and this post as a retrospective.

Dates and Signups

The idea to host an engineering conference for our team came from one of our engineering team leads, Mike Isman (thanks, Mike!). He sent us links to the Klarna blog series and talked me through some anticipated benefits and outcomes. We began planning the event during the first week of October. We were lucky enough to have quick buy-in from engineering leadership:

“BitsConf just makes so much sense for Hudl. It is an opportunity for individuals to share their passions, level up each other, and build excitement across developers.” — Brian Kaiser, CTO

Before anything else, we needed to know when we were going to host the event. Confirming the date as early as possible — and placing it on engineers’ calendars — allowed us to minimize conflict with other company events and team activities and give people ample time to plan travel to our Nebraska headquarters if they wanted to attend. We quickly settled on a date the same week as our company’s quarterly retreat, given that the highest number of engineers would already be in town.

After determining the date (which was only two months away!), we needed to quickly determine headcount to give us rough numbers for venue, food, and swag. We locked in attendance and solicited presentation proposals using an online form. Signups and the call for presentations (CFP) ran for a week and we decided on the final set of presentations shortly afterward.

Note: While the CFP was running, I proactively reached out to some Hudlies that seemed like good candidates for presentations and encouraged them to submit proposals, which paid off immensely — we had fifteen 30-minute presentation submissions for only eight slots!

Setting the Agenda

A rough agenda was necessary to choose the right number of presentations for the day. We knew we wanted to have a keynote, some blend of 30-minute sessions, 5-minute lightning talks, and panel sessions with breaks and a happy hour. Being the first year of this conference series, we decided to keep it simple and run it as a single-track event. Here’s where it ended up:

• 7:15–8:15 a.m.: Breakfast and welcome
• 8:15–9 a.m.: Keynote
• 9–10:10 a.m.: Sessions (2)
• 10:10–10:20 a.m.: Break
• 10:20–11:30 a.m.: Sessions (2)
• 11:30 a.m.–12:45 p.m.: Lunch/Catch-up time
• 12:45–2:30 p.m.: Lightning talks (6), sessions (2)
• 2:30–2:40 p.m.: Break
• 2:40–3:45 p.m.: Sessions (2)
• 3:45–4:30 p.m.: Panel Q&A
• 4:30–6 p.m.: Happy hour

Based on this agenda, we gathered a group of judges together the day after the CFP deadline to evaluate presentation submissions and decide on the layout of the day. Our judges had a wide array of expertise, from front-end and mobile development to data science and infrastructure, to ensure every proposal stood a fair chance. Each judge submitted their ideal agenda for the day as a vote and the presentations with the highest number of votes were chosen (although we had to re-vote a few times!).

Venue

Once we closed signups and determined rough numbers — based on signups, as well as the number of engineers in our Nebraska offices — we were able to start working on two more items off the planning list: venue and event swag. Our initial inclination was to host the event in our Lincoln headquarters, but we quickly realized a few things:

• Our headquarters would barely fit the number of engineers we were expecting in any single space
• The spaces that did fit our attendees had poor presentation setups (in terms of A/V and room arrangement)
• The headquarters was too disruptive a space for the event — it wouldn’t feel like the team was at a conference, but rather sequestered off for an all-day meeting

Taking these into account, we started looking at other options like hotels and event centers. We eventually decided on a conference room in a hotel across the street from our HQ for a number of reasons:

• We could use a conference room that was designed for a group of our size and set up well for presentations
• Being near HQ in a separate space would help maintain the conference vibe while allowing people to go to the office for urgent work
• We could easily provide breakfast via the hotel’s standard breakfast for guests (and only be charged for the number of people that ate!)
• A number of our team members were already staying at the hotel and wouldn’t be charged for things like breakfast
• We could take advantage of our office’s catered meal over our lunch break, rather than spending money on lunch for attendees, freeing up our budget for other costs
• We could easily host a happy hour after the event in our office instead of booking a bar or restaurant

Event Swag

It wouldn’t truly feel like a tech conference without a little bit of swag! From day one, we knew we’d need to budget some money for event gifts and researched a few options. We wanted to have at least one exclusive piece of swag to make attendees feel special for coming to the event, with a few supplementary items to round out the offering.

We decided on t-shirts, feeling they were the most exciting gifts we could give for the cost and were great conversation topics in the office. One of our marketing designers, Kevin Buglewicz, helped create an identity for the conference and designed t-shirts for us. They were a huge hit — we even had people outside engineering asking for shirts after the big day! We also gave out Hudl pens, stickers, and phone wallets to all attendees.

Rehearsals and Coaching

A large part of planning BitsConf was making sure every presenter would be ready for the event. There was a wide range of experience in our speaker pool, so it was crucial to provide the right amount of guidance and help people feel empowered. We put a couple fixtures in place to make this happen.

First, we sought out a number of “presentation coaches.” These were Hudlies with prior experience speaking at meet-ups or conferences. They could provide guidance on specifics for your presentation or give you feedback on its delivery. These coaches were involved early on, making themselves available to help people with their CFP submissions, and remained involved until the day of the conference.

Second, each presenter had a designated mandatory rehearsal the week before the conference. This gave them the chance to run through their presentation, time it, gather feedback on content and delivery, and ask any questions about expectations for the day. All of our presentation coaches signed up for one or more of these rehearsals, and I sat in on each one to be available for questions and feedback.

Recording the Event

The final logistical piece to nail down was properly recording the event. Hudl’s engineering team works across many offices and remote locations — Boston, London, Sydney, New York, and California, to name a few — so making the day’s presentations available after the fact was important to us. We also wanted to have these recordings for people to reference later, freeing them up from taking notes throughout the conference.

It was decided early on that live streaming the event would be too much of a logistical burden, primarily due to limitations around quality of internet and our video capture setup. Instead, we focused on trying to create a good setup for recording sessions. We set up a video camera and lapel microphones to record the presenters themselves, using a capture card to capture each presenter’s presentation while they used their own laptops. After the event, we stitched these recordings together and shared them out to the whole team.

Results and Feedback

After all the planning and legwork described in the paragraphs above, conference day finally came. The hard work paid off in a big way (though I might be a little biased!). A few of the highlights:

• Presentations were well-delivered, well-paced, and featured a diverse set of content — some got people excited about new tech, while others gave people food for thought about how they solve problems or interact with each other
• We were able to internally publish a recording of every presentation with picture-in-picture video of the presenter and their slides
• The most we ran behind was five minutes, and we even ended the day early, thanks to giving ourselves five minutes of setup time between each presentation
• We ended up more than $600 (almost 30%!) under budget, in large part due to savings on breakfast being charged per-person, rather than by volume
• We sent a feedback survey to all attendees — the average 30-minute session feedback score was 4.06/5, the average lightning talk feedback score was 4.03/5, and the average conference feedback score was 4.19/5!

Of course, we took many lessons away from the day:

• Projector contrast and lighting made slides and demos occasionally hard to see for both the speakers and audience; using lighter themes for code samples and sharing out slides can ease this pain
• Differences between rehearsal and conference A/V caused hiccups during some presentations — rehearsals should be done on A/V as similar to the true setup as possible
• The logistics of switching laptops between every presentation is painful and not worth the cost for lightning talks, which are least likely to have a live demo component
• We could have recognized presenters for their effort through gestures like special t-shirts, badges, or a speaker dinner
• Though we had diversity between high-level and highly technical presentations, there was a lack of content in some areas of our stack (eg. front-end and mobile) — potential speakers in those areas could have been approached more proactively
• The timing and structure of feedback surveys is critical; every hour between the delivery of a presentation and collection of feedback diminishes the quality of feedback given, and surveys need to set people up to give great feedback on every talk

The biggest takeaway was that this event was undoubtedly worth our time. It energized our team, helped them gain a broader understanding of the engineering work being done at Hudl, and got people excited about our future. This year was just the tip of the iceberg — I’m thrilled with the results and ready for us to start planning our next event.

Interested in being part of a team that hosts awesome events like this? We’re hiring!