Agitating for Innovation
A little over a year ago, I sat down with Mark Griffis and Jerry Koske (Aviture’s President and CTO, respectively) to make my case that Aviture should have an internal hackathon. I had a Powerpoint presentation all ready to go, a head full of ideas about how awesome it was going to be, and some pretty high hopes for the end results. I came out of the meeting feeling luckier than ever. Mark and Jerry are just as nuts about innovation and exploration of ideas as I am, and I got the go-ahead to put the event together.
I tell you this because Aviture recently had its second hackathon - which we’ve internally branded “Codefests”, on account of the potentially negative connotation of the word “hack” - and the event was a major success. With two of these under my belt (and a third in the planning) it is clearly time for me to dispense wisdom to you, the reader, on why you should be doing things exactly my way.
I joke, of course. But I do feel like it’s worthwhile to make the case for having a hackathon, the same way I made the case to Mark and Jerry. The obvious question there, though, is why? Why go to the effort - and why do this at all?
What even is a Hackathon?
Let’s start by clarifying exactly what I mean when I say “company hackathon”, because the term has been used to cover many different types of events. In a company hackathon, the employees of the company stop working on their day-to-day tasks and instead design and implement a prototype of an idea more or less from scratch. There are lots of different ways these events can work: everyone could be working on different solutions to the same problem, for instance. Or they could be working in small teams on new product prototypes. They could be learning new technologies, or using old familiar ones to get farther. The hackathon could last for days, or could be a single afternoon.
In my view, the defining aspect of the company hackathon is that the things you are building - be they product ideas or solutions to a proposed problem - are generated by and campaigned for by your company’s employees. That’s the most important thing to me, because people are quite naturally more attached to their own ideas and solutions than anything someone else could dream up. With that important criteria set, the actual format of the event can really be whatever you like.
How is this different from a “Ship-It” day?
Ship-It days, popularized by Atlassian, are very similar to a hackathon - the primary difference is that a hackathon is more structured. That makes it a little less organic (and a little less flexible as far as the output), but in return that structure helps you run the event and helps the participants know what they’re in for up front. It also makes it easier to sell to your boss, if you’re pitching this upward!
Okay, but who pays for this?
That is a very fair and important question. I believe that to get the full benefit out of a hackathon, the company really needs to be paying for the time. That solves two problems immediately: first, it eliminates the rather thorny question of who owns the intellectual output of the hackathon. Secondly (and arguably more important) it solves the problem of getting people to actually show up. It also sends a very strong message that innovation and camaraderie is something that the company is willing to actually put money towards. If you need ammunition for the idea, you can point at Atlassian itself. Or if you want to go old-school, you can point at 3M, whose ubiquitous Post-It notes were created using the company’s “permitted bootlegging” policy.
If you can’t manage to convince people, see if you can get enough people to participate on their own time. That might be hard, but if you can hold the event and demonstrate the benefits, it might be easier to get someone to find a charge code for it.
Why have a hackathon? What are the benefits?
That’s the real question, right? Why did I go to bat for the idea in the first place? Why should you go to bat for the idea? I think there’s three big reasons why - two of them concrete and immediate, and one of them vaguer and more long-term, but arguably more important.
-
Communication and cameraderie. In the two Codefests we’ve had so far, the benefit people have talked the most about was the chance to work with coworkers they’d never had a chance to hang out with much before. The reality of having to allocate employees across available projects means that if you work at a company that’s larger than a handful of people, you’ll almost always have someone you’ve never had a chance to work with. And when you work with new people, you both learn new things, and you strengthen your common goals as employees! It’s as simple as that.
-
Restoration. Aviturians also really loved the chance to take something that matters to them and try to turn it into reality (or as much reality as the time allows). There’s a real energy in working as hard and fast as you can to get as far with an idea as you can - it’s kind of paradoxical, but a sort of strenuous effort like that can actually leave you more refreshed than if you took a week-long vacation (especially if the vacation required you to fly anywhere) .
-
Risk. This here is the thing that I think is most important. Hackathon projects can - and should be - risky. Participants should be stretching themselves, reaching out to seize possibilities. And to make sure they’re doing that, the hackathon needs to be an event where failure is punishment-free. In fact, you should be celebrating failure, because failure means you’re learning something. There will inevitably be projects that encounter problems they didn’t expect, or who bite off more than they can chew in terms of workload. If you can help reframe those hiccups as learning experiences, you help establish that it’s okay to try something audacious and fail. And when those audacious things succeed, you’ll be thankful that you did.
Okay, I’m tentatively sold. How can I make it my own?
To really get people invested in an event like this it can’t feel like you’re just following instructions from someone else. It needs to have your company’s own stamp on it; it needs to feel like the event is a natural part of how your company does business. If your company is all about process and structure, then make sure there’s enough process and structure around the event. If your company’s more comfortable with a fast-and-loose, off-the-cuff style, don’t load the event up with enough rules to strangle it. If your company’s into fun (or just funny hats), make sure there’s enough whimsy in what you name things and how you arrange groups. You’re the best judge on what’s going to fly wherever you work. On the other hand, if you’re stuck for ideas, it can’t hurt to ask the people you work with.
So… what’s next?
This is going to be the first in a series of articles about running a company hackathon (or a Codefest, if that’s what you decide to call it). In the next article, I’ll talk about how to sell your boss, coworkers, or employees on having a hackathon. We’ll start by going through what you need to think about to develop the basic details of the event. So stay tuned!
