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.
TL;DR
Innovation can be something that happens naturally. However, to get there, we need to make sure that teams are set up for innovation.
Teams and managers need to understand that to be innovative, you need:
- room to run experiments,
- understand that innovation does not only happen on the feature-level, and
- make sure you have a great developer experience.
Innovation needs room to experiment
One of the biggest killers for innovation is when workers are busy all the time. 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.
Gold cards
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.
Hack weeks
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.
Hack Fridays
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!
Continuous Improvement
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.
Different kinds of innovation
When I talk to people about innovation, they usually conclude that I'm talking about innovation focused on the product (i.e., new features). But that's only a part of the whole picture. Innovation can and must happen on all levels taking in feedback from all departments.
Product innovation
Your Product Owner (PO) shouldn't be the only person responsible for this topic. Make sure that developers have direct access to end-users so that they can come up with creative ways to help people be more productive.
For instance, if developers do some support work for the product, they build, they are likely to discover common mistakes. Once they understand the issues of their users, they can also come up with solutions for them. The PO can still assist, for instance, by making sure that not every problem is solved through code.
Operations innovation
How we deliver our software is an often overlooked part when it comes to innovation. A couple of years ago services like auth0, Vercel, MongoDB Atlas, or Netlify didn't exist. Therefore, we needed to take care of authentication and hosting ourselves. Today we can save ourselves a lot of time by reducing the time we spend on these topics. This saves a lot of time and makes the experience for our end-users much better. For instance, the smart CDN from Vercel can make your page load faster across the globe, and you won't have to configure a thing to achieve this.
Process innovation
Next to making sure that what we're building is excellent, we also need to make sure that how we're building it evolves. If you haven't changed your process in a couple of months, then this might mean that the process is great. But it can also mean that you haven't learned anything during the last months. Only if we constantly experiment with our processes and try out new things can we ensure that people are engaged and productive.
DX drives UX
You have probably heard of UX (user experience) but have you heard about DX (developer experience)? Maybe. However, I believe that companies all too often do not understand how vital good DX is. Which developer will be more motivated? The one that has to wait hours for a build can't run tests locally, and has no insight into production metrics? Or the one that can test changes quickly and make decisions based on facts? I know that the second developer will almost certainly be the happier one. Since happier goes hand in hand with motivated and motivated means engaged, I would claim that the second developer will build the better software.
The lesson to learn here is that changes that seem far away from where we want to see the innovation can have a significant effect on making them happen.
In the end, we need to make sure to create an environment that motivates people to do the right thing. Furthermore, we need to make sure that people feel enabled to make decisions on their own. If we can achieve this drive in people and add enough context about end-users, then innovation will happen naturally. You won't even have to think about it, let alone create initiatives to force it to happen.
Developers, do you know of any more practices to foster an environment of experimentation? What works at your job, what doesn't? Managers, how does this article resonate with you? Some of the things I've said might sound counter-intuitive. I still urge you to give them a try. What's the worst that could happen?
As always, feel free to reach out to @philgiese on Twitter.