By the end of last year I began working on a proposal for the implementation of Innovation Days within the Netquest technology department. My main goal was to provide allocated time periods everyone could spend on whatever they considered most beneficial, in the widest sense, since I believe this empowers each one of us to be more creative and innovative.
I didn't want to be too ambitious so I aimed for a simple set up for starters, scheduling the events in a monthly basis, gathering feedback from everyone afterwards and applying some slight changes on each iteration. I figure this approach sounds about right to software developers, am I right?
The goal of the first edition was to deliver something with a tangible output in its broadest sense, including unfinished and negative outputs. For example:
And it could be in the form of a scope or specification document, an MVP, a PoC or even something production ready; and considering all areas: applications, infrastructure, development tools, monitoring, etc. The only restriction was that it had a real application within the organization.
Since this was the first time we were running this kind of event, everyone could decide if they'd rather make it an individual or a team activity.
The day started having breakfast all together and running a quick showcase of what everyone was up to during the day. By the end of the day everyone presented to the rest of the team what they had achieved, focusing on the problem to solve, who would benefit from it and the proposed solution.
After the event I sent a satisfaction survey to every participant in order to obtain their feedback. The first edition scored an average of 7.45 over 10.
The most valued traits of the initiative were the opportunity of having a time frame to try new things, learn, research or acquire some kind of knowledge; along with the possibility of changing the day-to-day routine and context.
On the other hand, some people considered that maybe just a single day felt short and that teamwork should be encouraged.
I didn't want to make too many changes at once on the second edition so, out of some people's feedback, I introduced a small portion of competition to the event by holding a vote to choose the most innovative idea or accomplishment, where the winner/s would get a prize.
The competition was greatly welcome, although some people thought otherwise. Again, the most appreciated trait was the opportunity to learn. As a counterpart, some people claimed that the concept of innovation might have a negative impact because of its ambitious connotation.
Despite putting emphasis on the recommendation of forming teams, most people were still working on their own and this was also something that came up in the satisfaction survey.
We carried out another two editions without applying any changes to the rules. Unsurprisingly, the received feedback didn't change as well.
After running four Innovation Day editions and mostly due to the feedback I received, I formed myself an opinion on what Innovation Days provide to a team.
I think Innovation Days should be a team activity that takes place twice a year or so. Gather together, form teams and generate ideas, bottom-up, providing value to the organization and to the team itself.
It should be a directed activity, seriously prepared: allocating a couple of days, hold in a nice venue, providing meals and all the necessary material to let people focus on new ideas and making them a reality.
The bottom line is, it should be a team building activity. One of the nice ones.
I accidentally realized though, that there's another angle on the activities carried out during an Innovation Day that wasn't the goal of the initiative but turns out to be, in my opinion, much more relevant to the team members: proactive development.
During the Innovation Days I observed that many (I could even say most) people focused on tasks almost completely related to their day-to-day / backlog / roadmap work. The main difference between those tasks and the ones carried out on a regular day is that they were the ones choosing them. Many of those tasks were mainly technical, related to perform some improvements, refactors, analyzing alternative technologies; but there were also functional tasks, which were simply not yet prioritized, deep down in the backlog or even brand new ideas.
This got me into thinking of the famous Google's "20-time" (20%) or Spotify's "hack time" (10%) but from a realistic point of view, since I was able to see it happen out of nothing. If you let people have some slack, eventually (and I think it would be a really short period), they will end up spending it in tasks closely related to their usual work, with a bunch of major benefits:
All of which will have a significant impact on the work they carry on the rest of the regular days, which are most of them.
I'm not saying that this should be the time when we're allowed to address technical debt issues, evaluate new technologies or implement PoCs. This things should happen without these specific time frames. The company or department's culture should foster this empowerment of the developers. What I'm stating is that we should be allowed some time that's dedicated to our professional growth and within that time, we'll likely spend most of it in tasks that will directly benefit the business as well.
And in order to do so I think it comes down to a single word: trust.
Summing up, I think Innovation Days are a really nice initiative with many benefits for the team, but what I really think can make a difference is letting the team have some slack to enable work to be triggered from the bottom up.
Would you like to leave a comment? Since this blog is hosted on GitHub Pages there's no straightforward way to do so.
Instead, you can add a comment in this GitHub issue. If you'd like to see it here, refresh this page after posting the comment.