Last Friday, our engineering teams spent the whole day on a Hackathon.
Traditionally, a Hackathon is a collaborative coding event where developers come together to solve a problem by developing new software or improving existing programs. Like many great pieces of dev culture, Hackathons came out of the open source community, and the first was hosted by OpenBSD in 1999 in Calgary, Canada. Hackathons give new and experienced engineers the opportunity to stretch their skills, think outside the box, and occasionally spark out-there ideas that lead to hugely successful ventures.
It’s that spirit of creativity and collaboration that leads companies to run internal Hackathons for their teams. The general premise is that your team gets a full day off of their current projects to work on something new and exciting. They can work alone or in teams, and the project can be inspired by a problem they run into regularly and want to solve, or a fun idea that they come up with day-of. The goal is to get engineers reinvigorated, inspired, and excited - and maybe come up with something valuable or useful.
While a Hackathon day isn’t a new idea, it was the first time we did one at Sicura, and the first time I led one - and the outcome was great! Our team returned to work this week energized, motivated, and engaged. Here are some tips for running a Hackathon day for your team:
Make the Time
It’s easy to come up with a long list of reasons NOT to spend a full work day on a Hackathon. “We’re too busy. We can’t spare the time. We have deadlines!”
What people don’t think about is that the morale and happiness of your employees has a major impact on how much work they get done. If you give them the chance to do something exciting and interesting that re-energizes them, suddenly they’re going to get a lot more done.
The need for lightness and fun and enthusiasm on engineering teams is a topic that’s getting more attention in recent years. Companies are realizing that you don’t need foosball tables or fancy snacks to motivate your people - you just need to create room for flexibility, creativity, and yes, even fun. Employees who are energized and engaged, empowered to spend brain time on the things that intrigue them, are going to be more effective and productive.
The Miro board we used to plan & explain Hackathon Day
Build a Few Guardrails
Create and share ground rules with the team in advance of the Hackathon day. You need to thread the needle of structure and flexibility. I knew if we had no rules, some folks on our team might go work on completely personal projects. But I’ve also heard of companies that make the requirements for a project's “marketability” so burdensome that it defeats the purpose of a Hackathon. You need enough flexibility that someone can come up with a moonshot idea that actually has the potential of being fantastic and profitable. Clear ground rules keep everyone in tune with your actual product, team, and long term goals - but also keep it vague enough that people feel safe to have weird crazy ideas and run with them.
A very important rule is that folks cannot work on current sprint work. The whole point is to get away from what you’re currently working on - you need to take a day away from that gnarly problem or tedious testing, to change your brain!
Our ground rules were:
- Must be “Sicura adjacent”
- Must be something you’re excited about
- Explicitly NOT in the current sprint or milestone
- Does not need to be in the backlog or a current epic, but can be
- Only work on your project during Hackathon day (8 hours!)
- Work alone or in teams - to be formed during morning scrum
- There are no bad ideas - nothing will be rejected, as long as it follows these rules!
Have a (Light) Plan
There’s a real balance here between structure and flexibility. I kind of winged it, and it worked. In retrospect I wish I’d been slightly more prepared to explain the concept and rules to the team. But, I do think the squishiness made the team feel more ownership over the day.
We followed this structure for the lead-up, day-of, and follow-up:
- 1 Week Out: Floated the idea of a Hackathon day to the team. They were really excited, so we prioritized putting it on the calendar soon. Team members started discussing possible projects among themselves, but the specific rules were still pretty vague.
- 2 Days Out: Shared more details with the team during our sprint retrospective. We listed out the ground rules and had everyone vote on a few options for date and format. This gave everyone 48 hours to brainstorm project ideas.
- Day Of: We started the morning with our usual standup. We used a Miro board for folks to write their projects and others to join in. In 20 minutes, everyone left the meeting and started working alone or in small groups. We had everyone use public slack channels and Huddles so others could pop in and follow along. The teams worked straight through the day. I popped into various huddles off and on to check in, help if necessary, and keep the enthusiasm up.
- Next Week: We hold lunchtime every Monday for a Brown Bag, for anyone on the team to deep dive into a topic. The Monday following Hackathon day had no topic, so we used that time for each team to share their progress. Originally I’d thought the team would want to do this sharing and recap at the end of the hackathon day, but they voted to work straight through EOD and share a few days later.
Be Prepared to be Surprised
Once you’ve laid the groundwork, you need to step back and let things flow. Whatever you’re expecting to happen, it probably won’t - but something better will. Folks worked with team members they don’t normally work with, on topics I never would have predicted. Someone on our team said, “I’m actually really excited about the project I started earlier this week - so I want to spend today on that!” One of the Hackathon projects was a clicker game that exaggerates the processes companies go through for security benchmark compliance - seems silly, but now our marketing team is really excited to have it set up at conference booths!
I went into the Hackathon day with the goal of getting the team out of the doldrums and excited about building cool programs, so for me, the projects that were developed were just a bonus. But the team was thrilled to have time to work on backlogged items or annoying bugs that they don’t normally have time to fix.
Know When It’s Time
I knew it was time to inject some fun into our team just by listening to them. During daily scrums, retrospectives, and our weekly wellness meetings, I could hear that our team was beaten down by months and months of testing we’ve had to do for the last few sprints. That slogging through time and again had zapped our energy.
In the week since our Hackathon, I can tell the energy is back up. Everyone enjoyed themselves and was excited. The team is already excited to do it again. We’re going to build it into a regular cadence - at least once a quarter, if not more.
If your team is burnt out and you want to get them jazzed about engineering again - or if you want to foster a more innovative culture and maybe spark your company’s next big win - dedicate a day to letting your team run wild and remember why they love what they do.
Interested in invigorating your IT and engineering teams by taking manual remediation of compliance issues off their plate? Get in touch to learn how Sicura can automate compliance so your teams can get back to work.