Tom Peruzzi's thoughts on digital, innovation, IT and operations

Company Hackathons

Posted in general, general failures, startup failures by opstakes on October 5, 2016

34207-NZINCW.jpgDesigned by Freepik

In one of my last blog posts I wrote about hackathons in general and what you should care of if you plan to invite externals (only). Organizing an internal hackathon only is somehow different with regards to drivers, motivation and resources.

The difference of internal and external hackathons

While an external hackathon is often an invite to others with similar/same interests to participate in some kind of joint co-innovation effort with (free) food (see also this wikipedia entry) an internal one is somehow different:

  • people know what you are doing already, potentially no need to explain the company goals but maybe biased as well
  • free beer and food is potentially limited
  • it is more about fostering the innovation capabilities of your crew rather than getting inspired externally
  • you have to rethink how to reward accordingly

The 3 models of internal hackathons

Generally speaking there are a few different ways to enable hackathons inhouse:

  • Developing a one-time event and reward with budget and resources to develop further and create a first prototype
  • Developing continous hackathons focussed on creating customer value
  • Developing continous hackathons focussed on solving problems, getting rid of legacy, fighting for a topic (eg. simplicity) or learning new technology

All of them are valid and vivid options and may be important tools in the company’s innovation toolbox. Anyhow all of them differ in how to set them up:

1.) One time event

Definitely I would never recommend to make a hackathon a one time event but let us have a closer look on it (and hopefully decide to make it an annual event 😉 )

The aim of such an event is mostly to foster internal innovation capabilities and capacities and get some special reward. Without reward it will be a nice event only and the reward should not be a bonus. Think about Daniel Pink and his book about motivation. What I have learned is a great bonus and reward is getting free time, a team and some budget to nail down your hackathons result and create a first PoC or even more. Don’t grant free time only. Free them up from daily routines, create extra time and space for them, let them be “their own boss” to solve the problem. A good reward is something like:

  • the best idea gets 3 people and enough money to go beyond PoC (eg. 30k Euro in digital space)
  • the 2nd best idea gets 2 people and some money to organize and manage the PoC and start thinking about how to go further (eg. 20k Euro in digital space)
  • the 3rd best idea gets 1 resource and some money to be able to go for the PoC if everything goes right but will need more personal effort to get  things done.

What you need to do too is to let them be as startup-like as possible and don’t confront them with enterprise barriers (eg. you have to use SAP as we use it internally). Let them be as enterpreneurial as possible.

Finally one important remark: If you decide to go further than “just” the PoC you have to contemplate on how you can reward them further. A good hint would be like xing did with the xing labs naming the origin of the feature released. (It’s not about money)

2.) Developing continous hackathons with focus on customer value

May it be hack days, weeks or special weekends, bringing together and let them explore without corporate control is a very unique experience and allows you to make use of the innovation potential of your employees. Be prepared: without proper reward it may become a one-time-wonder.

What we figured out during running hackathons is that the best reward you can get is that your idea gets implemented. So we ensured as the corporate leaders that at least 1 of the top 3 gets implemented within the next 5 sprints and are willing to do even more. Mostly it was even more because employees understand your product and market and often know upsell potentials better than you, even if they are not a sales or product expert.  You will experience a lot of surprise and please let people know and take part on your enthusiasm. Regular hackathons without the backing of the leadership team are worth nothing. Even the idea to have some fun or do some crazy stuff, ‘act like a startup’ will die immediately without proper reward and recognition.

3.) Developing continous hackathons with focus on solving problems

Similar to number 2 but slightly different with regards to the goal, maybe even more dedicated to a single team than a mixed effort. To help people getting rid of problems beside the daily routines dedicated hackathons to solve internal problems can be a good problem solving path.

Always share a topic, don’t let them do what they want and do not allow single-person actions. We figured out that e.g. simplicity (everything that makes your or your colleagues live easier), elasticity (everything that let us react automatically and properly on changing user demand) are pretty good examples, allowing space to develop and grow.

Again – and repeating – don’t forget the rewards and recognition. If you want people to participate and engage, be passionate please set up the right reward system. Again, mainly not money, recognition, being named as the origin source, or some special treatment may be way better than anything else. Create a demanding but fair jury, allow them to present properly and applause. It is the free extra work of your employees, don’t take that work for granted.

Conclusion and remarks

I would always propose to start with some hackathons. Beside creating value or solving problems you normally don’t have time for it is another great method to bring people in touch, let them form teams and learn the team mechanics of your department. You will be surprised seeing people work harder and longer you would have ever expected.

I personally got in touch with Cocreation while reading Chesborough’s book. It is fully understandable that no company can own all talent and should make use of it by doing co-innovation and co-creation. Hackathons are a good tool doing so.

