Why hackathons are great for your teams and your products
One day an invite labeled “Let’s make Search better” appeared in my inbox from our VP of Product. This meeting spanned two days and the invitation went out to two front-end teams and one back-end team that work on JSTOR, a website that is the digital equivalent of a core academic library used regularly by millions of researchers and students. There were two guests on the list as well—colleagues from the University of Washington (UW) who have been researching our search logs/algorithms and had insights to share about making it better.
Make something better? Of course! I was in and intrigued.
An agenda soon followed:
Day 1:
- Debrief from UW folks on their work
- Share what users are telling us about their search experience based on the issues our User Services team hears about and the user testing we conduct
- Brainstorm to identify proof-of-concept (POC) ideas based on the morning session
- Write down our idea(s) on a sticky note and pitch them to the group
- Vote on the top 3–4 ideas
- Self-organize into teams—ideally each team should have members from multiple teams and have a mix of front-end engineer, back-end engineer, QA, and UX/design
Day 2:
- Begin “developing” our POC
- Demonstrate our POC to the group
If you were to ask me now, I’d say I felt stupid for not realizing this would be a “hackathon.” The invite didn’t use the word, but how didn’t I catch that? I have no idea. To be fair, neither did my colleagues.
The day arrived, and coffee in hand, our group of 18 people was off and running. We learned about and processed user feedback and research about search functionality on our website.
Then we did the brainstorming exercise to come up with the best possible ideas to improve the current search experience. Everyone had a variety of innovative ideas and an open forum to think out-of-the-box. In my opinion, out-of-the-box should be an everyday problem-solving ethos, tempered with a dose of practical reality of course. Once all the ideas were up there, we had 15 minutes to walk up to the board and vote on 3 ideas each. The key here was to choose the idea that we would like to work on, with a focus on (here’s the reality part):
- high user value
- maximum utilization of the collaboration between the front-end and back-end teams
- speed (in other words, POC can be wrapped up in a day)
After the voting session, the votes were counted and the top 3 ideas were picked up. Then, we self-organized into groups of 3–4 people to work on each idea. It was a good mix of front-end developers, back-end developers, QA, product owners and UX. The exciting part was that not all the members in the group had worked together before. I know it might sound terrifying, but trust me, it was one of the most exciting parts of the experience. We broke out into our respective smaller groups and had another brainstorming exercise at a more granular level.
We discussed what we needed to create the POC:
- service components
- user-facing components
- design mock-ups
- happy-path and unhappy-path scenarios
Ideally, service components would be done by back-end engineers; user-facing components by front-end engineers; design mock-ups by UX; and happy-path and unhappy-path scenarios (and risk mitigation) by test engineers. So, which role did each person in the group play? None and all. We all played all the roles that we could from start to end, based on everything that each of us could bring to the table. We acted as a balanced team: when you look at a group of people working successfully together and you can’t tell which role each one is playing.
After listing out what we needed, we decided to break for the day. We regrouped the next morning with more thoughts about implementation details after sleeping on the first day’s ideas. Pssst…sleeping over ideas actually works, because when you’re going to work on something that really motivates you, you’re going to run through it in your mind unintentionally. That leads to many more ideas to make it better.
We were all geared up to give a face to our ideas by demo time. Back-end developers trying to help with front-end, building service components based on how the front-end would function; front-end developers thinking about back-end services needed; everyone wearing the design hat; everyone wearing the QA hat. The iterations were instant; the learnings were instant; the discussions took place right then and there; and the implementation followed just as smoothly. The demos went extremely well with each group explaining what the idea was, how it would improve specific aspects of the search experience, and how it was implemented. Each POC left us feeling strengthened and excited by just how much talent we have and how much we can get done in eight hours!
This experience produced a lot of valuable lessons and practical outcomes for us. Here are my top three for each. They are also the reasons why I think hackathons are great for teams and products!
Lessons:
- Taking a collective approach to a product as a team fosters innovation!
- Balanced teams encourage each team member to think holistically
- Organic processes can open the floodgates to previously untapped creativity and motivation
Outcomes:
- 3 innovative features, of which one got slated for release only weeks later
- Inter-team collaboration/connections which will benefit us for a long time
- Showcase of the vast talent our organization has!
After all the demos were done, I sensed the energy in the room and thought: We need to do this again, including all our front-end and back-end teams. As of this writing, we’ve already had our first all-team hackathon event!
