Running a Worldwide Hackathon on Slack

Last Fall, our team at Progress helped a partner run a hackathon for their R&D organization. The hackathon (perhaps best described as a boot camp) leveraged Slack and I believe the general ideas can be applied to similar situations. In this post, I'll explain what we did so that you can hopefully apply the processes to run a hackathon of your own.

The Challenge

Our partner has a worldwide R&D group with developers in 15 countries spread in time zones ranging from the west coast of the US to the east coast of Australia. The management of the group chose to create a "HackWeek" where developers organized into small groups and worked on a project of their choice during 3 days of that week - the scheduling flexibility reduced the impact on other deliverables within the organization but the overall arrangement meant we had significant support requirements.

Our team provided mentoring supporting during the whole event - we did this with a very small core team and a team of part-time mentors in different groups and locations at Progress, all coordinated through Slack.

What is Slack

Many developers already use Slack but if you haven't yet heard of it, Slack is a real-time multi-screen team communication SAAS solution. It supports public and private channels, direct messaging, file uploads, search, notifications, and has integrations with many tools. Slack has both free and for-fee offerings.

Leveraging Slack

Progress has had very good experience with Slack and several teams use it regularly. When our partner approached us with the Hackathon proposal we designed a way to leverage Slack to provide online support to the event.

Going online removed face-to-face interaction but it meant that the members of the support team didn't have to travel, could play "tag team" to support the participants, and could easily cover participants in several time zones "close" to their own time zone. Realistically, online support was the only way for us to support this event and, in the end, it worked very well.

We took advantage of Slack's channels and we created several public and private channels that were used by the participants and the mentors. We reached out to multiple teams inside our company and we got a very good response across geographies and different functions. We used the free Slack offering, which worked well enough for our needs. Most mentors had experience with Slack, but most participants had not - still they ramped up fairly well.

The channels we used were:

• #general - General messages
• #random - Shooting the breeze
• #announcements - For organizers to reach attendees
• #team-NAME – One per team
• #ineedhelp – to coordinate "support tickets"
• #mentors - a private channel for communication among the mentors

Every participant and every mentor was required to be in the#general, #random and #announcements channels. The intention was to keep #announcements strictly for communication from the mentors/coordinators to all the participants, to use #general for general public conversation among participants and mentors, and to use #random for side conversations, jokes and such - the way it is commonly used in Slack. In retrospect, this structure was too complicated for the needs of the event and next time I'd just use the #general channel and not use neither #random nor #announcements.

Each team was asked to create their own public channel. This channel was used for conversations within the team and also for conversations between the team and the mentors. This worked very well.

We created a channel specifically for the process of requesting and coordinating help. If a team needed help, they would post on #ineedhelp. A mentor would then start a conversation with the participants but anything longer than a few exchanges was moved to the channel specific to the team. Moving the conversations to the team channel reduced the "overload" on the #ineedhelp channel but also helped keep all the support context in a single, continuous conversation. Multiple mentors could then cooperate in supporting that team, sometimes simultaneously but also sequentially, as the availability of the mentors varied with the time of day or other constraints.

The #ineedhelp channel essentially provided a work ticket/support machinery. The participant team "opens" a ticket via a short post on the channel, and the mentor "claims" the ticket by replying to that post, and then moving to the private channel. It was a very simple arrangement that worked well for us.

Sometimes conversations between a participant and a mentor would move into direct messages. We discouraged DMs as they are not archived and cannot be searched. Another disadvantage of DMs is that any context there cannot be transferred from one mentor to another.

The #mentors channel was used for private conversations among the mentors. It was sometimes used to coordinate which mentor would take what ticket, sometimes to discuss solutions to problems, and sometimes just to indicate people going offline or arriving as the work days moved across the world.

Experience

Above is a graph showing conversations on our Slack team during the week that we ran the hackathon. We had almost 170 participants from our partner organized into more than 25 teams, and Slack recorded over 7.5K messages in HackWeek.

I live in California, so, from my perspective, that week started very early, as Australia, China and then India started their work week, and the demand on the mentor team continued high until late Friday on the US West Coast. The Progress mentors lived in Australia, Bulgaria, Germany, India, Spain and the USA, and represented multiple organizations including Developer Relations, R&D, Support, DevOps and the Office of the CTO.

The experience of the hackathon was very good and the partner was very happy with the results. The load on our side was manageable: a couple of mentors worked almost full-time on the project but most mentors were only involved part-time. The multi-screen facilities of Slack meant that sometimes the same mentor would start a conversation on one device (laptop) and continue on another (mobile or tablet) which helped stretch the time zones they could cover.

Another benefit of this project was that we increased cooperation across the different Progress teams that provided mentors - nothing builds a team like working together on a task.

A Mixed Online/Physical Hackathon?

In a traditional hackathon, the participants and the mentors are all physically in the same space, and this creates positive social dynamics - it is not uncommon for teams in hackathons to be comprised of members that had never worked together. This hackathon wasn't all that different other than from a coordination standpoint.

This hackathon was only online on the mentor side. The participant teams either all were co-located, all working in a given site and able to sit around a table and work on the project together, or they were part of a team at work and already knew how to work together. I believe that this physical/online combination could work well in other cases for running hackathons.