How We Organized The First Internal CIAN Hackathon

Large companies often face the same problems. The most common is communication. If departments are pretty isolated and try to talk to each other through the heads, leads and managers rather than directly, some team building event is here to come up, like internal hackathon for the programmers.

CIAN has never had a hackathon before. We planned it as an event for teams, where each team has its name and leader. There are several points to notice here.

  • We gave the teams freedom to find the members.
  • But we moderated this process slightly: teams were tend to find its members among their own departments. In that case we provided some help – broke that ice between departments and found a designer, or web developer, or data analyst that the team needed.
  • We kept in touch with this process and didn’t leave weak teams alone. We were like a bridge to different parts of the organization and continuously helped teams to make friendship. As the final result we got more happy teams and more social connections.

First of all, for the teams hackathon is a great opportunity:

  • to come and make something new and interesting,
  • to get that project done for which there was no time,
  • to get feedback from the participants.

The objectives of our hackathon were:

  • to improve horizontal communications in the company,
  • to find and inject new development tools and methods,
  • to get experience in organizing team building activities.

The goals were:

  • to get 4-5 teams,
  • to get working MVP of the projects,
  • to filter the best projects and find out what to do with them.

Before we started, we were to make a decision on some key aspects. We didn’t want the first hackathon to last long. We planned 8 hours for coding, lunch and preparations and an hour to present the results. Again, we gave full freedom here: we had no one presentation template. Later, one of the winning team simply used plain paper lists to present what they did.

The working place had to be organized. It seemed ugly for us to work at where we usually work. We brought tables, chairs, laptops, electrical outlets and some music at one of our open spaces. It helped to provide good creative atmosphere to the participants.

Infrastructure and deployment had to be defined too. It was very useful to invite system administrators: some teams had project-specific environment problems. There were lots of what to think about like awards and nominations, common chat and photographer, jury and warmup meeting (an involving meeting before the hackathon were we told about how it’s going to be and fed people). And pizza, of course.

The folowwing roadmap was accepted.

  • Hold the warmup meeting – tell people why they should join the hackathon and feed them.
  • Collect project ideas.
  • Build the teams.
  • Hold the hackathon.

The day of the hackathon was scheduled like this.

  • Welcome reception and registration.
  • The beginning of the hackathon.
  • Lunch.
  • Teams’ presentation.
  • Jury work.
  • Winner’s reward ceremony.
  • End of the hackathon.

We listed scoring criteria for jury. We gave 5 points to the project that perfectly matches the criteria, and 1 point if it didn’t match at all. We used 5 different criteria.

  • Project readiness – MVP works and carries its declared functions.
  • Project survival – The higher the probability of a project to survive in real life, the higher the score.
  • Project idea – The more original the idea is, the higher the score.
  • Project quality – The more completed, technological, logical and attractive the project is, the higher the score.
  • Project presentation – The better the team’s performance is, the higher the score.

What we got.

  • 7 teams.
  • About 35 people.
  • 3 winning teams.
  • They rated us as high as 4.6 out of 5.

What we provided.

  • The ability to communicate informally.
  • A chance to try new technologies and development tools.
  • An opportunity to be a part of a big family for remote teammates.

What we did wrong.

  • Didn’t match the schedule, lacked a lot of time.
  • Couldn’t resolve infrastructure problems quickly.
  • Didn’t help the teams breathe life into the projects after the hackathon is ended.

That’s it. There are two recommendations to get your own hackathon done in your company.

  1. There should be one person responsible for the hackathon.
  2. If there is a group of people responsible for the hackathon, there should be one person responsible for the group.

Hackathon is a great team building event. Your HR will surely like it. Hold your hackathon, unite people and start gathering new ideas.