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:
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
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:
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:
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.
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.
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:
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
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:
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:
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.
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.
Ready to maintain secure and compliant infrastructure focused on cost, automation, and consistency?