When I talk about the concept of making innovation habitual in R&D organizations, many tech executives recoil at first. It might sound daunting or as if it would require even more time from their already-too-busy teams. Some think it might cause chaos where each engineer can do as she pleases. In this article, I will tackle the objection of whose responsibility it is to come up with innovation. But before doing that, let’s make sure that we’re aligned about the value this entails.

Here are a few unsolicited quotes from my clients or readers of The Tech Executive Operating System about the impact they saw from implementing habitual innovation:

“Why can’t the team be like this every week?”

“This is a bonanza and paid for innovation time a year from now!”

“This was the most impactful change we’ve implemented in the past years.”

“I didn’t believe our team was capable of doing this.”

Wouldn’t you want to be in the same boat?

Background: Habitual Innovation

In my book, I describe the concept of implementing regular intermissions in order to provide your team with regular times for genuine creativity to take place. You can some of the specifics in this article, or get here the sample chapter that covers this topic. The gist of it is that your engineers should get the time where they are responsible for their schedule and do what they think is the right thing to do.

These intermissions provide a break from the regular rat-race of sprints. Suddenly, these bright, talented, and well-paid engineers you have can stop operating as Jira-resolving machines and take some time to think. It is precisely this concept that gets many CTOs and VPEs worked up. Let’s tackle the most common objections that I’ve heard recently as I’ve been giving talks about this concept.

Busting Objections

“Innovation should come from Product”

Indeed some innovation should originate from the hard work your product people are doing; there’s no denying that. Nevertheless, why not enlist the massive brainpower that you’ve worked hard to hire to pitch in as well? Each person comes from a different background, and each one can have an idea that others might never have thought about. I call this lubricating serendipity—we increase our chances of coming up with a “bonanza” idea and get to enjoy a whole lot of advantages along the way.

“My team just wants to focus on tech debt”

Sometimes, investing in clearing up tech debt makes sense. However, there’s only so much debt that you can get rid of, whereas the creation of tech capital is uncapped. The fact that the engineers are responsible for their time doesn’t mean they can do whatever they want. Put in place the proper guidelines regarding your expectations: less debt, more impact. I cover various examples of tech capital in | these | resources (and, again, the sample chapter of my book that you can get by subscribing below).

“These intermissions won’t provide genuine impact”

You can only get out of these intermissions as much as you put into them. Without the proper context and background, the team is unlikely to think up anything novel. There are two ways to address this. First, foster Product Mastery so the engineers will understand the business, the product, the users. Without this, their “shower thoughts” will all be about tech and not about your users. Second, the best teams I’ve seen have an ecosystem where people from Customer Success, Marketing, and other departments approach engineers before intermissions and “pitch” them ideas or problems. Just picture what wonders this can do to your company.

“We cannot let engineers do as they want with the product”

No one said we should. I’ve heard of cases where not enough guidelines were given, resulting in engineers pushing for the implementation of features that Product specifically decided against in the past. This isn’t the goal of intermissions. If the team has ideas about internal tools and improvements, they can do as they please. When it comes to actual features or product changes—they have to get someone from Product to “champion” the initiative. Again, like in the previous example, this approach is based on the core belief that your culture should be one where engineers are regularly communicating with others in the company—coders without borders.

“The team’s ideas are all relatively minor”

Lastly, sometimes engineers just tend not to think “big enough.” There’s no one-size-fits-all solution for this. However, in some cases, this could be traced to a culture that’s intolerable for occasional failures. There’s no genuine innovation without some failures from time to time. Let it be known that you expect this. At the end of the day, engineers should be able to justify the experiments and initiatives that they worked on during the intermissions’ retrospectives. If someone routinely places bets that make no sense (i.e., even had they succeeded, they wouldn’t be worth the effort)—give them feedback about it.

If you have any more objections, I’d love to hear them. Reach out!