Inviting Innovation. Running Hack Days at UCF’s Center for Distributed Learning.
In early 2011 I got the go-ahead to begin planning a Hack Day event. Our Assistant VP of Distributed Learning had heard about the success of Atlassian’s Shipit Days, and wanted to create a similar event here.
It was a glorious day. Me and my small team of student web developers had frequent conversations about running one ever since we’d heard of Google’s 20% time. Like teenagers imagining the adventures afforded by a driver’s license, we would imagine our selves solving all of higher ed’s problems. Pictures of late nights filled with high-fives, mind-blowing technology, Lazy Moon Pizza and gallons of caffeine danced in our heads.
We knew this would be great. We just couldn’t convince anyone to dedicate a week of our department’s time to the idea. Honestly, that is a hard sell, especially if you’re in an “enterprisey” environment. We just didn’t have the persuasion skills to convince our managers to sign off on that many hours of unknowns. Fortunately that all changed, and we got started something that’s become a fruitful tradition.
How We Run CDL’s Hack Day
Born out of industry leaders like Google, DropBox, and Atlassian, we created hack day to scratch a collective creative itch. It’s proven to be a great way to systematically create innovation and increase employee satisfaction. Great things.
Spirit & Intent
Sure, hack day events were born in software development teams, but the concept applies to all types of work (you may have to work at it). In any office on any given day there are really useful ideas that end up on the cutting room floor. Your teams have amazing new ideas that require incubation and resources not available from day to day.
Hack Day is about giving those ideas room to grow.
Who Participates?
Everyone. Again, the concept fits naturally with engineering and IT staff, but it can be adapted to work for everyone. In fact, when I started, many of our non-technical staff had a harder time getting into the headspace of Hack Day. I received quite a few questions like: “So, what do I work on?” and “Can I do this one specific thing?”. I found that having an open group discussion settled everyone’s fears. Some basic questions help get that conversation started:
- What’s the most recent project you had to abandon?
- Have an idea for a project that you can’t finish alone? Maybe something you wish another team was doing?
- Do you have an idea for something that can help you or your team work more effectively?
- Is there some project everyone’s been avoiding?
Everyone really can participate, but not everyone does. Be sure to build an environment where participation is encouraged and enjoyable, but not mandatory. Mandatory fun… isn’t.
Different jobs will have different capacity to participate. Part time staff likely won’t be able to work a whole day (we have quite a few). Unavoidable tasks pop up from time to time. That’s all fine. Don’t avoid implementing a hack day just because portions of your staff aren’t able to participate. Adjust the expectations and allow people the freedom to move in and out.
Choosing Dates
We’re a university, so our lives revolve around the semester. Three times a year has proven to be just few enough that we want more, and not so many that anyone is overwhelmed.
When scheduling, I attempt to avoid critical dates, but you are never going to get a date that’s perfect for everyone. Don’t sweat that too much.
All days of your event should be consecutive. We typically run our hack day on Wednesday, with our presentations on Thursday before lunch. If the presentation is too late in the day, you can assume quite a few people will be finishing up their project that morning.
Logistics & Management
The minimum amount of work required to run an effective Hack Day is not daunting. Shorter events (like our 1 day event) are easier to run often.
Make sure everyone knows about the event:
- Send calendar events a month ahead.
- Put up fliers
- Send a reminder email 1 week ahead.
If you have hourly employees, let them know what to expect from the beginning. Will you be paying them for every hour they put in, or just a normal day’s hours?
Kickoff
The kickoff is held first thing in the morning on the first day of the event. The main goal of this meeting is to make sure everyone knows what they’re doing. Go around the room and have everyone explain their project ideas. This is an opportunity to gather a team, brainstorm, and share extra project ideas.
It’s completely normal for some people to have no idea what to work on. This meeting is usually about 20 minutes for a group of 15–20 participants.
It’s also pretty common that repeat participants will skip this meeting in the future. Encourage participation so those with less experience can join an experienced team.
Hack Day
The main event! Initially, we reserved a large room for teams to work in. We soon realized most of our office preferred to work from their desks. This is actually perfect for those offices where employees can’t abandon phones or other critical duties. The only downside is it makes the event look a un-eventful. Many members of my team use the opportunity to work from other locations around campus. As much as possible, give your teams the flexibility to detach from the normal day-to-day and really focus on their ideas.
Quite a few participants end up taking their work home. I’ve found myself polishing a UI or finishing up a few slides pretty late into the following morning. This is ok, but not something we necessarily want to encourage.
Showcase
The showcase is where everyone shows off what they were able to build. Before each presentation, I have the presenter write their team’s names and project in a table drawn on a whiteboard. Teams get a strict 5 minutes to present with a projector and laptop if needed. We have no rules about the presentations besides the time limit. You don’t even have to have a finished project.
After everyone presents, attendees mob the board with a bucket of dry erase markers to vote on their favorites. Anyone can attend (even non-participants), and all attendees can vote. I give everyone 3 votes to make sure everyone can vote quickly without too much anxiety. As a nice bonus, I find this generally guarantees no project ends up with zero votes. The whole thing is pretty easy to manage, but you do need someone guiding the event to make sure everyone knows what to do when.
Winners
Over the years we’ve been running Hack Day, we’ve generally tried to hand out achievement trophies of one kind or another. In the beginning it was a magnetic badge. That evolved into a digital badge issued by the University. Now, we’re toying with the idea of 3D printed badges.
Prizes aren’t necessary, but they are valued. If you can afford something, try it out. It doesn’t have to be a trophy either, your options are open to whatever you can get away with. Some ideas: Bonus time off, tickets to an conference or event, gift cards, books, office equipment, or even dinner and a movie. The bigger the prize, the more competition you’ll see.
Here, we’ve keep the whole thing pretty low key, and that has it’s benefits. Instead of striving to win the game, we’ve seen teams focus on their passion. I’m pretty happy with that.
For the Record Books
Catalog these awesome projects! If you don’t start now, you’ll wish you did. My early record keeping left much to be desired. I spent quite a bit of time piecing together old events and projects. No fun.
Save yourself work in the future. Have your project teams send you assets (screen captures, videos, docs) after the presentation to add to your catalog now.
Make sure you publish the projects and send the results out to the whole organization. Getting people talking about the event is a good thing.
We created this Trello board where we keep each project. In fact, we use Trello to plan out upcoming projects, it fit’s the purpose perfectly.
Feel free to contact me with questions, I’d love to do whatever I can to help you start a Hack Day at your own organization.
