Hacking Hack Week
Document Cloud ‘Hack Week’ — A Few Things We Have Learned
In busy work places, day-to-day tasks and routine workflow eat up most of your time and inhibit creativity. As a result, innovation tends to get short shrift. At the same time, customers expect more and better experiences, and smart companies know they need to bring fresh ideas and creative input to the table.
Enter Hack Week
Companies from Netflix to Ebay use hackathons to motivate and inspire their employees, encouraging them to think out of the box. Hacking is a great way to promote creativity and drive new ideas.
It’s clear why we hack, and the results often speak for themselves. But no process is perfect, and of course, there’s always room for improvement.
Like a lot of technical organizations, Adobe Document Cloud sponsors a company-wide hackathon once or twice a year. With a full week dedicated to the event, “Hack Week” is a huge morale booster and innovation driver. Employees enjoy complete freedom to hack anything they want with whoever they want, with hacking unapologetically spread over 3 or 4 days during daytime hours (although you are free to keep going).
Hack Week at Adobe is about encouraging people to blow it open and try different things. So naturally, this same enthusiasm extends to how we run the event itself. Here are some of the ways we’ve hacked Hack Week, what we learned along the way and how we’re getting better results.
The DNA of a Great Hack Week
If you are considering organizing a hack for your company, the following is highly recommended:
- Get support from leadership. This is essential.
- No meetings. That’s right, no meetings.
- Maximize freedom. Hack on what your team thinks is best, with whoever you choose. Stay away from ‘hacks’ assigned by managers that look suspiciously like work.
- Share the demos publicly.
- Pay attention. Ensure a thorough review of the hacks for new directions, features, patentable ideas and stuff that’s ship-ready.
Hack Week Challenges
Hack Week is all about going fast and having fun, and yes, breaking things. But obstacles can get in the way. Here’s how we faced a few of our biggest challenges, along with some solutions we’re still trying to figure out.
Different geos & timezones. With 500+ developers, designers, product managers and QE spread over three geos (California, Boston and India) along with a number of folks working from remote locations, our first challenge involved coordinating across different geos and time zones. One remedy is to create a travel budget, setting aside money for people to gather together. The tools we use every day also help here: slack, git, and video in particular make seamless communication doable.
Hacking across functional groups. Originally, Hack Week was a chance for the Engineering organization to challenge themselves. But we quickly learned that having a more diverse group of hackers led to more diverse hacks. Now, we’re encouraging participation from Product Management, Design, Operations and even Marketing.
Feedback and recognition. With a large, geographically diverse team, it’s an ongoing challenge to ensure that hard working hack teams receive attention, feedback, and recognition from their peers and senior management. We try to tackle this problem by having a core group of judges who are also curators of the content, sharing it out and publicizing relevant work to other groups.
Hack Week — Version 1.0, 1.1, 2.0 & 3.0
Our first few Hack Weeks followed a pretty straightforward format. They lasted for three days, and involved mostly developers; hackers were given full freedom to do what they wanted with no prompts and all the hacks were reviewed at the end of the event. As we hacked, we experimented, learned and hacked the rough spots. Here’s how we approached hack week and what it looked like.
Version 1.0: Live Demos
The big feature of our first few Hack Weeks was demo day. On Thursday of Hack Week, we all gathered together to watch the demos. Each team had seven minutes to impress. But with upwards of 70 hacks to watch, we were swamped. 70 hacks x 7 minutes each = 8 hours of demos.
Spread across 3 geos, and 11 time zones, most people didn’t see all the demos (although our hardy Vice President of Engineering managed it). We also discovered that many live demos didn’t work perfectly or weren’t quite ready, causing them to go much longer than 7 minutes. One presenter talked for 17 minutes, and no one stopped him! On the other hand, the occasion was festive and quite a bit of fun.
Version 1.1: Canned Videos
In efforts to cut down on demo time, we tried putting them on video. Hack Week organizers negotiated on this point. But in the end, we settled on 4 minutes, agreeing that asking hackers to spend valuable hacking time editing video was not core to our Hack Week mission. Recording videos in advance was great, and we still have the recordings, even now. The more interesting hacks live on as we revisit them, while also becoming part of an individual’s portfolio of accomplishments.
Overall, canned videos worked well, and the demos were easier to schedule. But again, gathering together to watch a bunch of videos wasn’t much fun. In fact, it was boring. In the end, we captured great demos and plenty of innovation, but had less fun.
Version 2.0: Science Fair
This time we set demos up as science fairs: everyone from one office attended those demos and only those demos. This allowed us to ask questions, and spend as little or as much time on each before moving on. Oh, and we were also able to socialize and drink beer — never a bad thing. We still created videos, to share with other geos, executives and for posterity’s sake.
Unfortunately, the science fair model was no fun for our remote people — people in Boston had no idea what had been done in Delhi or San Jose, and vice versa. But for the people in each office, it was high energy, and much more engaging.
Version 3.0: Combined Science Fair, Big Gathering
Last year, we tried having an ‘open space’ pitch day where people with ideas pitched them to their local group, we then voted on the most interesting ideas and workshopped them for a few hours. The results of the work shop then became hacks that we tackled a few weeks later.
We also had local science fairs running in parallel with a demo theater. The demo stream is something everyone can watch, while still getting the local jazz. We think we struck a healthy balance between fun, learning about other geos and interacting directly with participants.
Version 4.0: planned for August 2018
We are already designing the next incarnation. We don’t know what it will be, but we know it will different!
Always Be Hacking!
While we’re on course to creating a truly great Hack Week, we still anticipate having to work through challenges along the way. For example, it can be tricky to get non-developers interested in hacking or feeling comfortable in an open-ended environment. Adobe’s designers have their own hackathon, and it’s not integrated with ours. It’s also tough getting Product Management to participate. The feeling is that Hack Week is a ‘code-a-thon’. While this is somewhat true, we don’t like excluding people and continue to find ways for all to participate.
Despite these challenges, we’re constantly looking for hacks that will spur imagination and drive fresh ideas. We’ve prompted Product and Engineering leadership for things they’re interested in, encouraged shy hackers to share by creating an ‘Open Space’ pitch day. We’ve even tasked a judging panel with finding the most amazing hacks, and making sure they’re recognized and highlighted. The one constant that never changes is the value of a great hack.
How are you hacking the hack? Bravo to spotify, a company we greatly admire who hacked their own Hack Week by changing the goals and format, even doing away with demos! Rock on you crazy Swedes!
If you’d like more information about how to set up your own hack week, or want to share what you have already done we would love to hear from you!
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
A version of this article was previously published in Information Week.