This article is about how I hosted my first hackathon for the team. Experienced organizers might find the material too simple, and the story naive. I aimed at those who are new to the format and consider whether to hold such an event.
handles complex things with data: we clean and enrich client contacts for large companies and build customer databases with hundreds of millions of records. Our Moscow offices employ 65 people, with around ten more working remotely from other cities.
Any job can sometimes become a bit dull. In such moments, it's useful to change focus and try something new. That's why for about six months we were considering hackathons.
A hackathon is a competition for IT specialists: several teams gather and spend two days solving complex problems, usually competing for a prize awarded by a jury.
We wanted to try out the format and have some fun, but a classic hackathon can be a quite large, troublesome, and expensive undertaking. So, we conducted a light version with almost no budget. In the end, we were satisfied and even created something useful.
Why a hackathon is beneficial for a company
Classic hackathons are usually organized not out of generous spirit. Organizers either solve practical issues or promote themselves. The format of the hackathon is chosen based on the objective.
- Solve a practical problem. The organizer sets goals, and participants choose a suitable one to solve. An example of such a task is to create a new client scoring algorithm for a bank.
- Promote their tools. The organizer provides participants with their own software, programming language, or API. The aim is to create something useful with the given tools. For instance, a hypothetical Google opens access to its voice translator and looks forward to interesting applications.
An additional goal of a large hackathon is to present the organizer as a desirable employer, both internally and externally. Guests from other companies will become impressed by the office, organization, and the breadth of opportunities. Their own employees will gain new challenges, freedom, and communication.
For example, "VKontakte" hosted a massive hackathon. It's hard to classify it into one type: there are just too many directions.
As for us. The main goal of the entire initiative for HFLabs is internal HR. We saw the hackathon as yet another collaborative activity outside of work. To unite, to invigorate, to entertain â thatâs the aim. Some play football in teams, others participate in quizzes. The hackathon is another format for meetings outside of daily tasks, which certainly doesnât replace either quizzes or football.
However, the hackathon, even in a light format, is not just pure entertainment. For example, one team ultimately created a text quest, learning the mechanics of bots in Telegram from scratch. This is wonderful: when a person tries something new and attempts to understand it, fresh ideas emerge. This is beneficial for everyday work as well.
Moreover, we ended up with useful tools, even though we didnât set any practical tasks at all. But more on that later.
The purpose of the hackathon for participants
Participants come to a classic hackathon to get acquainted with technologies, try out new experiences, or earn money. It seems that more people are joining the last category.
- Try out new technologies or methods. During the week, each developer sticks to their own stack of technologies, sometimes for years. But at the hackathon, one can try something new â whether itâs something just appeared or simply interesting.
- Experience the product journey in miniature. IT professionals are interested in creating a full-fledged product in just a few days, going through the entire cycle from concept to presentation.
- Earn money. Sometimes strong specialists assemble into teams of professional hackers â experienced and trained. They choose events with rich prize pools and dominate due to their experience and preparation. Some organizers immediately filter out such savvy contestants. Others welcome them.
As for us. To begin with, we asked the team â is a hackathon needed at all? We donât conduct anything forcibly, so we wanted to measure interest in advance. For the surveys, we used Google Forms.
In the team of 65 people, 20 completed the survey. Since 75% of them are interested â we need to make it happen!
The second task is to motivate the undecided, who make up more than half. The next survey showed that prizes wonât help in this case.
It turned out that our team is interested in creating new products. Even if itâs just a small application, they want to go from idea to working prototype.
We started gathering hackathon themes that would interest everyone. Once again, relying on the team: we opened a chat in Telegram, where ideas were tossed around freely. No holds barred: whatever comes to mind is fair game.
We collected 25 themes and launched a poll in Confluence. The five most popular projects â as shown in the picture â were selected for the hackathon.
How long does all this last?
A classic hackathon lasts two days and the night in between. The night is a nod to the old IT school, a pragmatic and romantic touch at the same time.
What to do during the dark hours is up to each team or participant to decide. At night, you can sleep; the organizers won't say a word. Or you can take action: program, design, plan, test.
As for us. We didn't even mention the night vigil. Moreover, we further condensed the format and decided to hold it for just one day. Otherwise, we would have to either spend two workdays on the experiment or drag colleagues away from their full summer weekends. Few would agree to the second option: summer weekends are precious.
There were wishes expressed that it would be nice to gather on weekdays. However, we didn't want to organize all of this during work hours. No matter how hard you try, it's hard to detach from work during the week: clients are writing, colleagues are asking questions, something's boiling in the office, and meetings are being scheduled. Everyone will revert to their usual matters. Therefore, our next survey was to see if people are willing to hackathon on weekends.
Not everyone is ready to unconditionally sacrifice a weekend. However, there are more than half who are uncertain, and we need to tempt them.
A bit later, in June, we asked participants about the dates. We set aside slots all the way until autumn â during the summer, colleagues are on vacation and at their dachas, and we didn't want to miss the event. So, we decided to suggest all Saturdays. You can choose several â pick the ones you are free on.
Not everyone is ready to unconditionally sacrifice a weekend. However, there are more than half who are uncertain, and we need to tempt them.
As a result, we planned the hackathon for August 17. The alternative of July 27 coincided with my business trip, so that option was ruled out.
Where will the event take place?
Usually, most participants gather in a shared space. Communication is an important part of the hackathon, so the organizer allocates an open space or an entire building.
Once, I participated in a Google hackathon. The organizers allocated a two-story building, with bean bags, tables, and other furniture inside. Teams scattered across the area to set up their working spaces.
But there are usually no strict limitations: if someone warns in advance and connects remotely, there will be no obstacles.
As for us. Since the hackathon was intimate, with seven participants, the empty Saturday office was more than enough. This was even without considering that one participant connected from Volgograd.
We planned to have everyone gather in a conference room.
What about the winners?
Classic hackathons have a jury that announces the best project. The jury usually includes someone from the organizers or sponsorsâthe ones who fund the entire event.
Project demos are an important part of the hackathon. Teams present a short presentation and then demonstrate their solution to the jury. Itâs like defending a thesis at university.
Sometimes, the work is evaluated by a computer: the project that scores the most points in the test wins. I find this approach too formal; by assessing solutions with 'parrots,' the organizers kill the product-oriented aspect of the hackathon. It resembles a competitive programming contest rather than a creative endeavor.
As for us. We took a radical approach: we simply canceled the jury and competition altogether. Because we didnât aim to create the best solution to a problem or produce a finished product.
Since the goal is to enjoy the process, participants can freely work on their projects without regard for other teams.
The Big Day at HFLabs
The hackathon kicked off on Friday evening, a day before. Participants gathered, and each chose a theme. Ready-made teams were formed.
The gathering and unexpected participants. Participants arrived around 11â12 on Saturdayâto avoid waking up early like on weekdays. There were six attendees remaining, and another connected from Volgograd.
The announcement of the date didnât go unnoticedâthe participants began to leave the hackathon chat actively. But there was no disaster, and the quorum was maintained.
Throughout the day, new participants suddenly appeared. Colleagues who weren't planning to attend the hackathon carved out three to four hours. They came, chose a project, and helped out. This is atypical for a classic format, but we enjoyed it.
Teams and projects. It turned out that three people were working on their projects alone. This is the main drawback of the event; working in a team is much more interesting. Finding interaction is actually an important aspect of the hackathon concept.
A text quest on the Telegram engine. It has no practical use, but inside thereâs industry humor and local memes.
A couple of hours after the start, one project was left without developers: the author left the project and joined another team. This is normal even for a classic format: good ideas attract people. At first, it seems that you will complete your project to the end. But then you dive in and see that you won't make it, and there's no point in trying. Or you join the neighbors because they are making progress and have a useful product.
Seryoga, a frontend developer from Volgograd, got a little bored, so he came up with a project "from scratch". And immediately got to work on it.
In the corner of one of our products lives a little cat. Previously, the cat just slept and created comfort, but Seryoga taught the furry friend to react to events.
By the end of the day, the number of projects remained the sameâfive. One was dropped, another was added.
Space and schedule. For the hackathon, the largest room in the officeâa conference roomâwas planned. But when it came down to it, everyone conveniently scattered to their own offices. That's how they started.
At first, it seemed that the shared space wasnât crucial. Since the projects werenât connected and there was no competition, it was fine to sit separately. Discussions were held in the hallâthe main thing was not to scatter further than walking distance.
But after a few hours, the fragmentation ceased by itself. Those who were creating in solitude, influenced by an unseen force, one after another moved to the busiest office. It became more interestingâconversations livelier, questions more complex and frequent.
They took breaks every couple of hoursâshared impressions and observed others' projects. They had lunch in the middle of the day.
During lunch, a supporter, who had subtly hovered nearby all this time, burst into the hackathon's fabric: cheesecakes were unexpectedly delivered to the office.
Time was not restricted: whoever wants to stay, stays. They usually left, bringing their project to a more or less finished state. The last participant left around 10 PM.
We decided not to hold a demo right away; instead, we'll talk about the hackathon on Tuesday for the whole office.
Results and life after
The hackathon light yielded even more benefits than I expected.
HR. We had a great time: we wrapped up the hackathon and discussed smart topics without the usual work hustle. All this for a budget equal to the cost of transport to the office and lunch. Plus, we cultivated evangelists for internal hackathons in the office.
Projects. Throughout the day, we didnât complete any of the five projects. But thatâs okay: usually, the goal of the event is to fundamentally solve a problem and find an idea. A good result is a minimally working tool, even if it has some rough edges and bugs.
Anton Zhiyyanov, head of our product , was creating an email newsletter. It looks like a browser-based editor that accepts a CSV file with recipients. It's much more convenient than the overloaded Mailchimp.
However, after the hackathon, the projects are either being realized or are preparing to be. We are already sending emails with the newsletter tool, and the cute cat is charming the clients. The other applications are being finished by their authors, and already based on requests from outside. For now, we're giving them away for free to acquaintances, but someday it might reach commercial use.
Cons. The main downside is that we gathered too few people. As a result, three out of five projects were handled by one person, which isn't that interesting. When you hack alone, you lose the effect of a product team. There's no one to establish interaction with.
I also realized that a stricter regulation would be beneficial. We need more organization:
- clear timing;
- merch for participants;
- jury and demo on the same day, while everyone is still charged up;
- preparationâannouncements, project descriptions.
We could also invite someone from outside, but it's not absolutely necessary. And invitations would likely be targeted. No large-scale advertising.
The future. Half of the office gathered for the general demo on Tuesday. It was then that I noticed interest in the projects and the format. Not everyone wanted to get involved in the experiment, but after the first try, the number of those willing increased. I think in 2020 we will make a bigger event.
That's all about the hackathon. If you're interested in working on complex data tasks, come join us. : weâre looking for Java developers, support and testing engineers, and systems analysts.
The article was first . The version for "Habr" has been revised and expanded.
Source: habr.com
