The first Trussle hackathon: what, why... and how did it go?
Product Manager Faris was inspired to run a hackathon after the idea was pitched to him at a Product conference. It wasn’t something Trussle had done before, but Faris wanted to give it a go and see if we could create a project of real value in just a day. After explaining the business value and setting targets to achieve, Faris held our first hackathon in February. Here’s his story about why he was inspired to run a hackathon, how he went about organising it, and whether we’d do one again.
What is a hackathon and why run one?
A hackathon is usually a day-long event that gives people the opportunity to work intensively on a project to create a new piece of software, product, service, or tool without any constraints.
Hackathons are the tech world’s answer to company away days. They might sound like something exclusive to software developers, but anyone can take part in a hackathon with some technical support.
I went to a Product conference with Trussle last year and listened to a Product Manager from Stravatalk about their hackathon experience. I was inspired hearing her explain how they use hackathons to build valuable products and features while having an amazing time doing it.
When you think about it like that, running a hackathon feels like a no brainer. But how do you make sure that it really does deliver value?
Getting buy-in from senior management
Embracing the open culture
Trussle has a very open culture - it’s one of my favourite things about working here. Ideas and opinions from every part of the company are actively encouraged, whether you’re a member of the senior management team or not.
Problem #1: The cost
The main difficulty of running a hackathon at a startup is the high cost involved. A whole day out for the entire team taken up by something that isn’t on the roadmap? That doesn’t sound like it’s in the business’s interests…
Solution: Remembering why we want to encourage creativity
Although hackathon ideas aren’t validated in the same way as the ideas on our roadmap, they’re all about experimentation.
Experimentation is one thing (of many, I think!) we do very well at Trussle. And a hackathon has the potential to deliver some game-changing ideas. The Facebook ‘like’ button was born out of a hackathon, as were the companies GroupMe and EasyTaxi. Sometimes taking the time to think creatively without the structure of a roadmap can pave the way for the most impactful ideas.
Problem #2: Who would participate?
Hackathons work best when all employees come together to brainstorm and create something meaningful in a short space of time.
At Trussle, we have an Engineering team, a Growth team, a Data team, a Design team, a Product team, and a Business Operations team. We also have a Mortgage Expert (ME) team and a Customer Success (CS) team who work directly with our customers, supporting them through the mortgage process. The nature of their work is much more reactive than the other teams, who were able to plan ahead to make sure they had time to dedicate a whole day to the hackathon.
We were very conscious of taking ME and CS support out of action for a day. But for our hackathon to be a success, we needed people from all areas of the business to balance the teams with different areas of expertise.
Solution: Keeping our support team active
To make sure our customers continued to receive the service they expect from us, some advisers and members of the Customer Success team sat this hackathon out. Those who weren’t able to join in this time will rotate with other members of the team for the next hackathon to make sure everyone’s ideas are heard.
I pitched the idea of holding a hackathon as an experiment to our CEO Ishaan. Although he liked the concept, he was understandably wary of the high business cost. We agreed on two goals we’d need to achieve to deem the hackathon a success:
For everyone to enjoy the day
To allow people from different teams to work together
We also agreed - given the high cost - that any future hackathons would have to demonstrate the potential to deliver both business and customer value.
Planning Trussle’s first hackathon
Ishaan gave the green light and the planning began.
I wanted to hear what people in different parts of the company thought of the hackathon idea, so I got a group together to talk about the day and how we thought it should run.
Our aim was to make the hackathon as enjoyable and creative as possible while maintaining focus on the things that matter for our customers. We talked about how we’d suggest project ideas, how the teams would work, and how the winners would be chosen. A couple of meetings later, we had a plan. We gave the company plenty of notice to make sure as many people as possible were able to take part, and hackathon day was booked.
Hackathon day: A timeline of events
9am - Kick off
We all gathered together to listen to each project owner pitch their idea. We’d decided teams in advance so this time was mainly to introduce the day and share what each team would be working on.
9.30am - Work began
We split into our teams and the project work kicked off. There was a definite buzz in the office and everyone seemed excited to get started.
10.30am - Break time
Hackathons are intense, so we encouraged short breaks to keep focus and energy high.
12.30pm - Lunch
One thing was a certainty before we started the hackathon - we’d need to keep our troops properly fed and watered. As the organiser, I had the honour of choosing lunch so went for the obvious choice: hummus.
Unfortunately we didn’t snap the most flattering lunch photo, so I’ve used one from our breakfast instead..!
1pm - Back to it
A few tubs of hummus down, it was back to work. All the teams were working at breakneck speed at this point to get their projects completed - you could feel the brainpower in the room!
5.30pm - Presentations
Laptops were closed and the presentations started. Each team gave a 15 minute presentation of their project, explaining the problem it solved and the value it added to the business.
6.30pm - Winners announced!
The tension was high as we announced the winners. We’d decided to have one overall winner selected by our panel including our CEO Ishaan; VP Operations, Rob; Head of Product, Zoe; VP Engineering, Matt; and Head of Design, Hoon.
And because no competition is complete without a ‘People’s Choice’ award, we made sure to have just that. Members of the Mortgage Expert and Customer Success teams who weren’t able to take part chose the people’s winners - a popular project but one that perhaps wasn’t ready to be implemented just yet…
What’s next for hackathons at Trussle?
What went well?
We knew the first Trussle hackathon was an experiment but we still had two main goals:
For everyone to enjoy the day
To allow people from different teams to work together
Given the energy in the office throughout the day and after reading the feedback we received, it felt like our first goal was a success. We also achieved our second goal and learnt something surprising along the way…
What did we learn?
We needed honest feedback before we could start thinking about the next hackathon. We wanted to find out what people thought worked well and what needed fine tuning so we could make improvements. We shared a post-hackathon survey which surfaced a few interesting insights:
Most people enjoyed the day and felt that one day was a good length of time for a hackathon.
Most people also felt that the main benefit of the day was the opportunity to work with people outside their usual team.
Creating ideas that will deliver value is the aim of a hackathons, but not everyone thought we nailed this part this time.
Although the goal for our first hackathon was to encourage people to work with others outside their usual teams, we need to make sure future hackathons deliver something of value to our customers to justify the cost.
The feedback doesn’t mean that the ideas didn’t bring any value, but in order to get the most out of the day, we need to make sure the business goals stay front of mind.
What would we do differently next time?
As always, we’ll iterate on our hackathon model to make sure next time it’s even more valuable. This time around, the hackathon was very open. We didn’t set a theme for the day or constraints in terms of the types of project or team sizes.
Set concrete timings
Although we set timings, we didn’t follow them to a tee and a few parts of the day went on for longer than planned. Although the teams were agreed in advance, we didn’t allocate time in the morning for any changes, which ended up putting us slightly behind schedule.
The presentations also went on for longer than we’d accounted for, although it was the probably the most fun part of the day so no one complained! Next time, however, I’ll be much more strict with timings.
Choose a theme
I’ll experiment with having a theme for the day to refine the project ideas. Giving people more guidance on the type of projects we want to see will help make sure we’re working on the things that really matter for our customers.
If we choose a great theme that excites people and timings are properly stuck to, I hope we’ll see even more value from our next hackathon.
Our top 3 tips for planning your own hackathon
Find out whether enough people are keen to take part. For a hackathon to be a real success, participation across the company is vital.
Agree the challenges you’re trying to solve. Set a theme to refine the project ideas to make sure you end up with a solution you actually want to use.
Identify what you want to get out of the hackathon. It’s important to set goals - even if you’re running it as an experiment like we did - to measure the success of the day