As a consulting company with a growing AppExchange portfolio, we rarely have a shortage of things to do at CloudAnswers. But every month or two, we adjust one of our sprints slightly so that everyone can take a day and work on something new. Usually, we run 24-hour hackathons. They have been a big success: we have received great feedback from the team, launched several products, solved customer problems and our own. So we thought we’d share why and how we run these.

What Is a Hackathon?

In case anyone has not heard of a hackathon, it’s a small competition where we try to build the best software within the constraints and timeframe provided. For example, in January, we did a hackathon where individuals had 24 hours to create something using at least one of the Salesforce Spring ‘21 release features. The results were judged based on pre-defined criteria that we’ll explain later, and a winner was chosen. In this case, the winner just won bragging rights, but often we’ll throw in prizes for some extra incentive.

Why Do Hackathons?

If you read this and say, “this will never work at my company”, then this paragraph is for you. Because at first, we had no idea if this would work for us. The concept of taking most, or all, of our team and telling them to stop doing customer work and to just build something, anything, is a decision that took some consideration. But after doing these semi-regularly for a few years, we’ve realized more value than we expected, and we plan to keep doing these.

First of all, it has been great for teamwork and morale. We are a distributed company with offices around the world, and the hackathons have been a way to bring everyone together for a short period. When we do team hackathons, people get to work together that might not communicate much during their everyday work. And since hackathons typically deal with new technology and don’t have to be production-ready, it’s an excellent way to take the pressure off since we are otherwise shipping code almost daily.

Secondly, we realized that our team has many great ideas, and sometimes they need the space to work on them. When you’re constantly working on products and customers’ projects, sometimes you never take the time to build that great idea that nobody has asked for. But with our hackathons, those ideas have become products on the AppExchange, tools we’ve provided to clients, and internal tools to help speed up our workflow. It’s been quite amazing to see what people build when giving them only a few constraints and letting them make whatever they want.

Lastly, and probably most importantly, it’s a great time to learn. One thing that often separates great developers from the rest is that they naturally try things – often spending a large portion of their free time just “hacking” on things. A hackathon can be a way to get all developers to set aside some time and try something new. More often than not, the hackathon demos include some lesson about how the team tried to build X but ended up building Y because of something they learned. We also use the hackathon themes to encourage particular learning topics; for example, we have a hackathon for almost every Salesforce release where you have to use at least one new feature.

How do we do Hackathons?

We take a pretty lightweight approach to hackathons. We’ve found that you need a certain amount of constraints to get the best ideas, but beyond that, any rules you add can limit the output and make it harder for new employees to understand and participate. And if you make a complex process for running the hackathons, you’re less likely to do them. So as much as possible, keep this process simple. Here’s a summary of our process.

Planning the Hackathon

1. Choose someone to organize it. For large hackathons, this can be a group of people. Feel free to rotate who’s in charge. For us, it’s usually our founder James picking the date, and then we organize it together.
2. Pick a good time and duration. Talk to the team and figure out what time and duration work best for your team and your customer demands. Some organizations do theirs after work one evening; some dedicate a weekend. Since we’re a distributed team, we’ve found it works best to schedule ours for Thursday at 9 AM EST to Friday at 9 AM EST. This gives everyone 24 hours, aligns with the teams’ standups, and allows people worldwide to join the same hackathon.
3. Pick a theme. You can do a hackathon without a theme, but we’ve found it’s often more challenging for teams to decide what to build when there are no constraints. So we ask for ideas in Slack and consider everyone’s input when planning hackathon themes. Some themes we’ve done and ideas that we’ve heard: Industry-specific solutions, Salesforce new features from a release, client-specific solutions, health and wellness, and non-profit solutions.
4. Plan your judging. Judging comes down to two things: judges and scoring method. For judges, you can either have teams vote for each other or invite guest judges that are not in the competition. We’ve done both, and while it’s always nice having a guest panel, sometimes it’s just easier to skip that extra step.

Hackathon Rules

We recommend keeping the rules as simple as possible. Both to make sure that you can enforce them and to make sure that everyone knows them. Here is an example of our rules:

1. All code must be written during the hackathon period unless the code was freely available to all participants before starting. In other words, you can use shared libraries or open-source libraries, but you can’t start working on your project ahead of time.
2. Your solution must meet the theme. For our Salesforce Spring ‘21 hackathon, the solution had to include at least one feature from the new release.
3. Code must be submitted to a GitHub repo for review by judges/other teams. This doesn’t have to be done until the end but helps us verify that no one is cheating.

For an example of what this looks like when it’s all put together, you can check out one of our old hackathons where we invited other companies to join: CloudAnswers Open Hackathon.

What Next?

If you’re looking to run internal hackathons at your company, share this article with the people who can approve it and ask for a simple experiment. Getting everyone to agree can be a bit of work at first, but believe us, it’s worth it. Try starting with a small hackathon – even a few hours one afternoon can be a great way to prove that it’s worth doing. If management doesn’t approve, see if some of the team members want to do a hackathon outside of work hours anyway and then see if management changes their mind after showing them some demos.

If you can’t get it approved or don’t work at a company with enough developers to host an internal hackathon, there are plenty of other hackathons to join. You can check a variety of online websites or look for local developer groups that might host hackathons.

If you’re interested in hearing more about our Hackathons, stay tuned for future blog posts on our hackathon results.