My First Hackathon

In every Mission: Impossible movie there's a montage set to suspenseful music where the heroes work tirelessly in sync with one another on various tasks in preparation of a climactic scene - technicians work on soldering a spy gizmo together, while another group translates a surreptitiously obtained laser-scan into a realistic face mask, while another group embeds outfits and tests a voice modulating throat harness, while yet another group embeds GPS trackers into the security ribbons of stacks of counterfeit $100 bills, etc..etc..

Such was my experience participating-in and watching six groups of my fellow Spreedlings over the course of two days as we held our first hackathon in recent memory.

It. Was. Awesome!

A hackathon by common definition is a social coding event that brings computer programmers and other interested people together to improve upon or build new software (techtarget.com). We used our hackathon to test out new ideas, work on system resiliency, "smash bugs", and drive forward automation supporting unattended autoscaling of our infrastructure.

We also used the hackathon to have a lot of fun. Across teams within engineering and throughout all edges of the company, folks that didn't always get together, did so. And with amazing results. (Sure, we had custom t-shirts, snacks, and an awesome read-out at our company all-hands the following week, but that's almost unimportant when I compare it to the camaraderie I witnessed, and the innovation and creativity that was unleashed within a focused time and encouragement to do so).

It's been a few weeks since and I'd like to share some thoughts on our approach in the hopes that such an event can work for you too.

Topics - We crowdsourced our hackathon topics in slack several weeks leading up to the event, and voted on them to prioritize which ones groups would be willing and most want to work on. While some hackathons might set out a singular and more open-ended question ("What can we do with Big Data?"), our first hackathon took a more timid approach, focusing on known problems and opportunities for which engineers had been "itching" to work on but never seemed to get the time.

Planning - The hackathon is so much more than the 2 days of the event itself. With topics selected and groups formed, we setup dedicated hackathon slack channels and used confluence as our teams' notepad, jotting down ideas, garnering support for possible approaches, and doing the "prework" -- research that made the actual event much more productive. (Nobody really wanted to spend the event watching me setup my dev environment, for example...). There's also a huge logistic component to ordering and shipping custom swag to participants that can't be overlooked. (Thanks, April!)

Flexibility - Our hackathon was completely virtual. We created a world in topia.io and used it as a meeting point with separate rooms for folks to gather. There was a central dance floor that played music (I left it stuck on "Gandalf Sax", unfortunately) and topia has this neat effect that the closer you are to folks, the more you can see and hear them; as your avatar walks away, sight and sound diminish. I'd like to say this was wonderful but in reality, well, it just didn't work for us. No fault to topia but it was too much glitz when what we really needed was just a bunch of zoom meetings, so most teams defaulted to that instead and used topia sparingly. Oh, well - no need to dwell. Just adapt and move on.

Autonomy - Beyond every topic having a team champion, the scope & organization of work, sharing & selection of ideas, and deciding what to present and in what format was left to each individual -- the best thing management could do was to stay out of the way. Trust that the "teams got this". And of course, each team did.

It turned out, there was a little bit of hackathon in each of us, all along.

Best Lesson Learned - This may be different for every participant but for me, the most important lesson learned was that it turned out there was a little bit of hackathon in each of us, all along. Perhaps we don't need a hackathon event every quarter for people to realize and deliver on their unique talents -- they just need focussed time, opportunity, and the encouragement to innovate and be creative.

That's my job going forward - yes, of course we're going to continue to have hackathons - but how can I ensure everyday that folks get the time they need, a network of people to connect with, the chance to exercise creativity using their unique talents, and a safe space to recognize and drive innovation without judgement.