Hackathons are like Petri dishes for innovation. When held in-house, they challenge institutionalized ways of thinking and stimulate change from the inside, encouraging people and teams to feel accountable for new directions. They also develop cross-functional talent, promote a culture of collaboration and serve as a source of inspiration.
I recently wrote about why game companies should run internal hackathons in the first of this three-part series. Now, here are a few key strategies to organize these events:
Rules for Running a Hackathon
Rule #1: Cease normal business operations during the event. The hackathon should be similar to a company retreat -- expect employees to be working on intensive projects that improve the business in some way, yet allow them to “turn off” from regular, non-essential tasks. No one should feel pressure to handle their normal responsibilities in addition to their hackathon projects, which requires advanced planning by the company’s leadership, managers and employees. This allows everyone to truly invest their time and energy in projects during the short hackathon period. If you remember one thing from this article, this is my strongest recommendation to successfully run a hackathon.
Rule #2: Don’t have too many rules. Give your staff the opportunity to get involved in projects that they’re passionate about in an organic way. Many hackathons begin with a pitch meeting, which allows project leaders to explain their vision and recruit team members who are also excited about the work. To encourage participants to execute business goal-oriented projects, create a broad event theme or award categories in the areas of focus. For example, if a business goal in 2014 is to operate in a “mobile first” mentality, implement award categories that reward mobile innovation. I also suggest offering a few awards that are based on employee votes, which motivates teams to produce great work that will impress their peers. A healthy level of competition helps build strong teams and pulls out the best ideas. Awards guide projects into the right focus areas, producing solutions to existing problems and positively impacting the business overall.
Rule #3: Not all hacks need code. Although hackathons often imply technical, code-driven solutions to challenges, not all hacks and hackers must be technically-based. Game companies are comprised of a wide range of employees, from community managers, to copywriters, to HR staff, who have great ideas to improve the company but don’t necessarily need a technical solution. Hackathon projects could range from streamlining the company’s marketing practices to finding new ways to make the office feel more creative and collaborative. A loosely-structured hackathon invites all employees to submit their project ideas, whether or not there are technical elements of the project and whether or not there is bottom-line value. One of the less technical and bottom line-driven hacks that has come out of our event is a video to our players that humanizes the GSN Games brand. By introducing a variety of team members and offering a behind-the-scenes look at the company, we build personal connections with our players. I recommend advising non-technical and technical staff members to cross-pollinate each other’s projects to understand the business more broadly and obtain an insider’s view of the project production process.
Before organizing a hackathon, think about the goals you hope to accomplish, as well as the strategies and logistics that will resonate well within your company culture. After the event, hold a postmortem to review if the original goals were achieved. However, when it comes to larger, less tangible organizational goals, such as cultivating a collaborative culture, remember that these shifts will take time. I recommend hosting hackathons semiannually to instill them as an integral part of the culture and empower employees at all levels to step back from their day to day and reevaluate what they’re doing, why they do it and how it could be improved with a hack.
How does your company structure a hackathon? How would you organize a hackathon so that involvement is organic, rather than mandated?