Internal hackdays – the untold story
One of the reasons that got me interested in Luminis Amsterdam was that they have internal hackdays (days where developers, designers, and other interested parties come together to build stuff).
Nowadays, having an internal hackday is not that special anymore: many companies do them (big and small). I liked to hear during my interview that since Luminis Amsterdam started, 1 year back, they already had two hackdays. And the trend continued after I joined them. Unfortunately, four months had passed this year and there was no sign of our next hackday. Having organized a couple of hackdays before, I took charge.
In this article, I’ll describe what I found important and what lessons I learned after organizing a hackday in Luminis Amsterdam. There’s a lot of good advice in there, but it can be a bit tricky to pick the most important one. I’ll be assuming that you’ve already convinced business to allow the hackday to take place (and take care of the eventual expenses).
Hackday guidelines
Here is what others [1, 2, 3, 4] recommend keeping in mind when organizing the hackday:
- define a clear objective of the hackday
- include and invite as many people as possible (even if it’s only for half a day, even if they don’t know much about hacking)
- organize the event in a place that is different from the place where you work every day
- decide of the hackday logistics (choose the day/days, choose the schedule of the day, technical setup, food, prizes, needed hardware/software etc). On some of these aspects, ask for input from participants.
- encourage everyone to prepare for the day (coming up with ideas, creating teams etc.)
- be clear about what will happen with the hacks
- involve business at least in the presentations at the end
- expect things to go wrong
- at the beginning of the day, remind participants of the structure of the day and of the rules and objectives
- define a theme for the day (most usually: solve a problem that your team or the company is facing)
- explore the IT landscape (learn a new way of working, a new technology or work with new people)
- keep the hacks isolated from the other systems
- build the smallest thing possible as fast as possible (it’s called hackday for a reason)
- make a few rules and respect them
Planning the hackday
Giving a bit of context about Luminis Amsterdam will give more perspective about the decisions:
- We’re still a small company, so it seemed important to have everyone showing up for the whole day. Otherwise, we’d be having a hackday with only 3 or 4 persons.
- Being a small company, people have a natural aversion to rules and schedules, so the day should be as flexible as possible
- We wanted to allow people to experiment, learn and have fun together, so there were no restrictions in terms of what topics/ideas participants could work on.
The hackday plan was created by applying the advice to our context:
- everyone had to agree on a specific day to have the hackday
- business had to agree on a clear objective of the day: the project should bring value to the company
- I made a schedule for the day
- I created the rules for the day:
- at least 2 people working per idea (to promote working together)
- demo at the end of the day (in which it is clearly mentioned how what was worked on brings value to the company)
- every person can pitch only 3 ideas
- the logistics needed by ideas were delegated to those that came up with the idea
- I asked people to put their ideas online, in a public space and give a couple of details about the ideas
- the teams were to be formed on the hackday, after the pitching of the ideas
After the hackday
The day itself went quite well and everyone agreed that we reached the goal set at the beginning of the day: “experimenting, learning and having fun together while creating something valuable for the company”
What went well
- working in pairs (pair programming)
- preparing by having the ideas and their short descriptions in a public place
- all the ideas worked on were demo-ed
- there were plenty of ideas presented, so there were plenty of options to choose from
- we had fun while working with new technologies or techniques
What we want to improve next time
- The day passed quite fast. Ideally, on the hackday, the teams are already formed, all the preconditions for developing the idea are met and all the big risks (that could stall an idea) have been eliminated. The rest of the plan of the day is entirely up to the team.
- We encountered difficulties on the hardware project with not having the proper connectors and cables. This one will be mitigated by making sure that the team prepares before the hackday (at least 1 meeting of the whole team). You don’t want to do debugging or workarounds for half of the hackday.
- Have a narrower domain for the ideas. We didn’t want to restrict participants from working on what they want to, but we discovered that the ideas were a bit all over the place and that makes it harder to demonstrate the value generated for the company. A narrower domain, if chosen well, will not restrict participants that much. Involve business when choosing the domain.
What advice we find crucial for the first hackdays
Based on my current experience with hackdays, I would say that the most important aspects to keep in mind when you’re in charge with organizing hackdays are:
- having a clear objective and a theme
- make sure that the ideas are submitted and teams are formed around these ideas. Make sure that the teams meet in advance to prepare the hackday (decide together what they will build, handle the logistics, minimize the big risks)
- have a demo at the end of the day and make sure that business attends it
- at the beginning of the day, remind participants of the rules and objectives
- do not allow participants to work alone on an idea.
