Last week I went to my first hackathon! It was part of TechXLR8, a tech expo that took place at Excel London. A huge east wing contained startup ventures, and the west wing contained corporate presentations. The hackathon sat in a large cordoned-off yet open area right in the middle of the venue, serving at times as a sideshow in its own right.
All hackathon attendees had the opportunity to pitch their project ideas to the rest. We organised ourselves into teams, before spending the rest of the day developing the concept and building a prototype. On day 2 we spent the morning finishing what we could of our product before practicing and delivering our presentations in the early afternoon.
I went in unsure about what to expect, and keen to get stuck into whatever the day threw at me. I think one of the main benefits I got was learning how a hackathon works, and how to approach one. If you’ve never been to one before, I hope you’ll find the lessons I’ve laid out here useful.
Believe it or not, working solidly for two days developing a semi-functioning application from scratch is a tough task, requiring lots of concentration and motivation. The process of pitching, planning, developing and presenting gets forced into a tiny amount of time, as do all the stresses and successes that come with those things. You’ll navigate your way through team dynamics, investigate the minutiae of most decisions and problems that arise, and devote thought to the longer term strategy of your idea before presenting. You’ll laugh, you’ll cry and you’ll be exhausted at the end of the day, so buckle up.
At TechXLR8, we left the venue by 8pm, however I understand that at many other hackathons people can work all night on their projects, so my experience was probably quite gentle in comparison!
If you want to pitch, plan beforehand
When you pitch your idea, you don’t need a hugely detailed plan, but if you end up forming a team, it will help hugely if you have given some thought to the reason behind your idea, why it is useful, why it’s different from what’s currently available, and how you could scale it. These things will make your life much easier when you get to work.
When I pitched my idea, I had discussed it briefly with some friends the day before, but I didn’t give it that much deep consideration before I pitched. Going forwards, I would definitely follow my own advice, and plan out a potential project before the day arrived.
Don’t be afraid to pitch
A large part of the Makers Academy course is made up of project work, for which you have to pitch your ideas to your cohort. Having done this multiple times as part of the course has definitely made me comfortable with the idea of standing in front of a roomful of people and pushing my project idea to them. There is no way I would have done that three months ago - it felt incredibly daunting, and everybody else’s ideas always seemed so much better than what I could propose.
After practising pitching multiple times at Makers, it felt incredibly freeing to realise that none of these worries mattered! My idea might not be better than everyone else’s, but it will certainly not be the worst, and nothing terrible will happen if I stand in front of people and talk about it for a minute. If you’re going to a hackathon and have an idea in mind that you think might be cool, go for it and suggest it to the group!
Follow the brief
Most hackathons will have a brief, serving as a set of guidelines for the project ideas. If you are serious about attempting to win, then it’s important to follow the brief closely. The brief for HackXLR8 was smart city, transport and home. A specific subsection was how to use technology to improve the experience of travellers and/or combat pollution. The winners were an awesome trio developing a pollution sensor that could be attached to bicycles. They really followed the spirit of the theme, and won because of this, as well as having a cool working prototype by the end of the event.
My team’s project was inspired by the brief, but did not follow it closely. Following the idea of ‘smart home’, using tech to assist personal finances, we began work on a salary negotiator app, that takes your skills as inputs (as well as a host of other job-relevant data), and tells you how much you would be worth in the job market for a specific title. Soon after we began a team member pointed out that it was not very closely aligned with the brief, and we diverted our attention from the initial vision to planning how we could tie in elements from our brief to our project. More on this in the next section.
Avoid mission creep
Our project suffered from mission creep right from the start. In an attempt to align it more closely with the idea of smart home, we attempted to build in a personal finance element to the purpose of the app. It made sense when you explained it to yourself. However the idea we ended up settling on was definitely confusing to people the first time you explained it to them. Tellingly, it was also confusing to members of the team.
This was the part of the hackathon I found most challenging. After being asked multiple times what the goal of our app was by one of the group, I found it increasingly difficult to grit my teeth and explain again a vision that was not my own and that I knew was too complicated. In general, I believe mission creep is a catastrophe for any project, and it showed in this case. A huge part of our energy ended up going into repurposing and reexplaining our new idea, as well as figuring out how it would for a user. If you find yourself in a similar position, avoid mission creep at all costs and focus on a single purpose.
Avoiding mission creep is easier said than done. In a team that is newly formed with no power structure, how do you make a call on what the right thing to do is going forwards, when the concerns of multiple members of your team strongly conflict with what you believe to be the best plan of action? In our case, the right thing to do would have been to make a call at the beginning as to whether to work on the original idea or not. We could have worked on the original idea as it was - it may not have won, but it would have benefitted much more from making sense as an idea than it did from being shoehorned into some semblance of the stated brief. Alternatively we could have jettisoned the original idea completely and gone for something different.
Ultimately what we made was fine, and I was proud of the product we ended up with. I think that working intensely on building an app in two days is a skill that can be honed, and that mission creep avoidance is one of the key things to be aware of in the process of doing so.
Get a balance of skills on your team
A good team will have people with a range of skills that complement each other. In our case, we had a great developer and a great designer, who did a lot of the dirty work when it came to prototype building. Alice and I spent our time discussing the overall business plan and making and rehearsing the final presentation. Through serendipity we had a great balance of people, and I’d advise anyone going to a hackathon to make clear in their pitch what skills they will need on their team to ensure they don’t hit any blockers when building a prototype.
It’s not just about code
This was one of the things that surprised me most. The judging decision we were faced with was decided based on a presentation. The judges did not use or try out our products, they watched us present on what we had built for three minutes and then asked us questions about our business plan for another two minutes. In this respect, hackathons seem to be less about software development, and more about building a business plan, and getting as much of a prototype built as you can. All components are important: the code, the concept, the design, the UX and the plan for marketability and scale. You’re bound to be missing some of these components if you are showing up without a solid business plan already, but in terms of what you’ll be judged on, they are all pretty equal in terms of priority.
I expected to do more coding than I did. Of the many things a hackathon is, it is not the best place to practice coding or learn a new skill. There simply isn’t the time and other tasks will end up being more important. You can expect to showcase your existing skills, but don’t expect to come away with new ones.
Social media featured highly. All groups were encouraged to get involved, and what little we did ended up being a lot of fun!
Meet people, and maybe get hired
There will be lots of interesting people around! My team ended up sharing meetup ideas and project ideas, as well as exploring the expo and meeting other stallholders. One of the judges specifically mentioned she was looking to hire somebody. Going into your next hackathon I’d treat it as an opportunity to meet lots of interesting new people, and potentially impress a recruiter, if you are looking for a job!
I look forward to going to more hackathons, and feel like having been to one, I am much better positioned to make the most of them, given I now know what to expect. I hope what I’ve written will serve as a useful guide to anyone considering going to a hackathon themselves, and I look forward to writing more about future events!