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.