Why run an internal hackday

Melinda Seckington discusses FutureLearn’s first ever hackday, why she planned it, how it went and what was gained.

I should have seen it coming that the first post I’d write here would be about a hackday. Hackdays and I… we have a long history to put it mildly. I’ve been regularly attending them for the past seven years. I’ve been organizing them at Geeks of London for the past four, including the 500 person HACKED last year. I’m one of the supporters of the Hackday Manifesto. And even my own previous startup was hatched at one. So yeah, me and hackdays, we go a long way back.

hackday [hak-deɪ] noun
1. A one or two day event where developers, designers and other interested parties come together to build stuff.

What is a hackday?

Hackdays come in all shapes and sizes. Some are extremely competitive, some have prizes, some are for good causes; but at their core they all come down to the same thing: put a bunch of people together for a limited amount of time to come up with something awesome. I’ve always found that a hackday is whatever you as an attendee want it to be and for me hackdays have been always about learning. Learning how to work with new technologies, learning how to work with new people, learning how to work quickly and learning how to build awesome stuff. I’ve always felt that at hackdays you’re surrounded by a ton of other brilliant people, all willing to help out and teach you whatever it is you want to know, and I wouldn’t be where I am today without them.

Why run a hackday?

Ever since I started at FutureLearn I knew we had the right culture and a great team to make an internal hackday work. I’ve always been interested by the idea of doing an internal hackday, but I had previously only done large external ones where the organizational focus is quite specific (in short: venue, sponsors, data, food, prizes). With an internal hackday the focus is slightly different and organizing the FutureLearn one was an interesting, new challenge.

The main thing we first needed to consider was: why? Why are we running this hackday? What do we get out of it? Our main goal was to give the whole team the space to be creative and explore interesting and innovative ways of improving FutureLearn. We wanted to see what ideas people come up with when you give them absolute freedom to work on whatever idea they were most passionate about, allowing them to let their imagination run wild. An extra side goal was to show each other the talent and creativity among our team, and to give people the opportunity to work with colleagues they might not get to deal with on a day-to-day basis.

Include everyone

The second thing we needed to pin down was: who? Should we keep it to just the product team or should we invite the entire company? We very quickly decided it should be anyone that wanted to attend: the more diversity of backgrounds and roles among the hack teams, the more interesting hacks we’d get.

This also led to us making it clear to everyone early on that you didn’t have to know how to code to participate in the hackday. Unlike the more traditional hackdays, our hacks were allowed to be sketches and whiteboard scribbles, as long as you showcased your idea in some creative way.

Besides that, we wanted to also involve the people in the office that for some reason or another couldn’t participate in the entire hackday. We did this by inviting everyone in the office that day to attend the free lunch and the final hack presentations. This way everybody could see what people were up to that day, even if they couldn’t attend themselves.

Create a hackspace

The next issue we needed to look at was: where would we hold the hackday? Should we get an external venue, or should we host it ourselves?

Initially we wanted an external venue that would inspire all the hackers to be creative and think about FutureLearn innovatively. While that still remains a nice sentiment, we realized that the hackday would benefit more from getting the interaction from everybody within the company (as mentioned above), even those that couldn’t participate in the full day. Holding the hackday in our own offices was a much more effective way of showing to everybody the conversation and interaction that went on, and an easier way to encourage them to attend the hack presentations at the end of the day. We were also hoping that seeing the bustle and buzz around the hackday would motivate them to participate next time.

A side benefit of that was that we knew our offices inside-and-out, and didn’t have to deal with the headaches most external venues create, like sorting out wifi, seating and insurance. We knew what was possible in our hack venue, because that’s where we work everyday.

What we didn’t want happening though was that the hackers would sit at their normal desks next to the people they’d normally sit, and get drawn back into doing the work they’d normally do. Instead we grabbed the normally quiet breakout area and turned that into a dedicated hackspace for the day. That area already included whiteboards, and we added several small islands of tables to allow small teams to huddle around and work together. Taking people out of their usual work environment meant again that the hackday allowed for people to work a bit differently than they usually would.

Define the hackday

Once we knew why, for who and where we were running the hackday, we started looking at some of the logistics around it. Should the hackday be one or two days? What day of the week should it be? What should the format of the day be? Should we have presentations? Should we have judges? Should we have prizes?

Since this was still an experiment and weren’t sure how people would react to it, we chose to keep the event simple to allow as many people as possible to come along. We chose a single normal working day, with the hackday running during standard office hours. The day would start with a short kick-off presentation, explaining the rules of the hackday, and would end with presentations from all the teams that created hacks. We settled on a simple but fun prize (tickets to a British Library exhibition) to be determined by popular vote of everyone that attended the presentations.

Give time to prepare

With the hackday only being a single day, we knew that we weren’t actually giving people that much time to hack on their idea. We didn’t want people wasting valuable hack time on the day, doing stuff they could have done beforehand. That known, we tried to give everyone enough time in the weeks before to prepare for the day.

We started by emailing everyone a few weeks before with details about the event. The main call to action in there was for people to come up with ideas and share them on one of the huge whiteboards we had set up for this. Within a few days the board was covered with ideas, allowing people to start choosing what they wanted to hack on.

A week before the event we started to encourage people to form teams already, and to figure out what other tools they might need to pull off their hack. That way during the hackday itself some teams could get hacking immediately.

Be clear what happens with the hacks

At the end of the day, 16 hacks got presented. Some were hugely ambitious, while others had more of a let’s just ship it feel. The winning hack “Moments of Celebration” tapped into a shared feeling that although celebration is part of the product vision it’s not really part of the product yet. What every team wanted to know was, what would actually happen with these ideas?

Before the hackday we made it clear to everyone that anything created during the hackday would be considered and have a chance to end up in the actual product. Since then, the product team has gotten together to review and reflect on the hacks created that day to discuss exactly what is happening with the hacks. Some of the hacks have better defined possible solutions to problems already outlined on our roadmap. Some have helped us understand things more as to the potential benefit and cost of developing the feature. And others have gotten us thinking about things that are missing. Suffice to say, the hackday has had a direct effect on some of the work we’re focusing on in the upcoming months.

Next time

When we do it again (and I’m pretty sure we will do it again), there are a couple of things I’d change. Even though we tried to prepare people, it was tricky for some to form teams and figure out what they wanted to work on that day. There was a lot of discussion happening in the morning, and most people only started hacking after lunch, which meant there wasn’t a lot of time to actually create something. This could be solved by allowing the event to span two days, and in the future we might experiment with that format. Another change would be to add more prize categories; with the range of interesting hacks, it was difficult to only reward one team. Having more categories would allow us to commend more teams for creating awesome hacks.

All in all, I think we can say the hackday was a success. It was great seeing what people came up with when you give them complete freedom on what to work on, and seeing how they work together with people they normally wouldn’t. We ended up with a wealth of interesting and fun ideas, some of which are being integrated into the site much sooner than I think they would have been done without the hackday.

As I said at the start of this post, for me hackdays have always been about learning. It’s part of FutureLearn’s company culture for us to always be learning and doing hackdays like these are yet another way to do that. What did I learn this time? That internal hackdays can be even more fun and useful than external ones… especially when you have a talented team to back them.