How to hack a hackathon

By @ryantmcknight | Posted: April 28, 2016

If you get the opportunity to attend a hackathon or startup weekend, go. These events offer challenges that can make you sharper on the job and connect you with a lot of awesome people in your area.

The several hackathons I've attended in the DC area have helped me to:

  • Hone my ability to lead and manage through verbal persuasion (because no one is a superior)
  • Pick up new technical skills and sharpen existing ones
  • Make professional connections and new friends with similar passions
  • Improve my presentation and public speaking skills

These benefits do come at a cost, though. Hackathons are hard. They force you to step out of your comfort zone and tackle unfamiliar problems.

Having recently completed a NASA hackathon, I decided to capture some of the lessons I've learned over the years. What follows is sort of a playbook or "how to" guide for hackathons based on my experiences. It is totally biased and by no means comprehensive. Use it to start thinking creatively about common questions and problems a lot of hackathon participants encounter.

How do you go from concept to "hacking" in a timely manner?

Let's face it. Most of us love to come up with new ideas and debate the suggestions of others. At a hackathon, it's easy to head too far down this road and waste a lot of valuable build time.

You can guide a team's discussion toward actual hacking by answering a few key questions on a whiteboard.

  • What is the specific problem we are solving?
  • Who is our target user?
  • What is the most basic version of our proposed solution?
  • Who is responsible for which part of the project?

The easiest step should be defining the problem. If your team can't agree on this within 20-30 minutes, you might want to break up into smaller groups or find a new team.

Get specific about your user, if possible. If you are creating an app for children, don't just make it for all children, create it for "high school students – 14-18yos" or "kids ages 5-10." Each of these groups will have very unique problems and demand a different user experience approach.

The most basic version of your proposed solution should be something doable in a weekend – a proof of concept. Come up with a super simple prototype or "minimum viable product" (MVP). This can even be static web pages that simulate an app. Let everyone know that you can build on the basic concept if you all have extra time (you won't).

How should a team split responsibilities?

The following suggestions assume that you are creating a physical or digital prototype.

  • Build team
  • Content/strategy team
  • Pitch team (comprised of members of build and content)

The build team will consist of team members who have the technical skills to develop your MVP. These are your backend developers and frontend designers, hardware/maker types, etc. This group will create the actual digital or physical prototype.

The content/strategy team will consist of team members who have soft skills or technical skills unrelated to the creation of the MVP. These are often business professionals, marketers, scientists, etc. This group will, as needed, provide the content for the product, further develop and define the project vision (beyond the MVP), craft a business plan, and prepare the pitch and slide deck. If you have a designer on the team, she or he will likely help out the content team with the creation of the slide deck.

The pitch team draws on members of both the build and content teams. Your build team will likely be working on the MVP until the very last minute, so members of the content team should take the lead here. After a content team member describes the problem, identifies the user, and reveals the proposed solution, a member of the build team should walk the judges and audience through a demo of the MVP. The content team can then wrap things up by describing how the MVP might be developed further in the future.

How do you keep a project and team on track toward a common goal when no one has actual authority?

This is a tricky one.

Is selecting a de-facto team leader a good idea? What if that person sucks at project management, providing feedback, or loves to micromanage? Any of these issues can quickly kill an entire team's motivation. I've seen it happen more than once.

I don't have a perfect answer to this question, but here are my suggestions:

  • When you define the project solution at the beginning of the hackathon, make sure everyone has a clear project responsibility. If someone is just standing around waiting to "help," this will cause problems. That individual will feel left out. Also, other members of the team won't want to stop working on their pieces to find work for that person.
  • Limit your unsolicited feedback. You might want to have clearly defined "review" breaks every few hours so that all teams are on the same page. It's also a great way for everyone to contribute. If someone is giving too much unsolicited feedback and it's upsetting people, check it. It'll kill team motivation.
  • When you provide feedback to another person, be persuasive, but make it clear that you are not demanding action. You are making a suggestion. You are no one's boss. When you receive feedback, thank that person but feel free to reject it.
  • Be okay with failure. Don't get pissed if the project isn't what you envision or if you disagree with someone. It is not your project. I repeat, it is not your project. It is the team's project. In a hackathon, you should be ready to embrace your own, and other people's, mistakes, lack of knowledge, and lack of technical expertise. Seriously, just have fun and enjoy creating new relationships.

Is a hackathon more about learning and supporting team members or completing your project and winning?

How you answer this question will depend on who you are. At hackathons, you'll meet both the Mr. Rogers and Ricky Bobbys of the world. Some people are there for the inclusive, volunteer experience, excited to help fellow team members grow in their knowledge and technical expertise. Other people are there to build and win. When you get people at the opposite ends of this spectrum on the same team, there will be conflict. I've seen it happen.

When selecting who you will work with, ask questions that can help you know if a person cares more about having fun or winning.

Personally, I find myself torn between both perspectives. I love winning. I love giving 110%. I value hard work and want my team members to share this perspective. At the same time, I want to support all the people at hackathons who are excited to start learning new technical skills. It's a difficult balance. Not sure I have a great answer for this question. Just be aware that it is a thing.

Should you ever walk away from a project or team?

People leaving projects and teams is pretty common at hackathons. I've seen entire groups disband over the weekend and not pitch.

Whether or not you should take that route is totally situation dependent. However, I believe it is OK to walk away sometimes. This is especially true if the project continues after the initial weekend.

Here's an example scenario. Imagine you have a team member who decides to assert authority and continually makes statements like, "You are going to give the presentation. I am firm about this." and "I am going to project manage you right now." Sometimes, you can just ignore this person. Other times, you can kindly confront the person and let him or her know know that you feel micromanaged or that all of your ideas are being shot down. Usually, this does the trick. Most people are well-meaning and don't even realize when they are being a drag on team motivation. If you clearly communicate the problem and the offending behavior continues, it is OK to gracefully withdraw. Don't subject yourself to that kind of mental stress when you have an option.

Is a hackathon supposed to be fun?

Yes. If you are not having fun, something is wrong. Figure out the issue and address it – starting with communicating the problem to the team. If the problem can't be fixed, assess whether or not you want to gracefully bow out.