Lucid’s core values include innovation, passion, excellence, and initiative. And we consciously find ways to ensure that teams live those values: when you come into our office, you can even see these words among other values painted on a wall as a reminder.
One of the ways we promote Lucid values is by hosting an annual hackathon. The hackathon is an opportunity to step back from the day-to-day and finally make time to concentrate on that problem you’ve been wanting to solve or that moonshot idea that might pan out to be something incredible.
Year after year, the hackathon has been praised as an event the team absolutely loves. Interns are invited to participate, and many have said it’s the highlight of their internship. Though the competitors tend to be exhausted by the end (because they choose to put in crazy hours), they also come back to work on Monday energized and excited. They talk for months about the projects and experiences they had during the hackathon.
How do you pull off an event that will produce great ideas and demand hard work—but also leave the team eager and excited? Take a look at a few of the lessons I’ve learned after holding an annual hackathon for five years straight.
1. Turn it over to the individuals
If you think that this is a time for managers and executives to push their ideas or get extra work out employees, your hackathon will surely fail.
For our hackathon, any ideas are allowed—and that flexibility allows our employees to really be creative and innovative. That said, anyone planning to host a hackathon should establish some basic rules. Our company has decided that:
- Teams cannot have more than six members.
- There will be no commits on master or sprintend (our production release branch).
- Teams cannot commit binaries to the repository.
- Teams are not allowed to write code for their projects before a set date.
Facilitate the process of people getting ideas and forming teams, but don’t dictate it. For example, we create a spreadsheet where people who have an idea for a project already can connect with those who just want to participate. We’ve never been short on ideas, and the vast majority of our product and engineering departments decide to join a team (including QA, UX, and PMs!).
2. Define judging criteria
Lucid is made up of talented, driven individuals—so it’s no surprise that our hackathons have always had a strong element of competition to them. We make it clear that there will be winners and significant prizes are at stake (for what it’s worth, we have tried lots of prizes but settled on Amazon gift cards).
But the desire to win, and the amount of smack talk that happens over those three days, is part of what makes the hackathon fun. In fact, Ben Dilts, our founder and CTO, famously (at least famously within the company) told the 2017 winning team that there was a “zero percent chance” of them succeeding on the project. But I dished it right back at Ben:
(After five years, our founder, Ben Dilts, was finally on a winning hackathon team!)
As you can probably tell, our employees take the competition seriously, and therefore, we need to be clear with them about the judging criteria so everyone knows what it takes to win. Our criteria, which has remained the same since our first hackathon, comes down to three elements:
- Creativity and innovation
- Value (or potential value) to Lucid
- Functional prototype (MVP, how realistic it would be to implement)
3. Choose your judges wisely
We let employees vote on the finalists for the hackathon, but the final decision comes down to a panel of judges. Choosing your judges can be tricky. Based on my experience, the best route is to select people within your company.
At Lucid, we started with outside judges—all great people with interesting perspectives. However, we received a lot of feedback that these judges didn’t have enough context to understand which projects were truly unique and which simply leveraged the existing features in Lucid’s code base. We even tried having Lucid executives sit down with the judges to answer questions, but we ultimately abandoned the use of outside judges altogether.
For the past three years, the judges have all been members of the Lucid executive team, and the complaints have dropped almost completely.
4. Make the hackathon fun
While a hackathon gives employees the opportunity to focus on the projects they are passionate about, it’s also a ton of work. We’ve seen employees camp out in the office or in their cars (some even set up tents) and operate on very few hours of sleep to make sure they finished on time.
So when planning the hackathon, we wanted to ensure that the teams still had fun (or least ensure that they ate). We always have a creative logo and theme song: “Thunderstuck” by AC/DC has been a favorite, but “Eye of the Tiger” and “The Final Countdown” also fit the mood. We provide dinner and snacks, and we take a ton of pictures.
5. Go all out for the final event
The final day of the hackathon is not only a celebration for the participants but a chance for other employees to see all that the teams have accomplished, so we pull out all the stops. This event lasts from about 3 p.m. until 8 p.m., and we invite all employees, including those who aren’t part of a hackathon project, and their families to attend.
A few thoughts on the logistics of the event: If you have 25 to 30 teams, you know you can’t do long demos, so how do you make sure that everyone sees each of the projects?
At Lucid, we plan about 45 minutes at the end of the hackathon for every team to give a one-minute pitch for their project, explaining at a high level what the project is. Then, we have science fair-style demos over the next few hours. Every employee can cast a certain number of votes to determine the final three projects. Each team puts together a display board (and many try to bribe voters with treats, stickers, and toy cars), and individuals can walk around and learn more about each project.
This agenda works well for us because teams don’t have to answer the same questions over and over again (they are answered in the one-minute demo) but individuals still have a chance to ask more in-depth questions about the projects they’re most interested in.
After the science fair, finalists are announced and given one hour to prepare a final five-minute presentation to the entire audience.
Aside from the competition itself, I’d recommend that you plan out activities for employees and their families once they finish voting and while the finalists prepare their presentations. If you need some inspiration, here are a few activities we had at our last hackathon:
- Dinner
- Cold Stone Ice Cream
- Magician
- Balloon artist
- Face painting
- Raffles for drones, a BB-8 toy, etc.
- Oculus with games set up on a big screen
One year, Lucid rented out a movie theater and held the science fair and all the presentations there. It was fun to see all the projects on the big screen, and we were able to watch a movie while the finalists prepared.
Finally, we announce the winners and also add in some fun awards, such as the “Make Diagramming Great Again Award,” the “Bears Beets Battlestar Galactica Award,” and the “Start Using Monday Award,” to make sure we recognize everyone’s efforts.
Why plan a hackathon
If you’re thinking all of this sounds like a lot of work, you’re right.
So why do we do it?
Personally, I think the hackathon has been successful for several reasons. It has given us many creative ideas that make it into the product (such as Feature Find) and opportunities to tackle difficult projects we wouldn’t otherwise find time for (such as converting 600k lines of code to TypeScript).
The hackathon has also helped us to create and maintain our culture here at Lucid. It all comes back to those core values—the hackathon pushes us to work with passion, excellence, innovation, initiative, and ownership. If these are qualities you want to instill in your employees, I would give it a try and see what your engineering and product development teams can do.
Brian Pugh, the SVP of Engineering at Lucid, has extensive experience designing, developing, testing, and deploying web applications. He has led development teams at many companies, including HP, Sun Microsystems, and FamilySearch.org. Brian holds a B.S. in Computer Science from Brigham Young University. He enjoys leading the Lucidchart team on strenuous outdoor adventures (biking, skiing, climbing, etc.) and seeing who can keep up.
No Comments, Be The First!