Blog
Company

The Notarize Engineering Hackathon

The Notarize team held its first two hackathons after more than a year of anticipation, planning, and prioritizing. Here's what we learned.
Keith Peters
November 8, 2019
Updated Jan 23, 2024
1 min

The Notarize team held its first two hackathons after more than a year of anticipation, planning, and prioritizing. The pair of events – one held in March, another that wrapped up in October – exceeded our lofty expectations.

Here's what we learned.

1. Pick front-line leaders

The first thing we did was form a Hackathon Committee. We kept it small – just two people – and chose people who Β were experienced and excited to lead the charge. We didn't limit the field to executives or managers. In fact, it's better if the hackathon leaders come from outside of your core leadership. It helps give the hackathon a grassroots feel.

2. Scope the projects and build your teams

Our planning was pretty low-tech: a shared Google Spreadsheet. We came up with ideas by sharing the spreadsheet with the entire company.

The spreadsheet included the projects and which engineers wanted to work on each idea. Engineers could sign up for a project or create their own project and recruit other engineers to be on their team. It took surprisingly little organization other than an occasional nudge by the committee members.

Having the entire company submit ideas helped produce a list of high-quality projects. There were no rules forcing engineers to work on any particular project, and nobody's projects – not even the CEO's – held higher status than another.

But having a list of useful, high-value projects set the tone. We had few, if any, frivolous projects.

Team sizes were capped at three developers. The spreadsheet had three columns for engineer names, so when they filled up, people simply moved on to a different project.

3. Announce a clear deadline

How long is a hackathon? It depends. We considered doing an entire week, but as we began the planning, we realized that seemed really long.

So we cut it down to three days. Then, since this was our first time, we decided to cap it at two days and see how it played out. We ultimately wrapped up after a day and a half, with closing ceremonies at the end of Day 2.

In retrospect, it was the perfect schedule of events for our team, and we used the same schedule for our second hackathon. We might try expanding it to three days next time, but it seems like most people agree that the two days was right on.

Constraints drive creativity. If you start making the activity too long, the projects start getting really big, and people start trying to do fancy architecture and slick designs and production-ready code. Soon enough, it's not a hackathon, but a short sprint.

4. Don't forget to celebrate

As mentioned, we had our closing ceremonies mid-afternoon on Friday. The entire company was invited. The hackathon committee put together a slide deck and every team got up and presented their project.

The teams were excited and proud to show off their work. So many projects had so much business values that in both events, there were literal tears of joy from other departments – for amazing features that would make their jobs so much easier.

After the presentation, a pre-appointed judging committee convened and chose the top three projects. For the first hackathon, miscellaneous physical prizes were purchased as rewards. The second time around, we got Amazon gift cards for the winners.

Most of the teams donated their winnings to breast cancer awareness efforts, which was an amazing and unexpected gesture.

5. Be sure to follow through

So many projects had so much immediate business value that the rest of the company was anxiously asking when they would be able to see those features in production.

We had to temper expectations, explaining that most of the code still needed a lot of additional work, or at least a lot of clean up, testing, etc.

We give company updates on the state of the projects at varying intervals after the hackathon, but getting the projects completed and in the hands of our teammates and customers is vital to the continued success and support of this activity.

____

We've only done two of these so far, so we're still learning and figure it out. But so far, both events have been hugely popular, both with engineers and the rest of the company. We've definitely earned the right to keep doing more of these events. A cadence of six months seems about right, so we've already penciled in our next one for March 2020.

‍

Share this post

Table of Contents

Have your forms ready?
Have your forms ready?

Get an online notarization! Upload, verify, and connect with a 24/7 on-demand notary through the Notarize Network. It's simpler, smarter, and safer than in-person notarizations.

Share this post

The Notarize team held its first two hackathons after more than a year of anticipation, planning, and prioritizing. The pair of events – one held in March, another that wrapped up in October – exceeded our lofty expectations.

Here's what we learned.

1. Pick front-line leaders

The first thing we did was form a Hackathon Committee. We kept it small – just two people – and chose people who Β were experienced and excited to lead the charge. We didn't limit the field to executives or managers. In fact, it's better if the hackathon leaders come from outside of your core leadership. It helps give the hackathon a grassroots feel.

2. Scope the projects and build your teams

Our planning was pretty low-tech: a shared Google Spreadsheet. We came up with ideas by sharing the spreadsheet with the entire company.

The spreadsheet included the projects and which engineers wanted to work on each idea. Engineers could sign up for a project or create their own project and recruit other engineers to be on their team. It took surprisingly little organization other than an occasional nudge by the committee members.

Having the entire company submit ideas helped produce a list of high-quality projects. There were no rules forcing engineers to work on any particular project, and nobody's projects – not even the CEO's – held higher status than another.

But having a list of useful, high-value projects set the tone. We had few, if any, frivolous projects.

Team sizes were capped at three developers. The spreadsheet had three columns for engineer names, so when they filled up, people simply moved on to a different project.

3. Announce a clear deadline

How long is a hackathon? It depends. We considered doing an entire week, but as we began the planning, we realized that seemed really long.

So we cut it down to three days. Then, since this was our first time, we decided to cap it at two days and see how it played out. We ultimately wrapped up after a day and a half, with closing ceremonies at the end of Day 2.

In retrospect, it was the perfect schedule of events for our team, and we used the same schedule for our second hackathon. We might try expanding it to three days next time, but it seems like most people agree that the two days was right on.

Constraints drive creativity. If you start making the activity too long, the projects start getting really big, and people start trying to do fancy architecture and slick designs and production-ready code. Soon enough, it's not a hackathon, but a short sprint.

4. Don't forget to celebrate

As mentioned, we had our closing ceremonies mid-afternoon on Friday. The entire company was invited. The hackathon committee put together a slide deck and every team got up and presented their project.

The teams were excited and proud to show off their work. So many projects had so much business values that in both events, there were literal tears of joy from other departments – for amazing features that would make their jobs so much easier.

After the presentation, a pre-appointed judging committee convened and chose the top three projects. For the first hackathon, miscellaneous physical prizes were purchased as rewards. The second time around, we got Amazon gift cards for the winners.

Most of the teams donated their winnings to breast cancer awareness efforts, which was an amazing and unexpected gesture.

5. Be sure to follow through

So many projects had so much immediate business value that the rest of the company was anxiously asking when they would be able to see those features in production.

We had to temper expectations, explaining that most of the code still needed a lot of additional work, or at least a lot of clean up, testing, etc.

We give company updates on the state of the projects at varying intervals after the hackathon, but getting the projects completed and in the hands of our teammates and customers is vital to the continued success and support of this activity.

____

We've only done two of these so far, so we're still learning and figure it out. But so far, both events have been hugely popular, both with engineers and the rest of the company. We've definitely earned the right to keep doing more of these events. A cadence of six months seems about right, so we've already penciled in our next one for March 2020.

‍

Share this post