How hackathons became a part of UXPin’s engineering culture
I remember the very first hackathon we organised back in 2014. We were just a team of 10 and we thought it might be an interesting experience to spend a weekend on hacking UXPin and see what innovations we can do in such a short time. We didn’t establish any rules, so engineers and designers had complete freedom to decide what they were going to work on. They chose very ambitious projects such as standalone image editor or video conference feature (over WebRTC) to enrich presentation mode in UXPin. After 24 hours, we had a few great proofs-of-concept. It showed us once again how enormous potential the team has.
Since then, we used to spend one Saturday a year working on any kind of feature, hack or improvement. We let people do anything they wanted and the results were more than awesome.
Organization
The most important rule about hackathons is that there are no rules at all. Previously, people organised themselves into teams and we didn’t force any structure there. Usually the team consisted of 1–3 Engineers and a Product Designer. Since hackathons used to be organised on Saturdays, we didnt even expect people to work on projects strictly related to UXPin. Although they usually chose to work on the product anyway.
We consulted the date with the Team, so it suited most people. We met at the office very early and coded together until late evening hours. There were beer and pizza of course, but what is most important — a lot of creativity, deep focus and productivity. It always surprises me what can be done when freedom, talent and creativity meet together in the right conditions.
Evolution
Three years later, in December 2017 we decided to introduce breaking change: instead of having hackathon once a year during the weekend, we’re going to organize it every three months during two working days (Thursday and Friday)!
Why have we changed that? Because we’ve noticed that hackathons are valuable not only for our product but also for our engineering culture. We want to give this event a proper place in the timeline to show people that it matters to us and that we care. Moreover, it’s just a fair way to do that.
Results
The last hackathon that took place on February 1–2 resulted in 22 projects: from small yet necessary improvements to proof-of-concept of the advanced features. As almost everyone had some ideas worth exploring, most of the people chose to work in solo-teams. As a consequence, we were able to run much more experiments than we would with fewer teams.
Some of the projects were related strictly to developer’s workflow, e.g. an implementation of CSS linting tool or deployment bot for Slack. Others were dedicated to speeding up UXPin or making it more secure. Of course, there was also a bunch of product features as well, like copying & pasting styles between elements or entirely new, outstanding tool that allows users to draw anything they want in UXPin.
Future
UXPin is evolving all the time because we’re constantly looking for the opportunity to improve. Currently, we’re thinking about two new formulas for the future editions of hackathons:
- Having less but more numerous teams
We’re going to encourage people to pitch their projects a week or two before the hackathon. This way, there is a big chance that the teammates will consider joining some other team rather than working alone on something else. - Having a theme week to focus on one specific area
We have been thinking about replacing some hackathons with a full working week dedicated to one particular area, like better user experience, bug fixing or refactoring. Great examples from other companies prove that it might be truly rewarding for us and our customers.
Summary
I hope that this post explains why initiatives such as hackathons are essential not only for our engineering culture but also for UXPin as a whole. It is all about building trust, engaging team members in product development regardless their roles, unleashing creativity and just having fun. I am sure a lot of things would not have happened without this kind of events. Sometimes it is just better to let people decide what is best for your product.
Try it. You won’t be disappointed.
