Over the years, I have seen companies and teams struggle with innovation. It might have worked initially, but after some time,e, the spark that existed when the company was young is now missing. As innovation is important, companies sometimes react with measures such as dedicated innovation teams. However, this way they make sure that innovation will only happen inside these teams and nowhere else. I think that's a massive waste of potential. I have witnessed that the teams who made innovation part of their day-to-day work were the most successful ones.
Innovation needs room to experiment. If you ensure that your teams are buried in work, then there can't be any innovation. To innovate, you need to be able to experiment, and to experiment, you need to have some spare time available.
Even more so, it must be OK that experiments fail. Most likely, most of the experiments will fail, but that is fine. This is how teams learn and gain a better understanding of a problem. If you only ever do experiments that you know will succeed then you're never taking risks. If you're never taking risks, then you'll never truly innovate.
Over the past years, I've seen a couple of techniques that are supposed to give developers the time and space to work on experiments.
A gold card is a mechanism to reserve time for personal activities. Developers can use a gold card to work on anything not related to day-to-day business whenever they want. Unfortunately, most of the teams I know that used gold cards had one major problem: Developers never used their gold cards.
I believe the reason for this is that gold cards are hard to plan. By definition, they are something special you should only take once a sprint/month/etc. This means they can easily be seen as a disruption which might be their main disadvantage.
A lot of developers don't use their gold cards because they feel like betraying their team. How could that extra work be more important than what was already planned? Do other people spend a similar amount of gold cards, or am I selfish?
I've heard statements like these and others.
A hack week is a planned event during which teams work on improving how they work. This can be fixing tech debt issues or automating manual activities.
Hack weeks are better than gold cards because they can be planned ahead of time. Therefore, the whole team is on-board, which eliminates the feeling of betraying the team. This is great because that's already a significant boost in terms of psychological safety for each individual developer.
The main issue I have with hack weeks is their frequency. By definition, you should spend more than one consecutive day. This sometimes leads to them being done only once a quarter not to take too much time away from feature work. However, what happens to issues that you discover right after a hack week? Do they need to wait until the next hack week? It could very well be this way.
Google did this years ago. Every Friday is exempt from standard feature work.
With this approach, you get proper planning (act as if every week only had 4 days) and you get fast iterations (discover an issue on Monday and fix it on Friday). The fact that its only one day is both good and bad. It is good because it forces you to think small and iterative. Since you can't do huge tasks on a Friday, you must figure out the most significant pain point and solve this one. However, it can still be that there are larger tasks that you cannot solve on a Friday. These still need to go into a proper planning cycle. But that isn't bad. If you've found a systemic issue, then you shouldn't work on fixing it alone. Let the team support you!
Experiment and innovate whenever you have the time to do so. I've spoken about work in progress limits a lot. If you manage to set up your team so that people aren't busy all the time, you create an environment where there is always time to experiment. Just use the time when you can't do feature work anyway. Working this way enables people to make minor improvements all the time during day-to-day work. It will also allow them to test out new ideas they had while working on a feature. Most likely even immediately after they have built the feature.