Last week we were excited to kick-off our first OpenTable Global Hackathon, underway simultaneously in San Francisco, Los Angeles, Mumbai, Melbourne, and right here in London. Having personally never attended a hackathon before let alone helped organise one I was initially daunted, but with some careful planning, good suggestions from the team and a fair amount of making it up as we went along, the end result was quite a success.
This post discusses what format our hackathon took, what challenges we faced in coordinating across countries, the experience in the London office and what we learned.
The basic format
The hackathon was conceived in our San Francisco headquarters and could easily have been confined to that one office, but I was delighted to learn is was intended to be a global event from the outset. The basic format, described below, was however optimised for our SF office.
In the weeks leading up to the hackathon, individuals were asked to submit their hack proposals. Idea prompts were circulated such as "engages and delights diners" or "socially connected", as well as the judging criteria; Originality, Feasibility, Likely to adopt, Fidelity of prototype, Business impact and Captivating presentation.
One week before the hackathon, our San Francisco office held a 'happy-hour' in which everyone taking part mingled and discussed ideas. This social event encouraged the developers, designers and product owners to self-organise into teams and submit their proposals in advance.
The hackathon itself was devised as a 2½ day event, running from Tuesday morning to Thursday lunchtime during normal working hours, with OpenTable providing breakfast and lunch. Live incidents or outages still had to be fixed, but otherwise the teams would be uninterrupted for the duration.
The hackathon concluded with each team having up to five minutes to present their hack to their colleagues and the judges. The awards were for the top three hacks, special CEO and CTO's prizes, and an open vote - and generous cash prizes and gifts were up for grabs.
Tweaks for the London version and building enthusiasm
The big headache in London that we always have to live with is the eight hour time difference between London and San Francisco - and the same constraint obviously existed for the hackathon. Each team concluded that it wouldn't be feasible to form teams across the offices so all our build-up and actual hacking remained independent. However we submitted our recorded presentations for the final judging along with the rest of the company.
To get our ideas flowing we set up a kick-off session which we called "Beers and Ideas" - half an hour at the end of the Friday preceding the hackathon. Each individual with an idea was asked to pitch it to their colleagues with the intent to recruit team-mates. This format seemed to be popular and rolled seamlessly into our regular Friday office drinks where the 'recruitment' could continue. Some engineers and product managers pitched their ideas even though they couldn't attend the hackathon itself.
Our design team in SF supplied posters which we put up around the office to raise awareness of the event amongst colleagues and invite them to submit ideas. We were also sent t-shirts that were handed out to the hackers.
One rule we introduced in London was that every hack team had to include someone with which you do not normally work. This was not an arduous stipulation and all teams managed to cross-pollinate with each other.
Just before we started hacking we had a short meeting to finalise the teams and projects. This was the last opportunity for anyone without a team to join an existing team or join forces together. Most people had already made their decisions, but three or four people found their projects at this late stage.
Our London hackathon culminated with a joint session at which we watched each other's demos. All teams decided to record in advance rather than giving a live presentation and we gathered to watch these often very funny videos as a group.
Finally, we introduced a "Best Hack in London" award. This bonus, regional award added some drama and tension, preventing an anti-climax at the end of our day - as we had to wait until 1am to hear the global awards live from SF.
How did it go?
Overall, the event was a big success. Five teams in the London office worked on six ideas, and 45 hacks projects were undertaken globally.
This positive outcome was despite a slow start. Having never held a Hackathon at OpenTable before it felt like many people were cautious about how successful it would be. In the UK we enjoy "20% time" - that is 20% of each sprint for engineers to undertake personal development, prototyping and other non-sprint work to grow themselves or the business - and so for many, a hackathon seemed like it could be just another 20% time, nothing out of the ordinary.
However once we got under way it quickly became apparent that it was much different. The advance planning, focus and critically the lack of interruptions clearly differentiated this from our typical two days of 20% time.
The teams ranged in size from seven (including product and designers), to a pair of engineers. The work undertaken also ranged from the hugely ambitious 'moonshots' that could revolutionise the business, to simpler infrastructure improvements and dashboards relying on the developers' day-to-day skills and experience.
A handful of people chose not to take part, instead taking the decision to continue with their sprint work. Additionally we had a couple of production issues during the event, but fortunately these only took one or two people from the hackathon for a couple of hours.
Providing the meals was a headache and not something I'd want to do too often! Pizza on the first day was nice and easy, although they arrived late and one looked like it had been dropped. On the second day we chose a restaurant on Deliveroo, I collected everyone's order and then couldn't order online... So I placed the order over the phone and asked one of the team to collect it with the department credit card - but forgot to give them the PIN (and the restaurant forgot to give us the rice, for which I was blamed!). Finally, I managed to order online on day three, but even then it took ages to deliver and what arrived was wrong. This was undoubtedly the most stressful element of the event and clearly not one of my strengths.
I was also unexpectedly asked to "star" in a hackathon video, "acting" as a restaurateur. Watching it back was quite cringeworthy - my acting skills are not as strong as I'd thought.
The final presentation of all the hacks was a high-energy, enjoyable conclusion to the event. Our co-ordinator in SF did a good job lining up 40 back-to-back live presentations to multiple remote offices, but inevitably there were some audiovisual difficulties. One final disappointment in London was that the winners were not emailed to the global office, meaning many of us excitedly checked our emails upon waking but had to wait much later to find out if they'd won.
What did we learn?
From the feedback after the event, everyone felt the event was relevant and helpful for their jobs. Engineers commented that it gave them experience of what technology to use in certain situations - and what not to use. Another engineer was able to complete a proof of concept that she had been unable to make time for in the sprint.
A number of people have commented that the prizes were too great and the competitiveness skews the engineering value of the event. Whilst we didn't know the prizes in advance, if they are as substantial next year then I fear there is a risk of people prioritising high-risk, dramatic projects at the expense of experimenting with smaller ideas - ideas that won't win but can still provide value. Competitiveness could also tempt people to start projects early, form huge teams and focus more on slick presentations rather than engineering excellence. This is not necessarily to be avoided, but should be balanced.
It remains to be seen how the company will follow up on the ideas that were worked on in the Hackathon. It would be great to see the time and effort spent built upon to turn some of the ideas into product deliverables, and in London we will try to at least continue some of our technical projects in 20% time.
Another piece of useful feedback was a recommendation to set minimum and maximum team sizes. One of the teams of two in London struggled to balance their responsibilities, and most of the winning teams across the company all seemed to have 7-10 members. Limiting teams to three to six people seems like a good compromise to improve productivity but also level the playing field.
Finally another initiative we wish to try is to coordinate one 20% period per quarter for an unofficial hackathon just in the UK. If we can coordinate with other departments then there is a real appetite to undertake more frequent cross-team, project-based initiatives. As for the main event itself, I’ve yet to gather feedback from the San Francisco office, but from the London point of view it was a big success and something we hope can become an annual undertaking.