How to Run a Collaborative Hackathon: The Cheatsheet
A hackathon is basically like a two-day party with programming. You want people to feel like there will be good people, good food, good space, good vibes all around.
One thing the publishing industry has working strongly in its favor: people of all disciplines love books. They love reading and love libraries. There is both enthusiasm and concern for the industry as it progresses through a digital transition.
But the challenge in publishing: the entire ecosystem has to move together to get into the future — the writing, the engineering, the retail experience, the curation, the legal constraints. It’s like the coordination needed in a three-legged race — only one run by spiders tied together.
Our goal with the CODEX Hackathon was to nurture the face-to-face relationships that we’ve come to realize are so important in publishing from our years working on Plympton, a literary studio. This is an industry based on individual trust (the place to see that in action is at the Frankfurt Book Fair, where you can watch a giant pas-de-deux of meetings after meetings in the great halls).
We wanted people to leave CODEX with relationships that they could build upon in the future — whether between app developers and literary journals, or Big Five publishers and design-thinking folks.
At the end many attendees said CODEX Hackathon was the funnest hackathon they’d ever been too — well-organized, collaborative, good food, interesting and diverse people, useful tools, and an inspiring space.
But it took a lot of effort from a lot of folks to put it together (and a fair bit of stress, once we discovered the hackathon was the same time as Pride Weekend). So we wanted to capture some of our learnings for others in the spirit of having more well-run collaborative hackathons in the world.
We took inspiration from the excellently executed Hacking Journalism event at Condé Nast in New York in January (which had Lenny Bognodoff and Jeanne Brooks among its organizers). So this is a more formalized guide we would have wanted before we started planning.
Strong Branding and Theme
We wanted a good name for the hackathon — one that would have a shelf-life since we hoped to hold more than one, if all went well.
After a bit of brainstorming on Slack, we came up with CODEX, which worked on many levels for all the different constituencies. The “codex,” the bound book, has strong literary roots. Also “Code X” gives it a whiff of programming nerdiness. Last, there was a historical connotation of innovation. The invention of the codex allowed for random access to data for the first time. Before that, the scroll only allowed for sequential access (The developers loved this fact).
So with name in hand, we asked designer-developer Allan Lasser to create a logo. We needed the design to do a lot of things. First it had to accommodate both interpretations of “codex” and “code X.” It also had to keep open the possibility that CODEX brand could expand beyond hackathons. (Fellowships, conferences, etc.)
Allan came up a great logo concept — pages linked together, each with a single logo. It was clean, evoked publishing and also intertwined the “Code X” interpretation of the event. It gave us the flexibility to extend that logo to other CODEX events.
We went back and forth on the font choices and ultimately settled with Roboto, because looked the best skewed and also came with a big font family. Then he put it against a colorful background with our Recovering the Classics covers.
We also used the single X-on-a-page as the avatar for Twitter and other places (like Github). With logo in hand, we could set up a page on Splashthat.
Our developers insisted on having a theme, instead of being totally open ended. More Slack, we chose “connecting,” which was pretty flexible, but gave just a hint of guidance, for those who were looking for it.
Application Process
We decided to have an application (rather than registration) process for CODEX. Partially, this was because we had limited capacity — around 100, and we wanted to make sure we got good people. Also, it made applicants take their commitment to the hackathon more seriously. We basically loosely adapted the form from the Hacking Journalism event, with a few extra questions like “What’s your favorite book?”
The original application form was done on Wufoo, but we ultimately switched to Submittable, even though Submittable requires folks to register with name and email before they can submit form. We made the switch not only because Submittable was a sponsor and willing to help us set it up, but because it gave us a lot more control over the relationship with the applicants over time, and had an good review set-up. Plus, their roots were in literary journals.
We were initially resistant to forcing people to register before applying, because we felt it caused too much friction. But ultimately came to see the right choice. The Submittable CEO said that forcing the registration increased conversion by double digits. In large part, it was because applicants could save their forms in, which allowed them to come back later if it wasn’t finished.
Sponsors and Partners
We worked hard to get really good sponsors and partners for the hackathon, both in tech and literary world. On the literary side, we came in with the New York Public Library, the Digital Public Library of America, and Harvard Book Store as partners, since we are working with them through our Recovering the Classics project. But we needed strong tech cred as well. GitHub’s generous offer to use their beautiful space (complete with a replica of the Oval Office) for an opening night pop-up gallery gave us a huge boost of tech cred. For all my stalking GitHub execs through investors and friends, I ultimately found success through just cold-applying through an online form at community.github.com. Mailchimp (Mailkimp?) also was an early and generous sponsor. The other early tech cred came from Dropbox thanks to my one-time neighbor Chris Varenhorst, who heads developer tools there. (This is where being based in Silicon Valley helps, because you just know these people).
Since we wanted to be inclusive, we made a big effort in making a range of price points that could work for everyone, from Fortune 500 companies to small bootstrapped startups.
We divided the organizations into sponsors and partners. Sponsors were entities that contributed money, whereas partners provided in-kind support rang from from data (Publishers Weekly) to logistical organizing (Chronicle Books).
It took some thought and creativity in shaping the packages so you could tier the sponsorships appropriately. This generally meant allowing the higher-level sponsors to access the RSVP list, or offer a tool or a challenge, or give a longer talk in the intros. Basic sponsors were basically just showing a logo.
And just as with investing, when you have first money in, it gets a lot easier to get more. The Knight Foundation, which has had done a lot of work with libraries, was the first to commit hackathon funding (Thank you George Martinez!). Once that was made, we knew we had enough money to at least pay for pizza for a hackathon for every meal, so we could host that. HarperCollins, which is one of the most innovative of the Big Five, joined in with a big commitment.
Ultimately we raised tens of thousands of dollars in sponsorship money in amounts ranging from $250 to $10,000. And we chose to use that money in a very strategic way — travel stipends.
Publicity
Once we had a critical mass of sponsors in hand, we felt confident in going public.
This part was stressful, and very much like throwing a party. What if you hold a hackathon and no one shows up? You will be judged. Also, we had to attract people locally and nationally, so needed a dual campaign.
Dan Schultz, one of the CODEX volunteers, pushed it out to his MIT Media friends, Mozilla, and tech journalism circles both inside and outside the Bay Area.
We asked friends in the Bay Area to send it over open company email lists: Quora, Twitter, Stripe, IDEO, etc. (interesting to learn which companies don’t have open email lists!) I emailed CS professors at Stanford asking them to get the word out to their students. This proved fruitful as Stanford now has a neat new English+CS combo major.
To get some national visibility among developers, we also asked John Resig (creator of Jquery) to tweet about CODEX, as well as Craig Mod (who has a huge book-innovation following). Both of those posts got a number of retweets and favorites. We even got permission from both of them to promote their Tweets via Twitter’s advertising system.
Then applications started rolling in. We knew it was a good sign when we started getting messages about the hackathon from the email lists we were on.
A key attraction was that we offered travel stipends.
Travel Stipends
Some hackathons use their money for big prizes (five-figure checks are pretty common). But given our goal of building relationships, we decided to take our sponsorship money and channel it towards travel stipends. Thanks to our sponsors, we were able to give out well over ten thousand dollars in travel stipends to folks from all around the United States and even internationally (Mexico and Canada).
One reason travel stipends help create a good hackathon. If you are pulling in folks locally for a hackathon, you often lose people on the Sunday, because they have other things to do — church, picnics, prior obligations. But if people have traveled in for the hackathon, it’s their main priority. They will be there. So by giving out dozens of travel stipends, it guaranteed we had a very dedicated core group.
A quick early offer of a $250 subsidy was often enough to tip interested folks into coming to the hackathon. When we first announced CODEX we didn’t know how much sponsorship money or demand we would end up with, so we were cautious in metering out the stipends. It was impressive how many people were able to leverage that initial $250. One person used our commitment to get work, a library, to pay for the rest of the trip.
We eventually were able to offer larger stipends in specific circumstances: if someone was willing to help be an organizer for the hackathon; if they were willing to specifically work on a sponsor challenge or tool; if they were filling a gap we had in our line up (a bookstore or a literary journal). At that point, our general rule was that we would pay for the roundtrip plane ticket, but that they had to find their own place to crash.
And some of our partners offered travel stipends targeted specifically at their communities. For example Gitbook offered a generous $1,200 international stipend, which included housing, based on proposals. That was good for us, because the announcement of the stipends to their communities drove more awareness of the hackathon overall.
Diverse Backgrounds
We knew that in order to have a good hackathon we wanted people with different backgrounds: engineering (back-end and front-end), editorial (writers and publishers), design (graphic and UX), retailers (online and off-line). We were able to use our application process (done through Submittable) to keep an eye on the balance, and also use the travel stipends to curate and recruit folks.
Some of the non-tech folks were a bit nervous about never having “hacked” before. But we insisted that they were among the most important folks there, because they had a perspective on the problems and challenges the industry was facing. If engineers go off and try to tackle publishing from an engineering perspective, they come up with a limited number of projects.
Important. Get non-techies into a hackathon! They will often have the more interesting ideas and problems to solve.
What was lovely was the kind of developers and engineers we attracted. They were people who loved books! As one MIT PhD described it, “We’re humanities people trapped in a developer’s body.”
Stanford d.School Workshop
How do you get cool projects?
Some folks came into the hackathon with a team and idea in mind, but most were waiting to be inspired. So we needed to find a way to create good teams who could tackle interesting questions.
We were super lucky to connect with Erik Olesund, a fellow at the Stanford d.school who started our hackathon by holding a design thinking and innovation workshop on Saturday morning.
In about an hour, Erik took our CODEXers from ice breakers to fully formed teams and ideas using Post-It notes, Sharpies, and a lot of pairing exercises.
This process was hugely useful, and one of the best ways I’ve seen a hackathon start.
Tools, APIs, and Data
We made a specific push to get a variety of tools and data for attendees to play with. These are the tech equivalent of construction paper, pipe cleaners, tinfoil, colored felt and markers. In combination things become really interesting.
But we wanted to have both editorial and tech resources. Editorially we got short stories, public domain classics, Recovering the Classics book covers, serialized novels. We also got reviews data from Publishers Weekly.
One thing that can make a hackathon appealing to programmers is to get early or exclusive access to tools that are not yet public. We were lucky in that a number of companies had new APIs that they wanted to test out and get feedback, including Wattpad and Mailchimp. We also lobbied our engineering friends at Pinterest to get folks onto the whitelist for their API. Last, we pushed on some publishing startups to make their internal APIs public facing, including Shelfie for their OCR ability and Zola for their Bookish recommendation engine. The Shelfie OCR API was of interest to me, because I’ve wanted to get a dating app based on books created ever since I went to another publishing hackathon two years ago.
Basically, you get very powerful results once you start chaining the tools together. One of the most practical projects to come out of the hackathon was Goodshelf, which is what you would get if Goodreads and Shelfie had a love child. Basically, the Shelfie API (which can take a picture of a bookshelf and return a list of books) combined with the Goodreads API (which allows you to add books to your bookshelf). As a result you could take a picture of a bookshelf and add those books onto Goodreads, which is easier than keying them in by hand, or taking pictures of bar codes.
Beautiful Space
One perennial question for the hackathon organizer. To hack all night, or not? Part of the aesthetic ethos of the hackathon is to see skinny bodies sprawled out sleeping on the table in the middle of the night.
But it’s actually hard to find spaces that will allow you to stay all night for staffing and security reasons. My developer friends said that you need to stay open until at least 10 p.m. to get a good productive window after dinner. But it’s not necessary for folks to stay all night because of diminishing productivity. Rather you want to stay late enough on Saturday but open early on Sunday.
Also, you want to have a beautiful space that has reliable wifi, good breakout areas and a common area for presentations.
A few weeks into the planning CODEX we realized we had a major challenge. The ALA conference was at the same time as Pride Weekend. That basically knocked out any spaces along Market Street because of the Sunday Parade (and my developer friends were insistent that you could not switch a space mid-hackathon). We never realized how many big tech offices are located just off of Market Street. This made for a very anxious scramble for a few weeks trying to find a place.
We were lucky to link up with Code for America (in part because I bumped into its director, Jen Pahlka, in a neighborhood Ethiopian restaurant). Parisoma, which hosts hackathons, was also a great option in SoMa.
CfA has a gorgeous space with great wifi, lot of outlets and plenty of breakout rooms, including a downstairs area with yoga mats. It was also located safely far away enough from the heart of the Pride Parade. And thanks to their ops people, they were able to have folks stay to host us until 11:45 pm Saturday night (enough time so the staff could take the BART home).
Highly recommend for anyone thinking of doing an event there.
The Schedule
Excluding our opening party on Friday night (which had no talks, purely social), the hackathon itself ran 10 am to 11:45 pm on Saturday and 9 am to 5 pm on Sunday (wanted to get them out before dinner).
We kicked off the morning with some simple talks from a mix of sponsors and partners with interesting tools. Then those who had a project in mind just started working, while the vast majority of folks went to the Stanford d.school workshop.
Catered meals were delivered, but there were no official meal breaks. During dinner on Saturday we held some longer, opt-in talks from Kickstarter, Poetica and Codex Press for a smaller crowd.
Presentations started at 3 pm on Sunday and ran for two or so hours. People broke for dinner, and then some folks reconverged for an afterparty at my place, which was only two blocks away from Code for America.
Food
We had great food, because a number of the organizers really cared about food (I’ve even written a book and produced a documentary on food).
We basically gave Zoelle a budget to go find “not-white people food” and “not-lame” breakfasts. Since so many companies in Silicon Valley feed people all the time, we wanted something distinctive.
Our meals included Malaysian, Filipino, Chinese dumplings and pastries, arepas and late night deep dish pizza (gotta have second dinner on the Saturday night). The cost for the lunches and dinners were generally around $1200-$1500 for 100+ people. And we made an effort to use small emerging businesses where that was a significant catering order for them.
We supplemented the catering with snacks from Trader Joe’s and Costco.
Attendees keep mentioning about how yummy the food was and how well-fed they were. This is a list of the caterers we used.
Presentations
We wanted to use a single computer for the presentations to keep things efficient. We required everyone to register their projects on Hackdash as part of a nice dashboard we created for the event.
Doing so had the benefit of producing a single link that can be shared and circulated after the hackathon.
A lot of people showed up for the presentations, way more than were actually there during the heart of the hackathon (where were these people coming from? They weren’t hiding out in the basement).
We had more than 25 teams. We gave them each 3-ish minutes to present, no Q&A. Some just did a slide presentation. Others used the video camera on the computer to project an iPhone app on the screen.
With that many projects, it took a long time to plow through them. Almost two hours. And then we were done.
Prizes
We gave out mostly book schwag from Litographs, Out of Print, and publishers. Some of our sponsors, like Mailchimp and Dropbox, also offered prizes specific to teams which used their projects.
Final Thoughts
In some ways, a hackathon feels like startup. It can look totally smooth from the outside even as you feel things are going wrong every which way from behind the scenes (coffee shortage, AV glitches, missing book shipments, canceled flights).
But at a certain point, if you throw enough interesting people together with a wifi and a mission, it just works.
We love our CODEX Hackathon experience enough that we’re going to do it again, January 8–10, 2016 at the ALA Midwinter Conference in Boston. Save the date. It’s going to be bigger and better next time around.
Questions? Email jenny[at]plympton[dot]com.
