Made by
Made by
Kevin Lewis
Hackathons have been a key part of the strategy of many of developer relations programmes. In this talk from DevRelCon London 2019, veteran hackathon organiser Kevin Lewis shares his recommendations on how to get the most from them.
Kevin: Hello, this talk is called getting the most from running a hackathon. It’s not so much about getting involved in other people’s events but rather running your own, talking about some common reasons why people want to run these events and then designing events around those goals. But before we crack on I just want to say hi. My name’s Kevin. I run a lot of tech events, mainly hackathons, and in the new year I’ll be joining the Nexmo team as a developer advocate for London. I’m also an avid boardgamer so if you’re looking for your last minute Christmas recommendations I would love to chat about that and I’m also a JavaScript developer.
In the next 20 minutes, I want to cover what hackathons actually are as an event format so we’re all on the same page. Talk about some common reasons why people run these events, cover the ingredients that are needed to run hackathons and then how those ingredients can be chopped and changed in relation to the goals of your event. Then, at the end I’ll cover a couple of common recipes that I’ve found work in the past. So without further ado, let’s get started.
Let’s cover what hackathons actually are so my definition of a hackathon is an invention marathon. Where you get together software developers, designers, researchers, and industry experts, give them a challenge and a fixed amount of time and then they build prototype solutions to answer that challenge and then present them at the end. I’ll do it in pictures. You welcome people at the beginning, tell them where the fire exits are and the loos and the challenges and stuff like that.
Next, you have partners and sponsors come up and provide some context around the challenges, the themes, the technologies that are focus of your event. And then, facilitate some ice breakers and team-formation activities. In these events some people will come alone and prefer to work alone throughout the time given. Some people will come in teams and work in those teams, but many will come alone and want teams to kind of be formed at the event and it’s our job as event facilitators to try and help people form those teams.
Then, they get a kind of an amount of time to freely design and develop solutions to the challenges and themes provided and during this time mentors often go around and support people. That support could be technical support but it can also be support around the challenges or the themes of the events. Additionally, sometimes though, workshops and talks that happen off at the site throughout this period and that content should really be designed to help support the hackers in forming ideas and building their projects. And this period can last anywhere from kind of four to 36 hours, where four hours is kind of in and afternoon and 36 hours goes through, from for example, the middle of a Friday straight through to a Sunday and is often quite common in game-focused hackathons or jams. That at the end of this period, people present what it is they’ve built. This could be a set of standard presentations like this were everyone’s given a period of time. Can be science fair format, they can be an element of online judging, but at the end of these ones, everyone’s presented at some events, though not all, that winners are crowned and they get bragging rights and or prizes.
Before we continue, I want to talk about the art of the challenge, because actually, this is one of the most important factors for a hackathon either makes it successful or an event that doesn’t necessarily meet its goals. See, it’s a bit of a Goldilocks situation. You want your challenges to be broad enough that it allows creativity and the interpretation of the challenge so you get a range of things that are built. Make it too specific and everyone runs the risk of building the same thing or very, very similar things. A good challenge still allows creativity while framing the desired outcome. It allows people to know kind of what it is expected of them. But also allows them to focus their ideas a lot quicker so they spend less time necessarily thinking of ideas and more time trying to build that prototype. I’ll be publishing a blog post about a good challenge in the next few weeks.
The point of this talk though is that you really need to have a goal when it comes to running hackathons. You see running an event without a goal can often lead to lackluster outcomes or getting to the end of it and wondering what it was you were actually trying to achieve. And when you have a goal you can justify decisions made in the planning process and the delivery of the event to meet those goals.
Next, I’m going to talk about a range of reasons that when I’m going out and talking to people are the reasons that they want to run events, and hopefully as a result of this, if you want to run a hackathon and you don’t really know why, maybe you can relate it to a couple of these goals, where if you have these goals, you might consider a hackathon as a platform to at least somewhat achieve them.
One of the most common is genuine research and development activity. Where you have a specific problem that you want to solve and you would value external contributors in coming to some ideas. For example, how can we improve the customer experience for fans coming to Wimbledon both during and after their visit? Is a challenge from a hackathon that I ran very much focused on research and development. It might not be relevant to everyone but if you’re in the UK and you frame this really nicely you can also get some tax credits if it’s genuine research and development activity which is wicked.
Next, is this idea of building communities around a common theme or cause. Remember, yeah, communities often need a cause or reason to be getting together so you’re going to be wanting to put focus on this cause that people are coming together about. These are quite often run in events that are themed around social impact or civic technology or things like that. Next, is driving adoption of your product. Now, this might not necessarily pay off immediately beyond some hackathon projects, but if you have tools and make them really easy to use in a way where someone can build something meaningful with it in a short period of time, that kind of experience often won’t go forgotten.
Driving adoption, though it is longer term, is another reason people consider getting involved in running hackathons. One way, of seeing this work before, is companies building hack-kits or hack-packs, which is a variation on the getting-started guides, where you might not necessarily be promoting best practice, you’re promoting how to get started really, really quickly and allows people to get running, there’s risks involved in like correcting their course later, but I wanted to also mention that. Another reason people run hackathons is to gather feedback about pre-release or general availability products. You can get honest feedback, you can get case studies and you can also approve relative ease of use if people are able to use it in a short period of time. What I would say about gathering feedback, ’cause we don’t cover it much more in this talk is if you are looking for it, be really explicit with the attendees about what it is you’re wanting from them. Otherwise, you might find feedback coming in forms that isn’t necessarily that useful or feedback on things that aren’t necessarily the focus of what you’re trying to get out of the event.
People also run hackathons as a recruitment activity, I don’t necessarily think that hackathons just as a recruitment activity with this being the sole goal is always the best format. But hackathons are a great way to assess people’s technical ability, their communication skills, teamwork prioritization, problems solving, a whole bunch of other things. Again, another caveat on this, is a note that some people perform really well in this environment, this quite potentially pressured environment and others don’t and that doesn’t necessarily speak to their technical skill, but as one stream of recruitment activity to kind of shortcuts that first part. You can have people highlight a lot of these skills quite quickly at these events. This is one of my favorite reasons to run hackathons, I know it sounds like I paid myself but a lot of people don’t consider that hackathons can also be used to support sales teams.
The context here is, for example, you might have a product and you’re going out to a business. The business is warm, yeah, they’ll probably give us some money but they’re not quite sold. And quite often I run hackathons in this context where we invite some external contributors and some sales engineers and we have them work on a challenge that uses the product that is trying to be sold in the context of the potential customer’s business. In this fake case study here, use product Y, to provide novel experiences for customers in Avanti train coaches. That would be an example of a challenge in an event like this. And one I won’t focus on it too much today, genuine skills increase, is the reason why some internal hackathons are run. I won’t be talking too much about internal hackathons but you know, for example, use today to try out technologies that aren’t part of your wheelhouse day to day, and these events can be quite effective in doing that.
There are some common reasons why people run hackathons. There are probably a lot more and if I’m missing some really obvious ones, please stop me in the break and let me know. There are some reasons why hackathons should not be run or scenarios where they are not the answer. Firstly, do you have a very, very specific scope about what it is you are trying to build? In that case a hackathon probably isn’t going to reap the reward you want if everyone’s going to be building almost the same thing at the cost of running an event. And I’d recommend hiring people to deliver the project with this very specific scope that you have.
Next, are you expecting deployment-ready solutions at the end of a 36 hour period? That is not going to end well for you. Hackathon projects are rough around the edges that’s putting it very, very kindly. They’re great for ideation and there are ways that you can’t take ideas and projects built at hackathons and further develop them, but if you’re expecting something out the end that’s ready to go, you will probably be disappointed. Next, you want to own what is built but you don’t want to pay people to build it. If you were hoping for some positive community feels, this is not the way to do it. Now, I’m not necessarily opposed for at the end of a hackathon, the things built not belonging to the attendees, on two conditions. One, everyone knows that is the case from the first minute. It’s not hidden in Ts and Cs. It’s not hidden in the small print but everyone knows and their signing up for that, and two, people are paid for their time. Then you can frame these events very much as a fun piece of work and we’ll talk about that in a little bit. If you’re sole aim is to improve brand awareness, then running your own hackathon might not be as useful as you think. ‘Cause you still have to build an audience that is aware of your brand to get them in the door. There are ways of incentivizing people to come to an event, but it will take more work and you might otherwise consider going and supporting existing established events.
Next, we’re going to talk about how to actually run a hackathon. I’m not going to go too much into depth with this, and I’ll focus more on kind of relating what I’m about to say with goals, so I’ll do this bit a little bit quicker, but core ingredients of any event is you need a space, you need a date to run your event, you need a theme, challenge or reason for people to be gathering. And then will all of that you need to fill the space with people. Every event is the same, doesn’t need to be a hackathon, but hackathons have some additional components, which are, yeah, more specific to this format.
Firstly, is food. Now, unfortunately I think we’ve found ourselves in this situation that I will call hacker entitlement, where a lot of people coming to hackathons expect to be fed four or five meals and have a constant flow of snacks. You might be able to do this, you might not be able to do this. If you can’t, just make it really clear. Setting expectations out-front is super useful.
Next, is content. And when I talk about content, I mean when people come up at the beginning and give that context about their business or the technologies that they’re encouraging you to use. But those are the talks and workshops that happen throughout the event. Good hackathons often nail the content both at the beginning and during the event to support people in creating ideas and then actually building them.
Next is, prizes. Now, not every needs prizes, how not every event needs winners, but you might consider prizes as a part of your event. Personally, I’m a fan of lower value prizes or no prizes and you just have a show-and-tell as opposed to presentations and a winner or pitches. But consider that as well.
And finally, the thing to make sure that hackathon projects don’t just sit on the shelf and gather dust at the end, is having some explicitly pre-planned follow-up activities, and again in a bit we’ll cover some of those as well. That one was a bit of a short one. So you can have this quick photo.
Right, let’s talk about designing hackathons for our specific goals. To recap, these are the reasons we spoke about why people often run hackathons, please do come correct me if I’ve missed some like, blatantly obvious ones. And here are the parts of running an event, we’ll be covering these again. Ccoming up, I’m going to talk about some key reasons people run events. From that list before I’ll cherry-pick some key ones I hear more the most, and we’ll talk about how to kind of shuffle these items around in order to make those events successful. And while I’ll only be covering three, I think, three, if you are, you know hopefully you’ll be able to see how these things can be changed for the other goals or other goals that you might have.
Going back to research and development, it’s the genuine research and development activity you want actual solutions to actual business problems. Now, there are some key things to these events to make them successful. Firstly, you really want to make sure you get the right makeup of attendees. What I mean by this is, if you are running a data science hackathon, having front-end developers and designers there probably won’t yield the results that you need, they’re important and you need them, but they need to come in the right kind of concentration with the other skills that are there. And if you have applications at these events it also allows you to see what you’re missing in terms of skills and make explicit efforts to go out into communities with people with missing skills that you require for these events.
Next, make effort to equip hackers with the suitable industry knowledge through the content at the beginning and a mentorship. And keep stakeholders involved. This one’s really important for the next step, those follow-on activities. If you have stake-holders involved right from the beginning you have a higher chance of making sure projects exist at the end of the two days. I find these events work best on weekdays in terms of date. And the reason for that is you can get stakeholders involved. They can be smaller, which means you can run them in a smaller space. I’ve run this kind of events in large meeting rooms not necessarily the most ideal space but possible, you can run them in quite small spaces.
But at these events if people are actually trying to solve issues that your business has, pay them. Pay them for their time, also pay them for the work they’ve done. Pay them for the projects they’ve created. Make sure that you’re not left in a space where good ideas are kind of locked away with them and instead you have the ability to go and run with them after it’s with or without them. And the fact you paid people makes it easier to run these events on weekdays. People can take a leave or they might be contractors and they can come along or take a day off and stuff like that. If you can provide food do, but I very much frame these events as a fun piece of work so again, as long as you’re setting expectations and you’re giving people ample time to go and sort themselves out, if it’s not necessarily the most feasible, you don’t have to.
And remember, content is absolutely key to ensuring effective hackers, making sure the things the are built actually hit the nail on the head in terms of the challenges that you have. And then in terms of some follow-up activities, ones that I’ve run quite often, further development workshops where you take projects you like and then run another hack on those projects with where the scope now gets reduced down into exploring a few of the concepts or ideas that are created, or engaging stakeholders with redux events. I don’t know where this term came from, but I’ve been using it for ages. Redux events are kind of a replay of the top presentations to stakeholders at another point in time. This means you can run them on weekends and then engage stakeholders in that redux event, but really hackathons are a very weird event where people don’t really get them until they’re in the room with them happening, so if you can try and run it with stakeholders involved as they’re happening, that is more, that is a bigger preference.
Going back to building communities around a course or a theme. These events focus on the environment that you’re creating. The small thoughtful touches at these events often go a long way. Now we should be putting effort into all of the events that we run, but more so than most if you consider the first example to be a piece of fun work, this is a community building exercise and the expectations in doing that are different, so putting more effort into those small touches, generally won’t be forgotten.
Next, encourage people to stay engaged after the event. Based on your specific used cases and your specific businesses, that could look like online community space more event-social stuff like that. Going back to that list of ingredients, these events work best the weekends when fewer people are at work. Generally, you won’t be paying people to come to these, they will be paying to attend. Make sure it is as accessible as possible and weekends seem to be the best time to do that. These events can also stand to be a lot larger, so you also want to be considering the space and the provisions for that space. I mean this is not an operational tool, but provisions like, are we going to hit the limit of people connected to an access point? That one I see more times than I care to. And in these events, food is generally expected. Again, you know, I’m not a big fan of the fact that we’ve found ourselves in this space where people expect it and if you don’t you have failed, but again, if you’re setting expectations up front, people will know what to expect, they’ll know they’ll have to sort their own dinner or something like that. The content of these events should be helpful for beginners to a topic. Where as in the first, you might be handpicking people based on applications based on their skill level or their skillset, these you might end up having a wider range of skills and abilities. So make sure the content or at least some of the content is helpful for beginners to a topic. And yeah, follow-up activities could be like online conversation spaces, more laid-back socials or again redux events I’ve seen done here, though it’s harder to people to commit to a second show-and-tell event when they’re just coming along for a bit of fun.
The third use case, ’cause I’m aware that I’m running out of time, the third use case is supporting sales – again, through contextually appropriate challenges. This one will sound a lot like the first. Make sure hackers know the purpose of the event. Make sure that everyone is on the same page, there’s nothing wrong with saying, hey, we’re paying you to do some work for us, our aim is to sell this, these are that things we’re trying to highlight very much as sales engineers would if they were to take part in these events. Make sure stakeholders from all sides of these events are involved, not just the hackers and not just the businesses, but also the potential customers as well. Don’t just present, oh, look what we’ve built in 24 hours, but have them more involved in this process. And if you can, try and include sales engineers as part of the hacking team, weave them in there. They’ll have more knowledge of products or potentially more knowledge of products. Hopefully more knowledge of products. And they can also upscale your hackers while you’re at it. Making them more effective if you run events again with them. As an aside, make sure to have a record of the projects you built, because these events are often smaller, there are fewer projects, quite often people don’t take really good note of what it is that it’s being built and you’re left scratching you head when you’re trying to talk about them later when you’re furthering your conversations, though, this is true of all hackathons.
And finally, not to sound like a broken record, but this is a directly bottom line-impacting activity, pay people for their time, they will represent you better, and it’s a piece of work, make sure everyone from all sides are treating it as such. Weekdays work best to get stakeholders involved. Try and find a venue on neutral ground. Don’t necessarily invite them into your house and don’t go to theirs but try to meet and make it a bit of an event. Try and ensure the right makeup of skills. I really am sounding like a broken record, I had not realized how many times I’ve put this on the slides. Pay people for their time.
If you remember this is a professional event, I think we’ve come on a long way, going into 2020 from kind of beers, pizzas, energy drinks at hackathons. And personally, I don’t include those elements in any hackathon I run for any purpose, but remember, these events, even more so are professional events so maybe putting a bit more effort into things like these would be appreciated by your team, the hackers, but also the people you’re trying to impress. What’s interesting about this format though, is essentially, because you’re hiring people in this context, you can prep hackers before the event. I often do this in a one hour call that I ask hackers to take part in if they’re free, a couple of weeks out from the event, it allows them to start talking about ideas, start getting to know one another and what their skills makeup is, ’cause well, we’re aware of that as facilitators, they might not be. And it also allow us to ensure that if someone has an idea that we really had no idea was going to come up, that we can place good mentors in terms of the knowledge that they have technically or related to the industry knowledge. This is really, really useful if you can do it.
Let’s talk about a couple of recipes. I’m going to talk about community hackathons and application-based hackathons. There are also internal hackathons, not going to talk about them today but acknowledging they exist. Community hackathons, open to the public are generally larger, have more people involved, and there are a bunch of reasons why these are good. You can fit more people in them, you can get a wider range of people coming along. You generally, physically, get more project ideas being built. They’re cheaper ’cause there’s no expectation you’re going to pay people for their time. You can involve more stakeholders, for example, Beth and I ran a social hackathon and we involved multiple charities and these kind of events can stand to have more stakeholders involved because there are more people to spread the attention between those partners, and also you have the opportunity for a much more buzzing vibe in these events, I don’t quite know how to say it, but like with more people there, generally it feels like a more energetic space. But there are some challenges, they’re harder to recruit for. I’ve run some hackathons, where I’ve throw open the doors, bought all the food, had loads of space, and there were 20 people in the room and I was expecting a hundred.
You know, there are a lot of these events happening so do consider that you’re going to have to put more effort into recruiting people. You also don’t know who’s going to turn up, you don’t know what skills they’re going to have, you don’t know if you’re going to have people who can really answer the challenge. You should be focusing on everyone, even if they can’t, but you might not know if they all meet your goal. I often generally find that the array of people who come and then the people who present projects at the end, that ratio is lower at these events, so a lot more people don’t end up presenting, ’cause it’s not really, there is an expectation they do, but it’s not quite framed the same way. The projects belong to them, which might get a bit hairy afterwards and then yeah, you need larger spaces, and there’s a side here of hacker entitlement, where people have an expectation of what a high-production quality hackathon is and actually you just want to run this little thing in a spare room in your office and get some food, get some takeaway and then have people chilling. Make sure you’re setting expectations.
Now, in terms of the application-based hackathons, which are kind of that R and D in sales context, there are some pros. So you know, everyone is working to a common goal and you can more heavily curate the audience who are attending them, you can prepare them, and the ideas at the end belong to you, so if at the end you want to do something with them, that could be giving them to the cost of my working with them, or selling it to them or continuing to develop it yourself or whatever, you are free to do that. And because generally, at these events, we have developers kind of look over an agreement that they sign, you can also fold in some other agreements to that, like non-disclosure agreements and while I’m not a big fan of these documents, it does mean perhaps that you can present more privileged information to them, mock data sets that actually mimic real data sets, or real data sets to work with. There are some cons, they’re much smaller, they work better at 10 to 20 people, so the space is, often feels quite different as a result, so do be considering that. They’re more expensive because you’re paying people, and also you don’t know what the outcome’s going to be so selling internally and unlocking that budget is often more difficult in this context, there are so many variations though. You know, applications for community-based events, which can be really good to vet the audience. I ran an event called Sex Tech Hack and in that we really want to vet the audience and make sure that we’re only allowing people in who’d be respectful to the environment that we’re providing. Applications to community events happen. Having super, super involved stakeholders at weekend events, and also high attendance and serious attendees at those events, maybe ’cause there’s prizes or ’cause they really bought into a theme.
That was a whirlwind tour. I’m more than happy to chat more about this, answer more questions, but how did we do? We did understand hackathons as an event format, I hope. We did cover some common reasons for running hackathons, covered the ingredients, talked about how to change them up in relation to some common goals, and talked about a couple of recipes. Thank you. My slides are up there if you want them, lws.io/drc and I’ll tweet those out. Thank you so much.