Our internal hackathons

At Whitesmith we believe in hackathons as a way to level up our craftsmanship in a few areas, but also because they are great to practice our ability to build products. Hackathons require the same practices and discipline of thinking on an idea with a purpose, make sensible choices regarding time and scope and then do our very best to deliver the initial vision.

Our retreats are the perfect opportunity to get our team together and spend some time hacking new ideas and projects. In the past, we developed some cool projects like Remotes.in, Hawkpost, and Soundy.

OUR LAST HACKATHON

During our last retreat, we also had an hackathon. To be fair, though, we were not that happy with the result. The output were seven projects, which weren’t launched, had an arguable purpose or were not even close to being completed by the end of the hackathon. This doesn’t mean that ideas should be boring products, or that people shouldn’t optimize to learn concerned that doing X on a new technology is a risk we should avoid. The main point is that each idea should have a purpose, and learning is a valid purpose.

If we are not able to pick and conquer a challenge that solves a problem or serves a purpose in 36h, how do we expect to do it with a much more complex product and environment?

For this hackathon, we had a few rules and framework for the projects from the get go, but I should have been more thorough in ensuring they were followed through. Instead, I was dispersed between some emergent work needs and helping on one of the hackathon projects. Since it’s the only thing I can control for sure, although with some sadness, next time I’ll avoid taking an active part on any project to ensure the hackathon goes smoothly. Even if people hate me during the process, I believe this way we can all be happy and proud of what we launched at the end.

It should be mentioned that the hackathon was at the end of a packed week, which naturally had an impact. But since hackathons are a good indicator of our ability to build products, it’s still worth reviewing what went wrong and how can we do better next time.

There were some general opinions that there weren’t many or great ideas and/or people decided on them too late. However, that’s not something we should accept without argument. If there are no good ideas, it’s probably best to start by focusing our time on finding a good one, than carrying on with a bad idea. Frequently the best hackathon projects (or products for that matter) are actually easy to implement after there is a clear and compelling vision. So next time if there are no good ideas, we should focus in the first part of the hackathon finding more and better ideas, even if that reduces the hackathon time.

It’s also fine to not being able to deliver fully if we had a bold challenge, like a team of designers coding a bot and React.js app. Actually, even if we tried something bold and failed spectacularly, we should be proud of the courage and grit to do it, the effort during the process. Effort and discipline during a mission should always be valued independently of the result. So the problem is not about not being able to deliver, but instead, that we lacked ambition in purpose on the missions we set out to.

We also had some cases of unbalanced teams. Some people explicitly were waiting on other teams to be formed so they could help on. But then the natural outcome is that the people waiting to end up making a team on their own that doesn’t necessarily have the balance to build a whole project. It’s important that everyone understands they have a right and in a way the duty to give ideas and propose their own projects. There shouldn’t be any sort of second-class citizens where some people wait for others to decide on what they should do, independently of the skill or usual role of anyone.

Even if we aren’t satisfied with the output, some good hacking was done. Here are the projects we worked on:

1º Shaque: beat your friends, dislocate your shoulder; 2º Big Spender: pay to win points and go up on the leader board; 3º Qlutch: save your life at the last minute finding the very last person you need for that friendly sports activity; 4º Black box security test for Digital Ocean as a service; 5º “A Internet da Beatriz” - the funniest things of the internet curated by Beatriz Beato; 6º Beira d’agua: the farming knowledge you need in one place; 7º Mob: leave at the right time to save the best score and stand out of the crowd.

Which one is your favorite?

WHAT CAN WE DO BETTER?

A backlog of ideas

One point is to reduce the friction of generating and picking ideas. There is some irony to this as once in a while it feels like we have too many, but when there’s time to hack they seem to disappear. To address this we now have one idea board on trello, that everyone should use to dump ideas whenever they have them, and will be our default repository for hackathons and Investment Time.

Purpose

In terms of ensuring we pick ideas a positive impact purpose, two frameworks for purpose arise:

• This is a full product that solves a problem and we will launch to get feedback;
• This is a learning experiment, so launching is optional, but the demo should display the results of that learning experiment.

In terms of purpose, we should also be weary of what drives us to build something. Even if we should be proud at the end of the hackathon, proud is a side-effect, a by-product of building something that matters. If we do something just because we believe it will drive us to fame or prove we are smart, we are not building purpose but instead being driven by our own ego. Obviously, there is a very fine line between proud as a purpose and proud as a symptom that we did the right thing. As on other subtle topics, wisdom comes from being aware of this fine line, and from questioning ourselves during the process about what drives us, to later make good decisions.

Slides-free demo

As an incentive to hack and get used to demo slightly broken things - which is perfectly normal at a hackathon, we should make a habit of really making a demo at the end of the hackathon. Slides can easily be a distraction and create the wrong incentives: the final presentation isn’t supposed to be a great pitch of an idea or concept, but instead the demo of a prototype.

So for the next hackathon, we should have two rules:

1. The idea either solves a problem or is a learning experiment;
2. The demo must be slides-free so we create an incentive to build and ship things, even if half-baked, ugly or broken, instead of concepts and ideas.

Do you do hackathons with your team? What are the main benefits in your opinion? Send us a tweet sharing your opinion!