Building a stronger and better product through recurring hackathons

Every six weeks my group holds a full day hackathon. This is one day every other sprint where the engineers can put aside the rigors of shipping production software and test new ideas and experiment with creative ways to make our product/service better. This practice has been going for over a year and we have found that this regular dedicated time to explore outside of the team’s backlog leads to a lot of benefits — new features, important bug fixes, better documentation, increased morale and stronger engineers.

Better product

“We are the music makers,

And we are the dreamers of dreams”

— Arthur O’Shaughnessy

Many ideas for new features would normally never make it to the top of the backlog; hackathons provide a way to incubate those ideas. A focused day helps prove them out, show what works (or doesn’t) and, what it will cost to make them shippable.

Sometimes a project will become a product feature, but the goal is not for every hackathon to result in shipped features. Taking an idea through the prototyping phase helps to understand it better. Maybe we learn the idea will never scale or that it makes for a terrible user experience. (Great!) Or maybe we learn it is an amazing idea but will take much more work to make real. (Even better!) Either way, the end result is greater knowledge to help inform the next steps for the product.

Several months ago, a small group of engineers worked on an idea for an extensibility point on the work item form. Multiple customers had asked for a feature like this but the team hadn’t had a chance to work on it yet. By the end of the day they had built a working prototype and had also uncovered an important open issue with the underlying APIs. At this point, we understood the feature and the complications and planned to finish the work in the next sprint. Seeing a working prototype, even if the code is horrendous*, helps accelerate the design and future implementation phase.

Even when the hackathon doesn’t lead to a new feature, it still leads to a higher quality product. Building against your own service (especially on parts you are not as familiar with) can uncover new issues. We discover many product bugs and documentation deficiencies during our hackathons. These are the issues that will frustrate customers. Filing/fixing these as a result of the hackathon ultimately contributes to a better product.

*Don’t check in hackathon code, please.

Better Engineers

Hackathons do not only make the product better, they build stronger engineers. The hackathon is a day to explore new ideas and new technologies. This leads to exposure to languages, tools and services they aren’t typically using day-to-day. We’ve had projects using React, Python, Node.js, Azure Services(ML, Bot, Functions,… etc), Chrome extensions and several open source projects to name a few.

Exposure to different technologies and services helps build more well rounded engineers. Over time a team can develop practices and norms that are not optimal. This happens when the same group of people are building software with the same technology and the same mindset. Stepping out of this bubble to build with new stacks and integrate with different services reveals the ways other people are writing and thinking about software. This can be eye opening and lead to fresh perspectives and approaches in your team.

In some cases, the hackathon projects experiment with technologies our team eventually uses. This happened with React; a few people worked with it during a hackathon and a couple months later they helped drive the team when we started adopting the technology. This led to a smoother and quicker transition for the team.

Better Teams

The hackathon is a powerful morale boost that strengthens the team. We encourage engineers to work in groups instead of individually on their projects. This helps them build deeper connections between each other and take their projects further. Typically, an engineer will propose an idea and lead a team focusing on this project. With this leadership opportunity, an engineer learns how to drive their vision into reality by coordinating and delegating among multiple people.

Hackathon day is distinguished by an energized and enthusiastic atmosphere. The engineers feel deep pride in the hard work they are doing to take these projects as far as they can — hopefully to a point where they can be demoed.. While this is going on they are having a great time; jumping from computer to computer, discussing the code and testing ideas. Everyone on the team looks forward to hackathon day and eagerly awaits the next one. The excitement from the hackathon carries over to the next week where the team feels energized and more committed to the success of the service.

Implementing Hackathons

To implement hackathons, we needed to find a way for them to work within the rhythm of our 3-week sprint schedule.

We broke our hackathon series into three activities: a planning meeting, a hackathon day and a demo meeting. We landed on a full-day hackathon every 6-weeks, an hour planning meeting the sprint before, and an hour demo meeting the week after the hackathon. The three week span between the planning meeting and the hackathon provides time to think about the projects and plan so they are successful. We chose to schedule the hackathon during a lighter time in terms of deployments and sprint deliverables — for us this meant the first Friday of every other sprint.

Planning Meeting

• A meeting to brainstorm ideas for next hackathaon.
• Each engineer submits one idea.
• We narrow down as a group to a few (2–3) ideas to ensure a critical mass of people working on each one.
• Person who proposed each chosen ideas must lead the project.
• Research on the APIs/technologies/design is done ahead of hackathon day by the project lead.

Hackathon Day

• Full day event.
• Team is encouraged to focus on the project by turning off emails (Except for the team DRI).
• The team’s DRI (person on call) need to be on email in case there are any issues (the health of the live service always comes first).

Demo Meeting

• Each project presents to the whole team. They demo the functionality and discussion the engineering design and challenges.
• Whole group can ask questions and provide suggestions on the ideas for next steps of the project.

A year in…

Our six-week hackathon series has been going on for about a year now. We are committed to it and only skipped it once when it conflicted with the Microsoft company-wide hackathon. This regularity builds trust in the team; they know and look forward to the next hackathon. They come to it with great ideas to try to improve the product.

The one issue we saw early on is the need to properly set the expectations that not every idea built will make it into the product. We encourage engineers that really want to ship something from the hackathon to build extensions for our marketplace. This lets them incubate ideas and have a simple way to expose the value to customers (even if it doesn’t meet the bar of a product feature). This also helps us vet the ideas and determine if we later want to integrate it.

Does your team or company do something similar? I would love to hear how it works for you and if you do something different towards the same goals.