Don’t tell developers what to build–simple advice that should be central to all hackathons. However, it’s all too frequently ignored by hackathon organizers. Hackathons are a time for developers to learn new technology, meet new people, and pick up new skills. As a rule, it’s better for open exploration to have an unstructured environment rather than a highly regulated one. However, organizers often make the mistake of thinking that rules and structure will create a better event that better conforms to their preferred outcome.
A developer’s job is to solve problems and get around obstacles. When an organizer tells a developer what to build, they’re putting up an obstacle and a developer’s mind automatically goes to figuring out ways to get around it. Furthermore, developers can and do get upset when they give up their weekend and then are told what they can or cannot do with their time.
The most common perpetrators of this mistake are technology companies that organize hackathons. These companies often want developers to adopt their technology and thus require its use to take part in a hackathon or be eligible for the main prizes. However, this often works against them, as the participants will use the technology so they may participate and then hold a grudge forever after, never using the technology again and instead turning to a direct substitute.
I’ve sat in on hackathons where developers started shouting at the hosting company’s representative after they announced use of their technology was a requirement. I’ve sat chatting with participants during a hackathon as they’ve told me all the reasons they hate the presenting company, all stemming from being forced to use the company’s tech. If you want developers to adopt your technology both at an event and afterward, encourage adoption by offering a prize for best use of your technology or platform.
Hosting companies aren’t the only perpetrators of telling developers what to build, however. Frequently, organizers will make rules about what a hack must do to participate (e.g. be a mobile app, use any API). While this might seem like a good idea to make sure the hacks coming out of the event are what you intended, this needlessly stifles creativity. API Hack Day does a good job getting participants to use APIs while not telling devs what to do. Despite its name, the event does not require the use of any API, but often gets mostly API hacks because participants are encouraged to do them. If you want to encourage a specific kind of hack, give an individual prize for that kind of hack, or strongly encourage that kind of hack, but never make it a requirement.
A final example of telling developers what to build backfiring is requiring developers to only build certain hacks. I’ve seen organizers do everything from list ideas and say “you must build one of these” to doing pitches, selecting their favorites, and requiring participants to build one of them. At these hackathons, I’ve seen teams who wanted to build something cool simply leave because an organizer didn’t want them to. If you like specific ideas, mention that they’re cool, but again, never require they be built.
There are certainly exceptions to the rule, especially with exclusionary hacks or hacks that would deeply offend someone. These should not be allowed, however, more often than not, you can stop them from being built by creating the right environment, and talking over bad ideas with developers, so they can understand why it might not be good to build.
At the end of the day, you must remember developers are spending their time at an event and no one likes being told how they’re allowed to spend their time.
Check out more hackathon tips from my fellow SendGrid developers here.