AeroFS Team, Engineering

We recently held our third internal Hackathon, and the results far exceeded our expectations. Aside from the intangible benefits to teamwork and culture, literally every project had one or more elements that we are productizing and integrating into AeroFS.

High risk engineering

One of the most important aspects of a hackathon is that it is a safe environment for the critical work of attempting high-risk experiments.

We all know that failures provide valuable results, and the company needs to make a space for those attempts somehow. Although most people conceptually agree on the above, it is especially challenging to foster that environment when you’re focused on growth and shipping a real product to customers.

I don’t think I need to say much more about why we conduct Hackathons. But I do want to share some thoughts about how we conduct them in hopes that they may be useful to others.

Oh, and if the engineering culture described here seems interesting to you? You should probably talk to us. Soon.

Scheduling: opportunistic

Schedules are hard

In the US, the week of Thanksgiving is an annual puzzle for project managers. Is three days even a “week”?

Rather than try to scale our expectations for planning, we simply removed the vestigial week from the planning calendar. Our project roadmaps were scheduled assuming no progress that week, but that did not mean that we couldn’t get some work done anyway.

This three day hole provided a natural drop-in for a “Hack Week”.

We kicked off the hackathon on Monday morning; checked in at a team “Friendsgiving” Tuesday night; and by mid-afternoon Wednesday we held demos, chose our winners, and then relaxed with some social time. It was an energizing lead-in to the holiday
weekend.

This turns out to be a strength overall – it is a better, and safer, use of time and attention than trying to cram in one last commit before your flight.

This three-day schedule felt about right, but we don’t have enough data to say that it’s the best length.

Frequency: as often as possible, and no more

Schedule pressure is real

You might expect that a company might treat this type of event as a loss of scheduled development time, and try to limit how often we do this. In fact, the opposite is true. The projects were so creative, and the results were so impressive, that we are getting pressure from literally every person on the team to do them more often.

My view is that the actual limiting reagent is setting the events far enough apart that each time feels like a special event – a welcome visit from an absent friend. We’re still experimenting to find the best rhythm. Right now, the plan is to
try a quarterly hackathon.

The biggest mistake would be to say “we’ll do them when we have less schedule pressure”; as most engineers will tell you, that day will never arrive.

Make it a priority: No hall passes

Screen sharing, how does it work?

 

As I briefly mentioned earlier in the post, project schedules accounted for the missing week — all ongoing projects were suspended. However, we still wanted everyone involved. The hackathon was not “optional” — every engineer who was present was expected to participate.

There are multiple reasons why we wanted everyone to participate:

  • It creates a feeling of value. Something everyone is working on.
  • If you have some people working on “real work”, while others are working on the hackathon, people may feel pressured to continue working on their regularly scheduled work.
  • Similarly, having people skip the hackathon implies the event is not important, both devaluing the efforts of others, and the hackathon itself.

Have a theme, not requirements

A loose theme.

Having a theme is important because it creates a loose framework for the team. You definitely don’t want product requirements to be a part of your hackathon, but a theme allows people to easily discuss projects, compare ideas, and generally make sure we’re all “swimming in the same direction”.

We keep the theme open to interpretation, but the teams should be able to tie their work back to the theme. The better your work applies to the theme, the more the rest of the team will appreciate it.

This time we asked the team to focus on defining new features and services. Bug fixes and improvements for internal services were not allowed (that seemed too close to “real work”).

As a company, we are strong believers that a Private Cloud architecture gives businesses and users the best mix of usability, privacy and features. Like everyone, we still find ourselves using public services when there is no private equivalent. And we grumble about it.

So, our theme was: leverage our Private Cloud infrastructure and expertise to build a better version of a public cloud service.

For historical purposes, our first-ever hackathon theme was a deliberate effort to validate our new API before announcing it to the
public. We have also used a hackathon to experiment with improvements to our
developer and production infrastructure.

Play favorites

I'm pretty sure it IS a word.

We give equivalent prizes in two categories.

1. Most impact: Vote for projects that make an impact on the stated theme. This rewards those 80/20 projects – where a few days’ work can make a big difference in our lives.

2. Technical amazingness: Vote for projects that accomplished something amazing, or took on a crazy amount of work, or attacked the hardest problem. We want to recognize the technology innovators here, regardless of how shiny the results are. This could also be a cool failure.

We choose the winners by secret ballot. All humans present at the demos get a vote. Non-humans can observe, but cannot vote.

One very important note: Live count the votes! I almost screwed this up. Tallying the votes on the board was surprisingly fun – tense and dramatic. The two leaders for technical amazingness prize were, through sheer good luck, tied until the very last vote was counted.

Speaking of prizes: Have some

This bird is so proud.

In my view, the ideal prize for an internal event should be:

  • coveted: The rest of the team actually wants it – it’s not a white elephant.
  • unique: You can’t obtain this prize any other way.
  • valueless: No monetary value. This is a physical manifestation of pride.

As an obvious example, a retailer gift card is perhaps the worst employee prize imaginable.

The big prize for this Hack Week was truly a big one:

  • A hand-made “You win hack week!” certificate.

But it has to include some other reminders you can use to remind the rest of the team of your amazingness:

  • gift certificate for a pint of delicious Scoop ice cream (I realize this contradicts my 3rd point about the prize being “valueless”, but Scoop is so delicious that we couldn’t resist).
  • A ribbon and medal
  • the right to choose the movie and dinner for our next Movie Night.

Grounding the discussion

Do not do this

Of course, it’s unlikely that two different companies will run a hackathon the same way. There is no “one size fits all” for hackathons, just like there’s no “one size fits all” for management, company building, or engineering practices in general.

This is only how we’ve handled hackathons in our short time running them. We hope this information has been useful for you, but we’d also love to hear from you how you run your own hackathons, if you’re willing to share.

— Jon & the AeroFS Team.