Afternoon Hack

A few thursdays ago we arranged our very first hack day at Telia. The event was attended by 15 people, forming 5 different teams. Snacks and drinks were on the house. Pizza was served to the hungry late stayers. But most importantly: During the day we saw many good ideas shape up and worked on. A passionate group worked hard throughout the day. Some working on internal tools, other groups on customer facing products and new concepts. The results were presented at 9 AM the morning after. And after a vote later in the afternoon, we could announce two "winners". The attendees reported back that they really enjoyed our afternoon-hack event, so we will definitely do more of that in the future.

I have not failed. I've just found 10,000 ways that won't work.

Why are we doing it?

First and foremost: To learn! If TS is going to stay competetive in the Telco market, then we need to learn faster than our competitors. We know we need to find new products and services to attract new customers and retain those that we already have. To do that we think we need to do at least 2 things:

• Create an environment where experimentation and learning can happen
• Run experiments

In a hectic work day it is not realistic to think that people will be able to create time and space to innovate. At least not in the short run. Thus, we need to change the envioronment. Our hypothesis was that a hack day (or a half hack day), could be such a learning environment. After the first experiment we still believe that, but we need to run more experiments to further improve. Other reasons to arrange a hack day:

• Have fun
• Learn new skills
• Get to know colleagues, also from other departments

Although having fun and learning new skills is obviously very important (we believe in creating a work place where people can have fun), I want to especially emphasize the importance of the last point above. We believe that events like these can be a really great way to tear down some of the functional silos that exists in the organization, to create new relationships across departments. The first time around we had a few from the business side. Next time around we hope to get more people from lots of differents departments to attend: More people from the business side, marketing, sales, HR and so on.

What is a Hack day?

A hack day is a timeboxed event where people meet to work on ideas they have for a new product, play around with new technology, together with other people. This creates an environment where people can focus on developing an idea they have without all the interferences that people normally have in their daily job.

Start small, ship it and improve

The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship.

Thinking small enough can be really difficult, but we believe it to be incredibly important. So we wanted to take this approach when launching hack day. A hack day normally lasts a full day, from morning to afternoon/evening. To start small we decided that our first experiment should be a bit shorter, starting from lunch and lasting to whenever people needed to leave. Starting with a short event made it not only easier for people to attend. It also felt like a safe-to-fail experiment, where we could test out the concept and learn (see "What we learned" below).

Show us what you've learned

Teams were challenged to present their hacks on the morning after, at 9AM. To keep things transparent and simple we decided to do the presentations in the open office space. Quite a few people got interested in what was going, and with some good presentations being made we managed to raise additional interest in our afternoon hack day. Next time we hope to have even more people joining. People has already started asking when our next event will take place.

In the afternoon we invited everybody to vote for two winners; best customer facing product and best internal product. No fancy prizes, just the honors.

What we learned from arranging the event?

We tried hard to keep our first event as simple as possible. That approach worked really well. The table below summarizes our key learnings from the event, tools and other learnings.

Since we decided to do a shorter hack day for our first experiment, we accepted that teams presented concepts as hacks. In fact, the two winning teams did not have a potentially shippable product. Next time around, if we are doing a full hack day, we will focus more on getting some minimum products finished.