The following is the article version of a talk I gave at SxSW 2017 which you can find here
“You either die a hero or live long enough to see yourself develop a chatbot,” or so goes the joke on Twitter. For hackathons, this seems to be doubly true. Among other culprits, it seems that the same chatbot-powered solutions get presented at hackathons over and over with little variation. While it could be said that they are solving problems, a core criterion of any submission at such an event, they are also often far from novel at this point. Why does this matter? Well, a mass collaboration also seeks and values novelty in solutions. The problem here isn’t chatbots or Twitter services to monitor something or another awful IOT device begging to be found on Shodan. Truly novel applications of these things exist and are being created, but seeing them show up in groups at every single event is the symptom of a larger phenomenon–a problem.
And the problem is?
However, chatbots are not the problem… Lazy ideas are. We might be tempted to stop there and berate developers for pitching these “lazy ideas” over the wall and declare the investigation finished and problem solved. Of course if that were the case, I wouldn’t be writing this article and you wouldn’t be reading it. There’s an even more fundamental root cause for these lazy ideas, and it goes by many names: writer’s block, the blank canvas problem, creative paralysis, etc. When faced with an overwhelming set of possibilities and a short timeframe in which to work, people often default to the safe solution instead of taking a creative risk. Given that hackathons are all about creative risks (or should be, but that’s another story), how do we fix this? We go from the top down by starting with the organizers by providing a little creative push in the form of slightly more specific challenge prompts or problem sets. Rather than asking our people to just go cure cancer, we give them a specific problem faced by researchers or organizations that has a broad range of possible approaches for solving.
In order to provide this nudge, this ever so slight push, we have to first figure out where to push and how hard, which requires a bit of introspection. Things such as the goals of the hackathon, a theme, and whether the goals and theme align with the organization’s mission and purpose are great questions to ask at this point. Are you an organization that people care about? Or maybe even that people hate? Your reputation and exposure are worth considering and will affect your recruitment. Are you attempting to get a specific software product or solution out of the event? If so, you’re barking up the wrong tree and should reconsider your approach. In short, get a good grasp on your ideas about the event and what your organization does (and why!). If you’re anything like me and the number of organizations I’ve helped through this process, you’ll discover that you incorrectly assumed many things which will require some adjusting. Don’t fret. That’s why we go through this process.
Direction > Boundaries
After taking inventory of yourself, take a look at who will be coming. What sort of skill sets do you expect? What experience levels will be represented? Will it be a diverse group? The makeup of your attendees will affect the sorts of things you can reasonably expect them to make progress on in a given time frame. Take all this as input into deciding what challenges you want to lay before the talented and creative group you will be hosting. Our goal and purpose is to neutralize this creative paralysis, so using what we know about ourselves, our event, and our people, we give them a direction. Instead of saying to a musician, “Hey, write me a song” or to a developer, “You’re a programmer. Go code something!” we are communicating a problem and doing it in a way that creates empathy. Nobody wants to build on internal tooling that just makes you more money, but people certainly care about big problems that impact social issues. And once again, we scope appropriately. A problem set that’s too broad invites writer’s block while one that’s too narrow leaves people constrained. Remember: Your hackers prefer direction over boundaries. We don’t prescribe solutions, we describe problems in a relatable fashion, provide them the tools and data, then step out of their way. These are generally the sort of people that will climb a mountain simply because it’s there. Therefore, a properly communicated problem becomes the mountain that begs to be summitted. And because we are giving direction instead of setting boundaries, our participants work with us, not for us.
A parting thought
I’ve spoken with a number of people on this topic and every single one says, “Yes! I have this writer’s block problem with {topic}” It’s not a phenomenon unique to hackathon by any means. Furthermore, while the solution I proposed here, giving people a small nudge to kickstart the creativity, is done with hackathons in mind, it can certainly be generalized and applied to any number of situations. A final exhortation for those with that technical writer’s block: While creativity can feel fickle, just be patient, try to relax, set a distinct goal, and then just attack your problem. It might take a while to get into a creative mindset, just get to work anyways and ideas will flow. We are as much artists as engineers.