How to Host a CodeFest/Hackathon: Part 2

Previous Posts in this Series

• How to Host a CodeFest/Hackathon, Part 1: Why Have a Hackathon?

Answering Questions in Advance

So last time I hopefully convinced you that you should at least consider having an internal company hackathon, or as we call it here at Aviture, a Codefest. But before we really get started, you have to flesh out enough of the details that you can get yourself excited, and so you can actually communicate the idea to everyone else! And believe me, they’re going to have a lot of questions. Here’s a couple big questions to ask yourself that should help you get the structure of the event settled:

First, ask “What do you want out of this event?”

Why are you holding it? Do you want to have usable projects at the end? Are you pushing for learning new technology, so the end projects might be kind of haphazard and sketchy, and not get as far as the developers wanted? Do you just want to encourage camaraderie, and you don’t care what the outcome is? Do you want to only have code projects, or can people do a project in the real world that changes the office? Like we talked about last time, all of these are valid desires to have a hackathon, so it helps to know which of them is the most important to you. If you can figure out what the end result of the event should be, it really helps to fill in the gaps for everyone involved. Make sure you can communicate that end result well.

Second, ask “What does the event look like?”

There are a lot of ways you can run a hackathon. Do you want everyone working on one big project? Or a bunch of small ones? Is everyone building different solutions to the same problem? Or are they each tackling their own? Is it one day, or multiple days? Are you doing this on-site, or are you all going somewhere off-site to jam on code until the wee hours together? You already know what you want the output of the event to be, so some of your answers should fall naturally out of that - you’re not likely to get marketable products out of a single day of development, for example. So figure out a rough idea of what you want to do, and be ready to explain why you picked that format.

Next, ask “Who do you want there?”

Is this just for developers? What about architects? What about UX? QA? Will you let even business development people participate? You can do a hackathon with any combination of these, so you should think carefully about it. Money’s going to be a consideration, naturally. So is scheduling - the more people you include, the more likely it is that someone’s going to have a conflict and be unable to participate. And some projects won’t be interesting to various groups, so the more diversity you have the more you have to broaden the scope on what a project actually is. On the other hand, the more people you involve, the more you can be surprised by what everyone comes up with!

Last, ask “How big should it be?”

The answer to this is going to be dependent on your answers to the first three questions, naturally. But if you know what you want at the end, and you know the format, and you know how many people are (hopefully) going to participate, you have a pretty good idea of how big the actual event’s going to be.

Recruit allies

As you work through this process, you might find it helpful to recruit a couple coworkers who can help you hash these things out. It can be difficult to answer everything yourself, and one or two people to bounce ideas off of and to help you create an event that’s unique to your company can really be a huge benefit. A problem shared is a problem halved, after all. That said, you probably don’t want to involve more than three people (including yourself). More than that and it starts to be hard to even find time to get people together, let alone actually making decisions.

What Aviture Does

I’m not going to say that Aviture has figured out the perfect way to run these things - we’ve only done a few, so we’ve only had a few times to experiment with different options, but if your head is swimming with all the options and you just want me to tell you what we do, here it is:

• A three-day event, sometimes consecutive and sometimes spread out
• Everyone submits their own project ideas, sometimes with a theme to guide them
• Once projects are accepted, the project owners go recruit a team
• Everyone can participate (even the business people!) - except the C-level employees, to avoid the appearance of favoritism
• The output has to be something that Aviture can really use, either as an improvement, a new feature, or a demo to show something off (even if that something is Aviture itself)
• The project needs to include some element of risk or innovation, but with some initial research or work to offset that risk
• We seem to have arrived at a sweet spot of 2 Codefests each year
• It’s up to each team to decide when they show up on the day of the event and how long they work during those days

Convincing Your Boss

Now that you know the rough shape of the event, we can work on convincing your boss. This can be tough! The first advice I have for you is probably the most important - don’t just fire off an email to your boss about this! Take what you’ve developed using the thoughts above and whip up a presentation with your arguments. Then arrange to be on your boss’ schedule, and get in front of their face! It’s a lot easier to let your passion for the idea show through in person, and they’re way more likely to respond to that than they are a bunch of text containing reasoned arguments, even if those arguments are good.

As far as good arguments go, I suggest you start at one that everyone loves - innovation. A hackathon, as I said in the last post, is a great place to be risky and try something that might fail. If it succeeds, it’ll often provide something innovative and cutting-edge that will help set your product or company apart.

If that avenue doesn’t work, you can try arguing about the effects on the culture. Hackathons re-energize developers, and refresh them from work on the applications and technologies they spend every workday with. During the first Codefest, Kathy Underwood (Aviture’s CFO) commented that “you could hear a pin drop” in the office; the teams were that focused and heads-down in the work they were doing.

If your boss is the kind to be convinced by personal testimony from somebody experienced and trustworthy, here’s a quote from Jerry Koske (Aviture’s CTO) about the event:

The Hackathon events at Aviture have significantly influenced innovative thinking within the company. Beyond focused engagement created through solving new and interesting problems, collaboration between individuals that infrequently interact lasts far beyond the event. This has created a palatable increase in sharing of solutions and ideas across the organization. I highly recommend Hackathons as both a team building and innovation promotion tool. ~ Jerry Koske

There’s also the argument that a lot of other companies run their own internal hackathons and find that they see a lot of value as a result. AngelHack helps companies run corporate hackathons, and you can just look at the list of companies that they’ve done this for and extrapolate to how many companies must be running these on their own initiative.

You can also make an argument that a hackathon built around improving or innovating on an existing project is a great way to see some dramatic improvements when your boss is probably used to only seeing features appear incrementally. From their perspective, the output from the hackathon will seem like it showed up almost overnight (and in fact in some cases, it might have). You can also make sure you mention that you’ll schedule around the deadlines and timing for whatever projects your company might have going on at that point. We’ll talk about how to do that later, but for right now we can use it as a way to assure your boss this will have minimal impact on the things your company’s already agreed to do.

Worst case, if none of that works, you can try doing the entire event as extra-curricular - see if your boss will agree to just let you use the office on a weekend, and start from there.

Convincing Your Coworkers and/or Employees

Compared to convincing your boss, this one could be pretty easy. Step 1 is to make sure the hackathon is paid time. Aviture finds that works pretty well.

Now, maybe that’s not in the cards for you and your particular event. All hope isn’t lost! You can structure the event so that people can submit ideas and projects, so they have the chance to work on something they care about, which will go a long way. You can also work on making the event fun - if you can’t get paid time, maybe you can get the company to spring for some pizzas for the hungry attendees. Maybe you have enough money laying around to get each team their own special hats. Maybe you can just find some speakers around the office and crank up the tunes. If it’s fun, people will let loose more, relax more, and hopefully attend more. It might take more time to build up your attendance this way, but it’ll pay off in the long run.

Be Ready to Clinch the Deal

What’s going to seal this deal and make your event actually happen is commitment. If your boss raises a concern you’re not ready for, take the time to consider the concern, address it, and have another meeting with your solution to it. If anyone has individual concerns, schedule follow ups with those people. If your coworkers or employees are generally uncertain about whether this thing is going to be good and fun or not, words won’t do much - your follow-through on the next steps is going to be what convinces them. Commit to the idea and do what you say you will, and people will come along with you for the ride.

So… What’s Next?

Hopefully everyone is on board now! In the next article, I’ll give you suggestions on how to lay out the submission process and what to consider when accepting projects. So stay tuned!