Innovation is one of those things that every leader wants but has a difficult time implementing due to competing priorities for time and resources. The benefits of innovation are clear: It can drastically improve a team’s output, it gives teams more tools and ideas to solve problems, and in some cases, innovation can lead to culture and technology shifts that can impact an entire company or industry.

If you ever get time to talk with an engineer about what they do at work, you’ll occasionally find passion involved in discussing their newest API, message consumer or UI feature. However, if you ask that same engineer what work they are doing on the side, they will slowly light up as they discuss the newest technology, how they are using it and what their next big idea is. One of the hardest things for leaders across all industries is figuring out how to leverage their employees’ passions while still delivering what’s needed for the business.

About two years ago, I attended a talk at a conference around innovation. One of the things that stood out from that talk was that the speaker’s company didn’t have “innovation” in any title. It was expected that everyone, at all levels, innovates. In fact, it’s so ingrained in this company’s culture that everyone was expected to dedicate 20 percent of their time to innovation. At the time, our team had innovation time carved out in what we called “innovation sprints” – two weeks per quarter dedicated to innovating. In theory, this was time for the entire team to go off and do things that they were passionate about. In practice, most of the time these sprints were never implemented due to needing to finish product work. When we did actually get an innovation sprint, two to three days of that time would be dedicated to planning for the next sprint; and if your innovation only took a day to complete, you would end up looking for things to do to pass the time with little to no other work to do since the quarter had ended. We saw a few things that were ultimately useful, but most of the time, the innovation sprint would come and go without any major breakthroughs. Looking back, it’s not surprising that our business partners didn’t see much value in this time.

After that talk, I thought hard about how we could embrace more of an innovation culture on our team. I thought about that company’s “20 percent of time dedicated to innovation” line and figured out, with some very complex math, that this equated to one full day a week. During my next status with my manager, I proposed the idea of getting rid of our innovation sprints and instead implement “Innovation Fridays,” dedicating every Friday to innovating.

Initially, this was a hard sell to our business partners. Rightfully so, they believed that a full day a week would impact our ability to deliver. Over the next few months, I continued to have conversations with my manager and our business partners to try Innovation Fridays. Eventually, I was able to convince them that we should be agile about the idea, try it, and if it didn’t work, we could always go back to innovation sprints. With that line, and a little bit of luck since we had a long weekend ahead of us and most people out of the office, we decided to give it a try.

The first question everyone on the team asked me was “What should I work on?”, which spurred some very simple ground rules. Work on whatever you want! Learn a new language. Explore a new framework. Take on some tech debt. Work on your story that has been exciting you throughout the week. Work on that proof of concept that has been in the backlog for six months and has never been prioritized. Build a new tool. Automate that painful process that has been giving you a headache. Do whatever you want, and if it’s something cool that you’d like to show off, let’s see it. Do anything that you feel passionate about!

We’ve now had Innovation Fridays for a year, and we couldn’t be more happy with the results. With just four people on our team, we’ve delivered incredible results within our product, while at the same time we’ve implemented through innovation time:

  • A desktop application written in ReactJS that can read/write to any Kafka topic, the newest version even allows you to spin up a local Kafka cluster at the click of a button
  • End-to-end automated functional tests in our test region that constantly run in the background that test happy path scenarios so breaking changes are found quickly
  • A Kafka alerting app written in GoLang and utilizing Burrow to alert if anything is wrong with a topic/partition
  • A Java TokenManager library to help SpringBoot apps utilize new OAuth tokens, and also automatically connects with the internal service alerts library with the token. This tool is now used in hundreds of apps.
  • A ReactJS talent tool idea that was presented to us by our director
  • Kubernetes automated secret management via Jenkins
  • A metrics pipeline for all our apps
  • A Kubernetes desktop app that gives visibility into our namespace, without needing to give everyone direct access to the namespace
  • A Java Spring library to monitor Kafka apps and alert based on message process issues
  • A Spring Boot Bootcamp github pages site to serve as a self-service walkthrough to teach new employees about Spring and Spring Boot
  • A documentation GitHub pages website to house all our team’s documentation

What can be clearly seen in just the list above is how much of our innovation has actually been used to deliver a better product, faster – which is the entire point of being an agile team. So not only have we not seen a decrease in productivity in the last year, it’s actually been the opposite. We know when things break before they get to production. We are alerted to issues before the business is even aware there is an issue. We’re on the forefront of the newest patterns and technology across the company. We’re finding ways to share what we can, as easily as possible, to get others up to speed as quickly as possible so we can focus on delivery. And the big lesson in all of this is that none of this would have gotten done without carving out time to do things that we found interesting.

What are the next steps? First and foremost, this wasn’t written as a prescriptive document on how to innovate, but instead to tell our story of how we had an idea, embraced agile principles, had numerous conversations, and implemented that idea to great success on our team. Maybe that does mean presenting Innovation Fridays to your team, having that conversation or pointing them to this article. Maybe it’s just starting out one day a sprint, once a month, trying out an innovation week, an innovation sprint, or maybe it’s just setting up a day for a team “hack day.” Just start something that brings out the passion in the team. You will quickly see how it strengthens your team, product, and company as problems that never seem to get prioritized start to get realized. But most of all, have fun innovating!