We should not forget to not only foster the wisdom of the crowd but foster the wisdom of our crew too. This is why creating internal hackathons is equally important than external ones but often forgotten or canceled by daily operational business pressure. Let us change this and make use of the talent we have infront of us.


Hackathon Does and Dont’s

Posted in general by opstakes on October 28, 2015

IMG_4774While wikepedia puts hackathons in the domain of computing only (see here), in my understanding a hackathon must be defined much broader and many examples show evidence of hackathons growing up in non-IT spaces.  It is a timeboxed event where any sort of interested people try to build a solution for a given problem or try to create value on top of existing data, interfaces or anything else (e.g. Chemistry Hackathon). There exist plenty of websites like which offer a calendar of upcoming open hackathons. And most important to name is the uncountable number of internal hackathons giving employees the chance to promote and develop their ideas which would never see light otherwise. More and more hackathons are accepted as a useful tool of open internal and external innovation. Hence more and more hackathons come up, willing to embrace the power and genius of each participant.

But what makes a hackathon a successful one? There are some obvious ones like

  • more than enough drinks and food (and geeks do not eat burgers and pizza only)
  • a good work- and playground
  • a clear, demanding but achievable goal, a real world problem
  • passionate supporters and a not to homogenous group of hackers
  • the story must go on (the end of the hackathon is not the end of the idea!)

While one mIMG_4924ay wonder why adequate prices are not in the list because they are not primarily necessary if you really match the 4 rules. As you may notice those 4 are quite similar to what Daniel Pink thinks makes a team successful; purpose (the demanding goal), mastery (matching with others in playground) and freedom (the team is self organized). One should not forget how important an adequate amount of humour might be. Especially as pride and sorrow may change a few times during a hackathon. The longer it takes, the less sleep you have, the more humour (not sarkasm) is sometime needed to keep you going the last mile…

And finally one more word: the result of a hackathon is not a ready-to-rollout product. It is a bunch of ideas with a first prototype or even a little bit more. As mentioned earlier prices are not the goal of taking part. It is relevance and every hackathon organizer should ask him or herself, how each hacker can keep on contributing or how his idea gets acknowledges when it comes to a real product later on. There exist some pretty good internal hackathon stories which result in labs, where the idea can be used in real by end-customers and the inventors are shown on the labs page, official contributor lists and many more. It highly depends on what you want to achieve and within which context.

How does your project plan look like?

This plan should give you a rough idea, it may vary depending on your case. It was used for a roboter hackathon with external teams only (see robothon)

Weeek 1: Workout on the goal, which is achievable in 24h, not too easy, not too strong, take care on your audience. Think about what sort of Tech you will need to help them solving the problem.

Week 2: Check financials, if needed talk to potential sponsors, at robothon we asked for 100 Euro per team only, rest was paid by sponsors (which is quite demanding if you work with roboters). Think about what you may tell sponsors already. (We decided to write about the claim only (10 items, 10 meters, 10 minutes), not about technology and other jobs to be done like we wanted them to think about a business canvas too)

Week 3: Setup a small website and social communities

Week 4: Send invites to people you want to be there

Week 5: Allow teams to register, media work

Week 5-8: Collect all necessary info (T-Shirt sizes ..), print shirts, prepare location, food and drink, prepare space to relax, prepare room to play.
Week 9-12: Invite VIPs, Jury, sponsors, define criteria for success, enable online team voting, search for volunteers, photographer, video-team, organize post-demo party

So within 3 months a solid hackathon is organized, take that time, especially consider more time for the first 3 hackathons.

The hackathon day (24h):
14:00 welcome
14:15 Intro, rules, schedule
14:45 Show playground and working area
15:15 Unpacking
16:00 GO
22:30 Part Exchange 1 (allow the teams to change parts if necessary)
24:00 Midnight break
8:00 Part Exchange 2 (allow the teams to change parts if necessary)
14:00 allow public viewing for the last 2 hours if OK for the teams and if a hackathon with externals
17:00 And the winner is …. and party 🙂

IMG_4892I will continue to organize internal and external hackathons. One thing you have to acknowledge is, you should truly try to understand what makes the teams successful and what motivates them to come back for the next session. We started working with a University team of occupational scientists in order to get those questions answered (Pilot study in German out there, ping me if you are interested). Do not forget, that a hackathon results in a lot of energy and a lot of work to do upfront. You are then paid by energetic teams, an incredible amount of creativity, fun and ideas. You get tons of leadership and group management insights and you get not only prototypes but loyal hackers giving their time and passion (for free) to you!

Enjoy and take care on your hackers!

%d bloggers like this: