The first COYO Hackathon
It all starts with an idea. And in our case, we just had to remember COYOs roots and where we are coming from as a company, to get inspired for the present.
Here at COYO we have a world of many freedoms. And for the software engineering department, one of the arguably biggest freedoms is the free coding day. On any bi-weekly Friday, it is completely left up to the imagination of the developer what to do with her or his time and what happens. Some decide to simply carry on with their daily work, others use it to further educate themselves on new technologies and then there is a group of people who use it to actively develop improvements for our product.
We’ve seen in the past that this is a great way to drive technological change and come up with absolutely unexpected yet marvellous additions to our product. But we have also witnessed its limitations. Ideally, you would want to be able to continuously progress on a topic not just every other week. That also poses a challenge to team up with a couple of developers. The product management or the design team do not run on the same schedule, so grabbing a share of their attention might be tough when you need it.
So as we really like the overall outcome of these free coding days, we asked ourselves what we could do to streamline the work that is being done there, how to put a better support system in place and make it transparent to the whole company what is being developed.
With some of our core values being agile, collaborative, uncomplicated, having a positive mindset and always thriving to be better, we turned to something that we did before and remembered from our earlier days. Going back a few years in our minds, we still felt this very hands-on, rapid-prototyping kind of atmosphere, which was also a bit hacky, that was a trademark of our company “youth”. And we then connected it with the experience of previous COYO summits, where we invited customers to our office to talk about the future of our product and roadmap, but also gave them the possibility to join in and brainstorm improvements that could then be put into practice by our developers in a one day Hackathon. And there it was. Our idea of agility meeting a well thought out product.
We came up with a timetable, some basic requirements and people and departments who would need to get involved for what we had in mind, but eventually it was just acting out that very idea.
The schedule was as follows:
until 29th of May: Call for Ideas
until 29th of May: Registration of developers
2nd of June: Jury evaluation of ideas
3rd — 5th of June: Hackathon
8th of June: Company-wide presentation and vote
It was important to us that the event as well as the process were as transparent and open as possible, so we started by collecting ideas from anyone. No matter your job or department in COYO, all ideas were warmly welcomed. And there were plenty. In the end, we counted 44 transmittals, detailing the feature request and the use cases for it. WOAH! And 18 developers wanted to participate in the Hackathon, which was huge as well.
A jury representing the software engineering team, product management, product design and key account management, then proceeded to evaluate the sent-in proposals. Instead of valuing and pre-judging them for the team, we committed to keep the selection as broad as possible by just eliminating those that were no suitable candidates for the Hackathon because of either missing product fit, they were already on our road map or being too small or too big of a topic to be worked on for three days. So we started into the Hackathon with 20 ideas being left. And of course it was all remote work, so we did video calls to organise it. Easy.
In the kick-off call (9:30 am, which explains all the faces 😀), every author had to do a 1 minute pitch for her or his idea. If the idea was to be chosen by one or more developers, the person — again, no matter the actual job or department — would then have to companion the team as their respective product owner during those three days. After all pitches, the developers made their choices and handed in their first and second picks, so we could form a total of six teams.
These came out as the chosen few:
Low Quality Image Placeholders
Content discovery
Read confirmation for blog posts
Audio messages
Mark timeline posts for later
Broadcast feature
And to keep up the tension, we will close with this giant cliffhanger.
If you ask yourself what stands behind the somewhat cryptic names and what our team was able to accomplish in those three following days, watch out for the next instalment of our blog series as it will detail the journey of some of the features and their actual outcome. See you after the break. 😉
