Maker Days 2014

Maker Days 2014 logo

So our first hackathon took place last week and I am really excited about the hacks and the effects of the hackthon. At SpeedLedger we call our hackathon ‘Maker Days’.

We started pitching for a hackathon in 2013. After overcoming all business politics involved with pulling out all engineering staff for one and a half day, we finally were able to set a date on Maker Days 2014 Q2. I tend to address the event with as high time precision as possible. 🙂 I believe we will have more Maker Days events. I feel dedicated to make it so.

The hacks

Five projects were developed. The projects characteristics are very diverse, from a reverse-proxy to a bank transaction transferring feature! Have a look.

Background

Me and Pål Brattberg started talking about a hackathon early last year. We were in the middle of migrating our old legacy accounting software SpeedLedger e-bokföring to the new platform (complete rewrite). The feeling of frustration was evident when all engineering capacity were used for feature development and customer migration. Very little time was put on improving technical infrastructure (or hackathons for that matter).

Nevertheless, we were able to pitch a hackathon event in late 2013. The event announcement caused ripple effects. Product realized that we would be spending a lot of time not focusing on delivering to the migration deadline. The original plan was already delayed by months, and this would probably stall it over christmas. It became a matter of company management team. The outcome was that the company declared the situation something we called “state of emergency”. The definition of the state was:

The end of life condition for the “state of emergency” was set to “All new customers and ~80% of existing customers are running on new platform”
Short term commitment. Follow a prioritized list of things that stand in the way of reaching the end of life of the state (above)
Short term velocity over long term velocity. An issue was assigned the person most suited for those specific tasks involved with the issue.
No isolated teams. Work over teams, cooperate if it will increase short term velocity.

So, the state of emergency caused a cancellation of our hackathon. It was postponed until 2014. And here we are…

More about this “state of emergency” another time.

Implementation / doin’ it

Since this was our first hackathon the planning and implementation was quite ad-hoc. I browsed through other hackatonish events to get inspiration and here’s the outline of our event.

Pre-launch

Engineering staff were informed about the event one week before the event (too late) and encouraged to start think about what kind of projects they would want to do. Participants could work alone or in a team. Teams and projects/idea were formed before the event started in order to really focus on getting things done on the event. If Maker Days would span several days I would prefer not to prepare ideas and teams. The forming of ideas and projects is really fun and if time allowed, it would be nice to do that all gathered in one room.

During

We started off Wednesday early morning. The teams would gather and start discussing ideas on how to start implementing and assign tasks. At noon we gathered for joint lunch in a conference room were we discussed progress and what kind of problems we had. Some of us already had some stuff running.

Back to coding.

Come evening we ordered pizza and took a well-deserved break. Focus was now on tweaking stuff to get it in a presentable state. My team made local recordings on our machine if everything would break in the last minute. Pushed our stuff to a more stable environment while others did not have the time and ran it on their local development environment.

Presentation

On Thursday morning all the staff at SpeedLedger were encouraged to attend the Maker Days presentation. Everybody were told to keep their presentation within 4 minutes, thoroughly prepare equipment so that everything just works. We also had some time for questions after each presentation.

The presentation turned out to be a success. Almost everybody attended the presentation in some extent and the teams held their presentations short and concise. All projects had reached a point where something could be demonstrated. After presentation the jury got 10 minutes to deliberate. In the meantime the audience were urged to vote on the one candidate they thought were the best one. I suggested four success factors for the jury and the audience.

Achievement and effort
Innovation
Completeness – how far from production ready state
Relevance

No prize was given to the winner. I was inspired by this presentation given by Dan Pink which really made me think about prizes in these kind of events.:

Dan Pink on motivation

Conclusion

The jury was really impressed by what we had achieved in roughly one day. The jury chose “Zero Install Screen Sharing” as the winner and “Hyperbank” got the most votes from the audience. I got the impression that Maker Days was a great success and some of the projects will probably have effect in production pretty soon and all projects will surely affect our products in the future.

As a developer, I love these kind of events. It triggers a desire of getting through the full stack of technologies as fast as possible to be able to show off what you really want to do. And whilst doing that you learn a lot. Not just how to use the techniques chosen, but also how to incorporate them into your existing stack.

The results from a survey sent out to participants resulted in the following:

91% were happy with the length of Maker Days. Some wanted it to be a half day longer.
83 % had a great time while 17% had a good time.
67% were happy with Maker Days being a competition. The rest were unsure about whether or not a competitive element is a good thing or not.
100% agree upon that it is good thing that no prize is given to the winner.
83% were happy with the presentation length and 17% thinks that the presentations could be tightened.
100% felt that it was ok that managers participated
100% agreed upon making Maker Days a recurrent event. How often varied between every second month to every quarter.

These were tasks needed to arrange Maker Days

Come up with a stylish name for our hackathon
Set a date
Announce the event as early as possible
Involve our designer producing a logo
Create internal wiki page for the event to boost engineers’ engagement
Fix voting papers
Set up winner criteria/success factors
Create a jury (a mix of people representing all departments + external)
Order trophy with Maker Days logo
Make sure participants can work undisturbed, no inbound communication.
Fill fridge with beers and cola. Buy snacks.
Order lunch and evening pizza
Prepare participants before presentation day
Set up presentation stage practicalities (chairs, equipment, lighting, camera etc)
Prepare a survey in order to get feedback on Maker Days (sent out after presentations)
Make a blog post about it

Take-aways

If we can manage to squeeze some more hours into the next Maker Days event I think we should include a preparation part. That way we can jointly reason about ideas and form teams in the most optimal way. It would make people able to more easily join a project not coming from a close team member.

Prior to the next presentation I would suggest that all projects are presented in English and prepared for a public audience. That way we can link them from here so you readers can watch.

All-in-all it was a great happening that seems to really have resonated throughout the company and I’m really looking forward arranging the next one…

That’s all for now folks! Thanks for reading

/Lars-Erik Lis