Hackathon Advice?

Charlene MPH CEO & Founder, ReciproCare, Halcyon Fellow

November 13th, 2014

I will be attending my first hackathon as a non-technical founder soon.  Any advice?  

Are there things that you wish you knew before participating in a hackathon?

Shahab Layeghi Software Professional

November 13th, 2014

Think about some ideas relevant to the subject of the hackathon in advance so when you go there you can propose and form a team if others like one of them.

Sanjeev Rao

November 13th, 2014

As a non-technical person, you have your work cut out for you: I'd say you'll do well if you develop a sense of how you want your product to look, feel and work. Be very detail oriented, because lack of detail is ambiguity. If it is a consumer product, get a sense of how you should make the target consumer feel. For both B2B (hospitals. insurers, etc) and B2C, understand what the key touch points are and how you will get your product in front of your desired audience (for them to hopefully accept and love). Learn about growth hacking.

I'll assume you'll be smart enough to not try to be anyone's boss even if it is your idea. You need the technical guys as much as they need you.

Alison Lewis CEO/Creative Director

November 13th, 2014

Congrats, first of all!

Secondly, as a non-tech - you have to kind of prove your value. Come with a clear idea and why that idea is valuable. Then let people know your role. Do you do UI/UX design?

Hackathon's are for those that do... they work, they make something. If you don't have a specific skill set and are just hanging around with ideas, you'll be left in the cold fast.

Here is my experience as a designer last year. I tried to do some design strategy and thinking with my group before agreeing to the tech specs - they were not interested AT ALL. I found my 10 years of running design teams was useless. Someone started building the UI/UX without even a discussion. We didn't win. Usually, in app hackathons, the person with the best thought out, and most understandable expression of what you want to get across... wins. That means, you DO NOT have to be the best coder to win, unless it's a code specific hackathon. Like compression algorithms or something.

My point, go with teams that VALUE your talents and input. A lot of times, it's good to pick your team mates in advance. There should be a chat room or some way to connect before the day.

Good luck and it's going to be a lot of fun!

Shawn Burke CTO, Buddy Platform

November 13th, 2014

Just have fun!  Hackathons are typically low key.   Typically non-technical team members do things like build a deck to explain the project, help out with design/ux, etc.  There's plenty to do.

Clynton Caines SharePoint Developer at Discover Technologies

November 13th, 2014

Use the event to meet great people and build lasting friendships (not necessarily just among your team-mates). If your idea is not picked, find another that's interesting and join them. If you don't win, then grow from he experience - build a different product, learn from the presentations, find new team-mates for your next thing, whatever... Remember that not everyone wins, but if you do, then milk it for what it's worth! :-)

Good luck

Jaymes Hines Founder, Global Events and Partnerships at Startup Edtech VR

November 13th, 2014


Aside from the great advise and insights from above, ..my own two cents are if you are to join a team, work hard with team to get them to understand demo time is best used to showcase how the app user will greatly benefit from app solution and clearly  present how-to-use app product in an easy 1, 2, 3 fashion and ending with an expected outcome that causes the new user to say yes when thinking of its intended use!

Do network and have a lot of fun!!!

Stephen Cataldo

November 13th, 2014

Know what you're looking for. I'm just guessing: a dev partner?

Pitch so everyone in the room knows what you're up to, but listen to the other pitches. Unless a *good* team with a dev starts to form quickly around your idea, disband your effort early, and go look for an impressive dev and join their team. Use it for networking, for letting a dev know you're good to work with and finding out if they are competent. 

Non-technical/non-design founders trying to get devs to work on their project at hacks is usually bad news for devs. If you do want help on your project, paradoxically you have to have a challenging problem -- if you just want a website, any dev with skills has done this too much and would be bored, no reason to join. If you have a technical problem that is unique and the solution is not obvious and maybe I would try and fail, that's what hackathons are for.

Jacob Gostylo Bitcoin Expert and Developer

November 13th, 2014

I was in a hackathon in early November. My advice if you are there to win. 1) Understand the rules and realize most people will bend them. Are you supposed to submit new code only? Still do most of the code before hand to prove out the tech. Hackathons are not a place to learn or a place to organize or a place to decide what should be done, they are a place to get things done. If code has to be fresh you still prove out your tech in pieces and copy/paste to get things done. Talk to your judges about your project before it is done. It is crappy and against the nature of the competition but that does not mean those teams that do it do not also win. If a judge already understands and likes your project and has had time to mull it over you have a distinct advantage over the rest of the field when presentations role around. I saw one team basically get their first round pass about 16 hours before official judging started. I knew it and everyone else knew it. 2) Understand the way things are going to be judged. We had sponsors judging. The winner was the team that used most of the sponsor's available tech. They were also the team who produced something that the sponsor could use later down the road. It was not something earth shattering or even very original, it was a tech the sponsor could put into their toolkit. Know your judges and correctly ascertain what they are looking for. It is most likely not what they tell the whole group. 3) Style will win over substance. It is a difficult fact of life but you are trying to get someone to understand what you are trying to do in a short period of time. In that short period of time they will not grasp the nuances of how your tech will change the world. They will be impressed by animations and will think "people will like to use this because it is pretty." 4) As a non-technical founder (who will be presenting I am assuming) it is imperative that you get sleep. Presenting is very difficult when you are out of your mind on no sleep. As a presenter the team will win or lose on your actions. Take your presentation very seriously. Work on it. Hone it. Make it clever. Get to the point. Sell your product. Don't get bogged down in the technical of how you accomplished your goal unless you have determined that is what the judges want to know about. Instead tell about what it does and why that is the best thing they will hear that day. You are not there to "support the team and build camaraderie". You have a job and you need to make sure you are not the team's weakest link. You want people to treat you fair, but that is not going to happen. Judges are people and people are insanely biased based on factors that have nothing to do with the circumstances. Best of luck!

Charlene MPH CEO & Founder, ReciproCare, Halcyon Fellow

November 13th, 2014

Thanks to all of you for the great advice!
I will look for teams that will value my content expertise and do my best :-)

Hopefully, it will be low key!

Tony Dobaj CTO at Bizzz

November 13th, 2014

Hi Charlene! Being a techie myself I have a hard time understanding why on earth you'd want to hang out with people like me for an entire weekend :-)

All kidding aside, presuming the focus is aligned with your domain of expertise, my view is that you just might be the most valuable person in the room, and here's why. Engineers tend to be a bit myopic and naturally want to illustrate their skills especially among peers. So it's all too easy for us to dive into the weeds and forget to keep the end in mind. What emerges is not a tool but a piece of art. Whether or not the sponsors can tell the difference is another matter.

So go for it! Hone your elevator speech and lean-in, you'll be doing them a huge favor. The worst that can happen is that nobody gets it and you burn a Friday night drinking beer with some really interesting people.