Made by
Made by
Seasoned hacker Mike Elsmore presents an entertaining guide to representing at events. From preparing properly to providing prizes, this talk from DevRelCon Tokyo 2017 will tell you all.
Mike: Okay, yeah. So, I am gonna start. Just gonna stand here and look pretty. Right. So. See if the mouse works. I don’t trust Safari. Anybody who does, I worry. Okay, it works, great. So, who am I? I am Mike Elsmore. I do things on and with the internet. I don’t actually know what my job is anymore. And my contact information for you to pass to me via all methods is GitHub and Twitter on top and email on the bottom. Cool? Cool. Right.
So, what I usually end up doing is stuff like this, which is software development and some DevRel consultancy and content encryption. And what this talk is actually about… Oddly enough, it’s not about running a hackathon. If you want to help setting up and running a hackathon, ask me after the talk. I’m more than happy to go through that with you. But this is actually about representing at a hackathon. So, just as a rough guide, hands up if you’ve ever been to a hackathon. Who has a clue of what hackathons are? Okay. I can start from ground level, but for those of you who haven’t been, it’s a really good experience. You should go just for the fun and the LOLs anyway.
So, how am I qualified to do this? Well, I don’t actually have any skills, but I am slightly qualified because I’ve attended a lot of them. I happen to have won some of them. I have run a few of them. And for some odd reason, I can’t stop running them. I’m on year five of running the same event. Even though there is a running joke that this will be the last event I ever run. And that joke has been going for about four years. And arguably, it’s the most loved hackathon in the UK. At least I like to think so.
I also happen to, once upon a time, be an evangelist for IBM. So I’ve also done the actual mentoring bit. So, I’ve kind of done it all. I’ve been a hacker, I’ve run hackathons. I’ve mentored and represented at hackathons. That isn’t actually everything in life, but there is a lot of it that’s that.
There’s no real way of doing this in a very obvious way because hackathons are very liquid and fluid thing. They change based on who’s running them, where they are, etc. So a lot of this is going to be common sense. And if what I say makes no sense, ignore me and go about what you’re doing anyway. So, this is very much my opinion. I am sorry, you’ll just have to live with it. Also, like every British person I know, I have a tendency to start talking really, really, really quickly. So stick your hand up, not to ask a question, but to tell me to slow down.
And there’s already a troll in the room. So, it’s time to limber up. Get started. Shall we begin? Right. So step one, before the event. So what do you do when you’re prepping for it? You may not even have a choice in the events. So, I have represented at quite a few hackathons that I didn’t agree with in the individual, but from the company perspective, it was a requirement, so I still had to go and do them. It meant having to, like, be happy. Find ways of, you know, to deal with that and just get on with work. And some of the ways of doing that is for me… Check this out. The thing has a code of conduct. Hands up. Who is aware of what a code of conduct is? Okay. If you’re not aware of what a code of conduct is, it is a guide and a set of procedures for how an event is meant to take place. This is a set of expectations and procedures for how things will be. Really useful for making sure that everybody plays nice because then sponsors and the attendees and the organisers all have to behave in the same predictable way.
If you haven’t got one on the event and/or they don’t know what one is… point them to this thing, which is The Hack Code of Conduct built by Cristiano Betta. It’s like, it’s not the best thing in the world, but it’s a good start. It’s a…it’s for people… You should never have a generic code of conduct. You should always make it work for your event. So this is a great starting point. Especially has it the customise button, so you can just put the bits you don’t want in there.
The big piece before the event is actually doing some research on it. So, quite a few hackathons in Europe are now becoming a series. They’ve been around and are sticking around for a while. There’s quite a lot of throwaway ones, but some of them are repeating. You wanna do this not because…because all hackathons aren’t the same, some of them are big corporate events and startup-y like TechCrunch Disrupt in New York and in Amsterdam, I think, was the last one, or London. And then there’s real community level ones. Like the ones run by MLH. Which may then have very different fields on how the attendees behave. So you should really research previous ones or even just the organisers to see if they’ve run previous ones, to see how they actually want to do their thing. Wouldn’t mean you’ve prepared the correct stuff. To use a metaphor, which is a real pain in the bum, especially if you’re working in a large corporate. Making sure you have your marketing material ready. The amount of times where I have come to quite a last-minute response to stuff means that most teams don’t have their banners or swag, etc., just lined up ready to go. So, try and have it ready.
The next one is RTM. Or as I like to put it, read the manual. There is a lot of stuff that happens at hackathons that you will not have a clue about even if you are a professional developer evangelist. Mainly because you can’t know everything. It is impossible to be an excellent programmer in every language that your company uses. Unless your company is just JavaScript. Because that’s just easy. You kind of do things and it works. I think. But you need to really know how to help people even if it’s a problem that you can’t personally solve. So, oh, it turns out, nobody can actually hear me. I apologise.
I’m getting advice from the sides on how to hold the microphone. And it’s very confusing. Uh…I’m never doing that again. Right. So, read the manual. Make sure you know, if you don’t’ know the specifics, you know where to find the information in the manual. Wow, I can hear the reverberation. This actually works. There we go. Right.
Another one that is a lot of people seem to forget is, check the support channels. Make sure you know if there is gonna be any actual support at the period of the hackathon. So if you’re, say, a small startup who has to spin up dedicated clusters to do stuff, then make sure you know who’s gonna be on ops, so you can be very nice to them. And if stuff goes wrong, you can ask them to fix it. Because if the product disappears in the middle of a hackathon, yeah, yeah, that’s not gonna be very good. It’s a bit of a pain.
And there’s also setting up tracking. If you do hackathons quite a while, people start asking where the hell is my ROI? That’s usually for a lot of places just sign-ups and brand awareness. So, make sure you set up tracking in advance. A lot of companies just have custom codes for their products. So Twillio is part of that process. Usually has a little code they hand out during the process of getting in a hackathon. So make sure you have tracking so that in some way, they can see that people are engaging and money’s not being wasted.
And one important one is, don’t bail without a reason. I’ve had quite a few events where I’ve either been helping or run and people have just disappeared. This isn’t cool because a hackathon is relying on very much on… Even if they’ve given money, they’re relying on the APIs to provide stuff for people to do. Stuff they can actually get their teeth into. And if people have bailed, they’re kind of leaving the attendees in a lurch. And they’re liable to get bored and factious with not enough stuff. So if you have to bail, give them a reason so at least they can pass it on when people aren’t grouchy about it. Maybe you’ll get a sponsor again later. Right.
Step one. It’s time to buckle in because now it gets a bit more difficult. You got the next step, the kickoff. So, what do you do at the beginning of the hackathon? So, start with setting up normal sponsor-y, booth-y things. Mingling. I just realised I kind of wrote these down. I don’t need to say them.
An important one, which I have failed at myself and got shouted at for is, be punctual. If you’re going to sponsor an event, turn up early enough that you’re not setting up in the middle of everybody else. So that if you got banners, etc., they’re all set up on the side. And just so you could be around, so if the organisers are going, “Oh my god, I have no idea what’s going on.” You can either help them or at least answer any of their questions.
Another one is, be obvious. I don’t mean sarcastic, I mean easily identifiable. What I’m saying there is, there’s a lot of people who, when they start, they all go looking like the attendees. It’s really, really hard to go and ask a question of somebody when they’re wearing the same t-shirt as everybody else. I want to find the GitHub guy for better help. I see 50 people in GitHub t-shirts. Which one is it? So make sure you’re easily identifiable or at least you have a booth with branding, etc., that you can easily be found at. So when people are screaming bloody murder, they know where to go for help.
On that note, there’s also remember to mingle. There is a representative of your brand and technology. You want to get people interested in it. And an easy way is just to talk to people whilst the event is getting started. You can find out what they want. What they’re gonna do. And suggest things that may use your product, or other such mildly nefarious means. And more importantly, which I have done, don’t forget about your presentation. Most hackathons, you got a couple of minutes to actually talk about your product. I may have a couple of times forgotten that I’m giving this. So I didn’t have anything prepped.
Make sure you actually know what you’re doing there for the event. Certain companies go to these things to recruit. Others go to push a new technology. Others go to promote product and do brand awareness. Make sure you know what you’re going to present about and you have a relative presentation that makes sense to the attendees. And if you’re doing it for about technology, have an appropriate demo. Most of the time, this is like live coding and putting something together and getting people to interact with it. Or it could actually just be a really funny and descriptive demo. But something that people can understand what your product actually does if they have never heard of you.
And more importantly, practice the demo. Because I have once or twice, tried doing the whole live coding thing and forgotten that half of my keyboard commands to cheat and get it to make the code come out. I wouldn’t suggest doing this because it means you then chew through your time very quickly. It essentially means also preparing for demo fail. Things will inevitably go wrong. This is technology. I have never seen technology work every time, ever. So, don’t blame the demo gods. That just looks really bad. I think I got shouted at this for the first event I did. And I think it was that man there that did the shouting. So, just prepare everything as if the internet didn’t exist. So have offline versions of the code sets, if you know it’s something you can work against. Or have pre rigged completely fake things running, so it looks like it’s working. You look cool, but you’re lying out of your back teeth. And if necessary, GIF everything, so people can see interacting, even if it’s not.
Yeah, I may have done that a few times. So, now we’re in for the long haul. We’ve got the actual hack starting. So, what the hell do you do during the event? So, you can’t make assumptions over the skills. Does everybody here assume that somebody who’s going to a hackathon is a seasoned developer? Or that they are even interested in code to begin with? Usually, people are interested in code, but these people, in the case of like student hackathons, they could be coming from a physics background and just started writing horrible Python scripts for their course and don’t actually like writing code. Or it could be that you’re in a startup one and it’s randomly a team of UX people that have gone, “Oh, nuts. I can’t use Envision for my demo.” So they have to learn to do some basic work for once in their lives. So don’t assume everybody has the same skill set. So you’re just going to need to actually talk to them. Find out what they’re doing. Because a lot of them are going to be feeling panic as the seconds start ticking away and they realise, “Oh, nuts, I have X period of time to actually finish something and present at the end.” So, make sure you actually just mingle and get in there.
This leads on to the next one, which is, how many people you actually need to take? I’m halfway through. Well. At least one person. Don’t try and do hackathons virtually. It gets really, really, really difficult when they go, “Okay, the only way I can ask help is on Twitter.” It doesn’t work. But you also don’t want to send an army. There was a time at my old place where we used to just bring the bus of people. That meant there was an event with 150 people. We took 20. That was too many people. We just had like 10 people just sat at the side doing nothing. They looked bored. They looked disinteresting. People don’t want to engage with you. So, the usual amount for, say, a 200-person event would be 2 people. Scale it up, say, once every hundred so you’ll have enough people to kind of answer questions but without having somebody looking really, really bored at a booth.
Next, this one is the most important thing if you’re at a hackathon and you’re meant to be mentoring and representing. Be a good citizen. That means be approachable. Don’t be very negative towards everybody. And actually, just engage with the people there and talk about the problems that hackers are actually having whilst they’re trying to build stuff. Some people, it’s just going to be, “Oh, nuts, I’m having difficulty setting up environments or getting access to API keys.” Or any number of possible problems. So, at the very least, you should just like get involved and help them with their Google fruit and actually search for stuff. This, even if it means you have to be nice about the competitors, it sounds a bit weird, but you’re there as an individual. Which means you must appear as a nice person. So suddenly, if you go on a rant about how horrible competitor X is, it doesn’t look good against you and are very unlikely to approach you later if they…even if they need help with your product.
Also, don’t leave early. I’ve seen this quite a few times. Where people will stay for the demos and then leave two hours in. Nobody’s built something two hours in. They’re still trying to work out how to do it. Stick around until actually people start plugging things together so you can actually give them a hand. And don’t look like you’re working. If you’re trying to look like you’re just sat there, headphones in, doing your work, nobody’s gonna interact with you because, well, who here wears headphones when they want them to leave them alone? Yeah. So that at a hackathon, not a good idea if you’re trying to interact with people.
Also, don’t take work calls. I found salespeople at a hackathon taking sales calls. No. There should… That needs no explanation. Just no. So now you’re getting to engage. Best option is to stay for 24 hours. I’ve seen… And I’ve personally done the whole 24 hours at a hackathon thing as a developer mentor. I don’t advise it because when people need help at 4 in the morning, you’re useless. But be available as much as possible. So, be available into the evening. Into the early hours, if need be. But be there back in the morning so the people who you haven’t been with overnight can come ask questions when they’ve got two hours to spare before they have to submit. Okay?
So, the hacking’s done. We’re nearly over. It’s time to do the end of the event. So, I’ve just realised that’s spelled badly. It’s meant to be supportive. Be supportive of everyone else’s work. You’ve been there for like 36 hours. You’ve been paid to be there, I hope. But these people have been there, most of the time, voluntarily to do it, it’s fun. Or just to do something. So, they’re gonna be fretting, they’re gonna be fractious. Be supportive of what they’ve been doing. Even if they haven’t used your product. Just be supportive. You don’t have to be happy about it, but be supportive.
So, next up is the judging bit. Don’t be afraid to ask questions. I know that it’s usually frowned upon if the sponsors are asking questions. But half the time, if you… You can’t quite tell if they’ve used your API or not. Or how they’ve done it. Don’t be afraid to ask after they’ve presented, but before you judge, go find them and go, “Help, help, help. I need some information, please. Please, help.” And you don’t have to pick the most complete product. This is something I’ve seen a lot of, like, teams that have done this. Struggle with. They’re after the most complete thing. The thing that looks like a finished product. Sometimes the best example of your technology or of just of somebody’s skills as a developer is how far they got. Because maybe they picked it… They decided to make Google in 24 hours. That’s not going to happen. They couldn’t really make a good UI. So, think. Or they’ve made a really good search algorithm. Think carefully and pick something that’s very representative of what you need, not what looks polished.
This one, prizes. Eventually, if you’re sponsoring, you probably want to give out prizes to engage, to get people to actually engage with your product. But, be appropriate. You don’t have to spend thousands of dollars to do this. So TechCrunch Disrupt? Yes. People that are after money, so you probably wanna put up like a giant chunk of change just to get them to even look at you. But if you’re at a community event, you just want people to engage. That means, people aren’t there for the money. They’re after the glory and the fun of it. So, I’ve seen a great example of a company just rocking with refurbished GBA’s and copies of Pokémon in there. Because it’s like, that’s kind of cool. Doesn’t cost a lot for the company, costs some time, but it’s engaging. It’s something that people would’ve enjoyed after doing 24 hours of pain.
Talk to the hackers that used your stuff afterwards. I have seen teams where they presented their prize and then left. So they haven’t found out what else. And they haven’t got any extra information out of them. This is really important. Because eventually, you want to make collateral, you want to have blogs, social media stuff. Sharables, so let…images of their… Sorry. Images of their completed things. Repos, so that you can share and actually have people go, “Look, here’s a really good use case. This is something you could do as a product.” Rather than just a really, really bad piece of code. So, remember to talk to people afterwards rather than just leaving. It also gives a bad impression in the fact that you don’t care about what’s just happened.
So, be a hero. Get involved in hackathons if you haven’t. And if you do, don’t stop getting involved in them because I think they’re really fun. So, that’s me. That’s the talk. Any questions? Thank you.