Every Product Company needs Corporate Innovation Days!
I am part of a small team that organizes a company internal innovation event for our 100+ man strong development organization. I have been part of this so called Innovation Day (iDay) from the very beginning, therefore I want to share how such an event can impact the culture of a company.
TL;DR If you are a product company, developing any type of custom software, and you don’t have an event that taps into the creativity of your engineers: Change that today! It is worth every penny!
Innovation Day Setup
So what is an Innovation Day? In other places these events are called hackathon or hackday. Some corporate examples are the google 20% day, zalando hack week and many others. Fundamentally they are all the same: Allow your engineers to work on projects of their own liking for a fixed amount of time, typically outside of the context of their team.
We kept the concept both simple and open:
- work on a project of your own liking for 1 day (the projects typically still end up at least somewhat related to the domain in which our company operates)
- submit your project if you feel you have something worthwhile submitting (otherwise you can also continue on the next iDay)
- share the projects with the whole organization for public voting. this determines the overall ‘winner’ of the event
- next to the public voting, a jury picks a couple of projects in different categories e.g. biggest productivity improvement, or most flashy UI
By design, we took every single iDay as an experiment. Much like in the agile development paradigm, we used the retrospective learnings from each event, to make the next event better, more fulfilling for the participants, and more beneficial for the company.
Learnings
Some of the areas that have been positively impacted by these Innovation Days:
The creativity of that many people puts a lot of interesting projects in your pipeline. Hence we had to revisit our innovation capitalization process quite a bit. Every time we were reviewing the submissions from our engineers, we were trying to figure out how to best make these projects flow into existing or new products.
Many engineers were experimenting with internal APIs and tools unrelated to their normal work responsibilities. Over time this started to foster an internal open source mentality in the company, which helped to improve the quality of API documentation and the way we think about services in general.
Communication and collaboration. We saw increased discussions between Engineering and Sales about projects coming out of iDay. New collaborations started within Engineering because people from different teams were now working on the same project for a day. The communication between Engineering and Product benefitted from these events as well, because both teams could discuss new ideas independent of any organizational boundaries.
Engineering efficiency got a boost from our iDay activities too. Tools were developed to better align the development guidelines across teams, to get more out of our communication tools (HipChat bot anybody?), or to inspect the internal data structures of our Search Engine.
Culture and Fun. iDays have helped to bring our teams together in a fun, shared global experience. They even had some ripple effects into other departments, which also started to experiment with similar concepts.
Summary
In case your company develops custom software, and you don’t have any type of event that taps into the creativity of your engineers yet, then I hope that this post has you wondering if you should change that.
I would be very happy to hear about your experiences with similar concepts at your place of work!
Photo credit: Missy Schmidt - Innovation chalkboard