HackerNest posted an articleThe legend of SuperConnect, or how a circle of nerds saves the world see more
The year was 2018. Justin Bieber was still popular, governments were still surprising, and hipsters were still into obscure bands you'd never heard of. HackerNest was knee-deep in a big organizational revamp and one our projects was to make the Tech Socials even more effective at connecting everyone in tech.
We came up with (and heavily battle-tested) "SuperConnect" -- a quick, deceptively simple, effective way to get you talking with the right people. It catalogs the room so recruiters and job seekers and cofounders and people with common interests can all find each other and do stuff together. The frenetic matching that follows is awesome to behold. Maybe they trade notes on frameworks, form D&D groups, or build Skynet. That's what we assume, anyway, since we don't really track outcomes that well.
Here's the idea. Participants stand in a circle and each get 10 seconds to tell the room who they are, who they want to meet, and one thing they care about. After that, they go talk to each other. Easy. It's important to point out that volunteers don't miss out -- we shut down our stations to encourage them to participate. Not so shameless plug: volunteering is fun and makes it even easier to talk to everyone.
We went through so, so many iterations to find just the right thing that would:
- be quick, scalable, and replicable in every city we run in
- get participants to share just enough info to spark conversation
- help folks help each other - the first step is knowing someone could use support!
- encourage people to speak (in short bursts) in front of a crowd and build confidence
- be easy to indulge, with no strings, commitments, or work required before or after event
The resulting SuperConnect, in all its two-dimensional elegance, became our weapon of choice. The format is low-stress. You don't need to think too hard and the very important 10-second limit is strict. It's not enough time for someone to:
- feel nervous
- bore the crowd
- obnoxiously pitch
- do anything irritating like try to be funny or break the format by showboating or whatever
We do need to cut folks off at 10 seconds. If we let some people drag on, it's unfair. Everyone gets bored and annoyed and tunes out. 10 seconds makes people focus and listen -- or they'll miss hearing from that one person they really needed to meet.
Don't be fooled by its simplicity; SuperConnect works. We've had only glowing feedback from folks who've participated. And there's no pressure: if you change your mind, just back out of the circle. No harm, no foul.
So! Come to a Tech Social. 10 seconds could change your world. You'll have fun. Promise.
Shaharris posted an articleHackathons are terrible for innovation. see more
Updated August 2019.
Disclaimer: No flowery language or elegant arguments; just a list of reasons why your company/organization shouldn't run public innovation hackathons.
Source/credibility: 8+ years of running epic hackathons with partners like Facebook, Amazon, Dove, Grindr, Deloitte, the Canadian/UK/US governments, etc.
TL;DR: Hackathons rock, but don't expect innovation or solutions to real problems.
What is a hackathon?
Many versions (e.g. design jams, business plan competitions) exist, but the core began as a computer programming competition. Just like how the word 'event' describes a wedding, a boxing match, and a funeral, the word 'hackathon' also has many applications. Hardware, internal, learn-to-code, infiltration, et al. For clarity, the 'hackathon' this article refers to is the popular 'public innovation hackathon'-type outlined below.
Typical public innovation hackathon characteristics
In-person event, overnight 24-48 hours, public call for participants from theme-related students/groups/mentors/mailing lists, coding only allowed at event, local pundit judges choose ranked winners based on 1-3-minute demos, token cash and prizes awarded, promises of funding/opportunities if teams create "something amazing". Hackathons are usually conceived from some variation of this logic:
"Tech solves problems in so many industries. Why not ours? Traditional approaches haven't solved our big challenges. Let's think outside the box and get fresh ideas from tech nerds not "held down" by industry standards and expectations. A hackathon does this by gathering 300 innovators for an inspiring weekend of pizza and code to solve our problems. We'll surely get at least 5-10 disruptive ideas and 3-5 brilliant teams building working prototypes."
This all sounds perfectly logical and reasonable, but reality tells a different story.
Reasons not to run a hackathon
(in almost no particular order)
1. Hackathons don't solve important or persistent problems.
Short timeframes force teams to pick the simplest, quickest, easiest thing they can build a pretty demo of and submit in time for judging -- or they won't win. Solving big, endemic problems takes time, effort, and understanding -- that won't fit into a 3-minute demo. If things were that easy to solve, they wouldn't be problems.
2. Output isn't likely to be "something amazing".
There's just not enough time/care/planning/incentive/motivation/sustainability. Particularly for teams that form "day of" - a hackathon is 1 hour of frantic ideation followed by 23 hours of typing and sleep deprivation... not a recipe for success. Zombies don't code or present well.
3. Winners aren't always winners; cheating is common.
For a big enough prize, some teams will build their demo "from scratch" 6 times leading up to the event -- good luck proving it. Others are actually fully-formed, product-already-developed startups looking for a good PR launch platform. It's easy to blow away judges when they're comparing 2-day hackjobs to a product you've worked on for 8 months. Journalists and investors love stories about geniuses who accidentally build amazing products and get 'discovered' at hackathons.
4. Hackathons are wasteful, inefficient, and demoralizing.
A big hackathon may have 300 participants working on complex problems all weekend. That's 14,400 hours of high-functioning human effort. Let's say 5% win prizes and praise. To the other 285 participants, the hackathon basically says, "Thanks, you weren't good enough to win. The 13,680 hours of hard work, effort, and good intentions you poured into the weekend amount to little more than 'a fun learning experience'. Go home."
5. (Good) Hackathons get expensive; explaining this to people is an uphill battle.
A respectable Sat-Sun hackathon has at least 8 meals (if you're not fed at least every 6.5 hours, leave -- it's bad for your health/performance). Catering for 300 participants and 60 volunteers/organizers/mentors/sponsors at a very conservative $13 average per nutritious meal (excluding tax, staff, delivery) costs $37,440. Unless you're crafty and getting stuff donated, you'll also need to pay for venue, A/V, and furniture rental, staffing, major event insurance, prizes to convince 300 nerds to give up their weekends, ads, safe late-night volunteer transportation/housing, shirts and SWAG, banners and signs, extra cleaning, parking, salaries, and so on. A decent hackathon can easily run $150K+.
Side note: Eventually, some well-meaning cat who doesn't run events may want to properly educate you about what hackathons cost. They heard some company's amazing hack-fest-day-athon (where Kanye did a jazz flute solo at halftime and bought all the winning teams) only spent $15K -- they locked nerds in a room with pizza and caffeine and had a time travel app the next morning. A good strategy at that point is to excuse yourself and then try to find a window to climb out of.
6. Judges don't have magical judging skills.
The pundits, high-rankers, and minor celebrities that hackathon organizers recruit as judges generally lack the market/customer knowledge, experience, and intuition for any sort of calibrated demo evaluation. They may be department heads and CTOs, but unless they've actually evaluated hundreds of industry tech demos (like an investor), they have no clue what they're doing and it's 100% not their fault.
What happens when you go into a big parking lot and ask a non-driver to pick the car with the best handling? They pick the newest-looking sports car. Hackathon judging is the same.
Dirty secret: non-tech judges favor the prettiest/slickest presentation because they figure the 'polish' implies the team's technical competence.
Dirtier secret: tech judges do the same thing.
7. Judging is pretty ridiculous.
Ironically, hackathons as coding competitions judge projects on pretty much everything except code. Even with perfect documentation, proper code review is time-consuming and logistically unfeasible at standard hackathons. The 1 to 3-minute demo format makes it a contest of design and presentation skills, not technical prowess. Hackathons are won by designers and charming presenters; teams can win by making pretty mockups with little actual code because they know nobody looks under the hood.
After about 6 or 7 intense demos, the teams and demos start blurring together. Since judges don't take good notes (because organizers don't coach or set them up for it), they'll be confused and forgetful in deliberations, resulting in even-worse "judging".
8. Hackathon demo and judging processes are usually an afterthought.
Almost all hackathons feature the rapid-fire, one-after-another standard demo process to try to condense demo time while maintaining fairness. Here's some math. In a perfect world, each demo averages 7 minutes: setup (1 minute), demo (3 minutes), judge Q&A (2 minutes), takedown/transition/scoring (1 minute). Demos and judging for a small, 15-team hackathon (10-minute judge washroom break) will take 2+ hours. Without rock-solid processes, demos are sloppy and unfair.
300 participants, 5 max per team means 60 teams minimum (300 maximum). The unrealistic minimum of 60 teams doing standard demos will take at least SEVEN (7) HOURS. Imagine being on an exhausted team that worked 24-48 hours to shine on stage for 3 minutes -- and then has to sit through 7 hours of demos to find out who wins. Nuts, right?
Just to keep things manageable, HackerNest had to invent a new demo-and-judging system/process for big hackathons (100+ teams) that ran under 2.5 hours without reducing demo time. HackerNest Judging is thorough (teams can demo multiple times), transparent, and devastatingly effective. It's not complicated and runs very smoothly -- we're super proud of it -- but it took a lot to manifest.
Running a hackathon without having a fair, meaningful way for teams to showcase all their work is really terrible and, unfortunately, really common.
9. Participants aren't experts; mentors can only help so much.
Participants are clever and well-intentioned, but rarely subject matter experts. Mentors can help, but there's only so much they can impart in the 3 hours they spend with several groups of random people building things for fun.
There's a lot of, "Yes, CompanyX built the same thing you came up with 4 years ago, didn't you know?"
10. The overwhelming majority of teams don't (plan to) survive the weekend.
Teams don't expect to continue projects past judging. Most are formed ad hoc in order to participate -- whoever has calendar availability. Even if they win, they aren't likely to quit school/work and risk everything to spend the next 6 years toiling and building a stressful startup, managing a team, getting financing and fundraising, etc.
Teams break up, go home, and continue their comfortable lives.
11. IP is handled really, really awkwardly. And badly.
Here's a fun scenario: CompanyX runs a hackathon. Teams participate, win, then break up after the weekend to go back to their regular lives. CompanyX likes the demo that TeamX did, so they decide to build it as a feature of their product. TeamX sees this and sues CompanyX for stealing their idea.
CompanyX laments, "Oh woe, if only we'd read HackerNest's article before running this crapathon, we'd have avoided this gerbillion-dollar lawsuit. Darn it, darn it all to heck."
12. Hackathons are great for ideation.
Yes and no. Traditionally, teams are pitted against each other and competing to win. Info and ideas get shared within a team, but not between teams. So yes, you get different perspectives and that helps generate new ideas -- but you're limited to the people on your team. You're not really taking full advantage of the room by picking the brains of the 295 other clever people.
This should be enough to get you thinking. There are better ways to innovate.
If you know someone who needs to run a truly amazing hackathon (or who needs to be talked out of one), we can help. Please contact us.