PAYETTE Hackathon: Hear from the Judges

Each of our judges brought a unique perspective and set of experiences to our first ever hackathon. These three judges came to the experience with an open mind about what the event would entail and how to interpret the outcomes presented by the participating teams.

In case you missed it, in our hackathon, we “hacked” a design problem dealing with a hypothetical lab building, asking teams to potentially upend program adjacencies, funding models or how collaboration zones work.

Each of our judges took some time to share a bit about their perspective on the experience:

Elizabeth Cox
When I received the brief for the hackathon I realized just how little I knew about lab planning. The relationship of PI to researchers and, in turn, their relationship to the building was foreign. Instead of focusing on what the brief actually meant, we (the judges) began by loosely establishing the elements of a winning proposal. We determined that the proposal needed to be compelling, coherent and succinct, while addressing some or all of the brief (or decisively throwing it out). Interestingly, as we started to discuss, we also started to brainstorm our own ideas for a solution without specifically intending to do so. The creative atmosphere in the room was contagious!

As the teams began to work, we had the opportunity to walk around the room and listen in to their conversations. It appeared that each of the teams had a basic understanding of the elements of the brief, and how they related to laboratory buildings; however the teams really pushed themselves as they considered different approaches. Some teams latched on to the notion of the “hacking” the building and others began by evaluating the relationships of the people or institutions introduced in the brief. I particularly appreciated listening in on the team conversations that began with “why” instead of “how.” Even if the team conclusion landed within a known paradigm, the baseline for their proposal became one of conviction.

Towards the end of the hackathon it was fascinating to see how the teams organized and presented their proposals. Many of the proposals were presented to us in such a way that assumed a basic laboratory understanding. As a judge who knew little about labs this made some of the proposals hard to comprehend, and therefore hard to evaluate. It was particularly thought-provoking to be one the evaluators and assume the role that our clients often play. How many times do we, as architects, get caught up in our own understanding and ideas, but forget to think about our audience. The communication of an idea is often half of the battle!

Daniel Gonzalez Brenes
During the event, my role as a judge gave me a privileged view of the process, allowing me to mingle with the teams as they developed their ideas. As the deadline for the teams’ 5-minute pitch was nearing, I started to get really stressed out about my ability to judge their work. Am I qualified to do this? I’ve never even been to a hackathon!  How does a hackathon judge do the actual judging? 

In the final minutes before the pitches, I came up with a scoring system, with a 1-5 score given on 5 different categories (presentation, feasibility, repeatability, thoroughness, disruption) for a maximum score of 25. This made me feel much better. As the teams began to present, however, I found that my scoring system was very limited. The 5-minute presentations were so packed, and so quick, that the various scoring categories seemed indistinguishable. My scoring system made sense, but it didn’t correlate strongly with how I felt at the end of each presentation.

I suppose a hackathon is a little less rational than I anticipated. Teams could satisfy the brief criteria, have a great idea and put together a well-rounded pitch, but that may not be the best path to winning. The winning team is more likely to be able to evoke the most positive emotional response. Perhaps adding a more metric component to the design problem would create a totally different dynamic, where a superior solution would be more easily apparent. In any case, I’m looking forward to experiencing the next hackathon from the other perspective. Being a judge is way too much pressure…

Alison Laas
My first observation as a judge during PAYETTE’s first hackathon was that I wanted to be a participant! It was nearly impossible as a designer to refrain from brainstorming my own ideas about how to solve the brief. As the judges discussed what we were looking for from a winning team, we couldn’t help proposing potential solutions. Later as I circulated among each of the groups working through their own solutions, I could not help starting to form judgements of others’ approaches and ideas as they compared to my own preferences and preconceptions about the brief.

Which leads to my second observation about the hackathon experience and format: the hackathon is a fantastic tool to help each us of set aside our preconceptions and listen to the ideas of other people. While I circulated between groups and just before listening to the final pitches, I consciously set aside my own ideas and biases about the brief in order to openly and objectively listen to the ideas presented. After all, the goal of the hackathon was to introduce something new and disruptive to a system that was at least, somewhat familiar to me as a designer and employee at PAYETTE. Because the aim of the hackathon was to discover something new, something with potential to disrupt the way that we think about challenges we routinely face in our project work, then it was my responsibility as a judge to set aside my own preconceptions about what the best solution would or would not include.

This conscious setting aside of my own preconceptions to actively seek out and listen to new ideas is where I see the greatest value of the hackathon format. In the routines of our work, even architecture, we can easily relax into comfortable patterns of thinking, taking things for granted, especially our own experience and biases. By consciously putting ourselves into an environment with a group of people with whom we do not routinely interact, with a specific purpose of finding new, innovative and disruptive ideas, we can consciously open ourselves to listen to voices of others who are coming from potentially very different points of view. Even if the resulting ideas are farfetched; even if the likelihood that we will be able to apply the ideas we shared with our colleagues on a real project are potentially slim; the act of putting ourselves in situation where openly listening to others and accepting the potential in every idea gives us the opportunity to exercise mental muscles essential to what we do as architects.

If everyone who participated in PAYETTE’s first hackathon can take the spirit of open collaboration, engaged listening and enthusiastic risk  to one other setting in our jobs – whether it be in a design discussion amongst team members, an interview with a client or a user meeting – then we will all reap the benefits of the experience.