This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team check out our careers page!
If you didn’t already know, hack days come from the traditional hackathon where companies come together with others externally, or internally and spend a limited period of time working on a solution to current problems, or improving internal processes.
The events became quite popular and started to integrate themselves into the framework of software engineering culture in the industry. This has led many companies to dedicate a certain amount of their time to both internal and external hackathons, or in Feather’s case, hack days.
How often do hack days take place?
We do our hack days every third Friday, but this might change as our team grows. For larger companies like Dropbox (they have around 2,800 employees), they can only manage to do a hackathon for a week once per year.
When writing this article, our engineering team is less than 10 people, so we have enough time and capacity to dedicate one Friday every three weeks to the ideas our team has. We encourage everyone to think of a topic before the hack day starts, so that way they’re ready to jump into testing a hypothesis, building a quick prototype, or trying out ideas there’d normally not be time for.
Again, thanks to our small team size, we’ve been able to have a lot of fun over the years with numerous hacks maturing into systems we’re currently using in our daily routines.
You can expect it to be quite different from a traditional hackathon, though, which would require the whole company to gather in one place for a week to brainstorm ideas. Our hack days build on the creative freedom of our team, and they’re tailored to work remotely, so no one has to come to Berlin.
What we work on during a hack day
Because of our small team size, we tend to work on micro-projects that a single person can complete in a day or so. It’s up to each person to decide what the micro-project will be about which is the most important part.
The day begins with everyone sharing what they’ll be working on and ends with everyone presenting what they did or discovered. In the past, these micro-projects have turned into things like press releases, blog posts, new internal tools, or just skills that you wouldn’t otherwise have time to develop.
Since we have hack days once every three weeks, these micro-projects can actually be used over time to work on something much more substantial. In the end, any given year would have 15 – 17 hack days which is about three weeks of pure creative freedom to test ideas.
We’ve been inspired by other companies like Spotify who have used their annual hack week to create well-known features like the discover weekly playlist. Giving people the space and opportunity to be creative can have a huge positive impact on customer experience.
Are there any rules?
While we don’t set many rules, the ones we do have are pretty much just common sense. First, your micro-project has to directly or indirectly contribute to the customer’s and/or team’s happiness (as well as to the company’s success).
And, although hack days are a great time for conducting research and learning new things, we try not to read books or watch videos online. This is something anyone could do during any point of their day (maybe while washing dishes or even hanging up laundry), and hack days are a time for actively doing something that you’d otherwise not be able to do.
What about clearing the backlog? It would make the team happy, but there is most likely a reason a project has technical debt. That’s because technical debt requires a lot more collaboration and QA processes than your average hack, so we prefer to spend an entire sprint dedicated to it. Technical debt also has a whole week blocked in our calendars every three months, and it deserves a separate blog post that will come later.
Want some examples of Feather hack day projects?
Dirty Swan
We built and open-sourced our design system during one of our hack days. You might be able to tell from our website and motto that design is pretty important to us since “simple, honest insurance” means cutting away at messy UI.
One of our main grievances with the insurance industry is that it’s just too complicated too. So, we decided to give our simplicity to those who needed it.
You can check it out at dirtyswan.design.
Migration to Customer.io
At some point, we realized that the notifications we send to our customers are becoming hard to manage and require a developer to be involved in every change. The solution to this problem came from a hack day: we switched from Sendgrid to customer.io and moved the hardcoded email logic to a clean event-driven architecture.
Feature toggles
In one of the recent hack days, we’ve introduced Unleash to manage our features in production. At any given time, there can be multiple unreleased features that would have otherwise blocked the main branch from shipping new code to production. From now on, we hide them behind a feature flag, and it has dramatically simplified the releases.
Set up development snapshot automation
We’ve implemented a tool that restores the staging database in a local environment. We’ve been eyeing Snaplet since its early release, and decided to give it a try. We might not use all of its features and replace it with an even simpler tool, but for now it works like a charm.
Numerous internal NPM packages
We are regularly extracting a lot of internal tools from our code and publish them through Github Packages as private and public NPM libraries. A lot of this work is done during this event, and it’s always a safe bet when you don’t have a bigger idea!
Interested in learning more about the engineering team at Feather?
This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team check out our careers page.
Alternatively, you can check out our blog for our most recent articles!
