I’ve seen it happen time and time again! Someone on the team comes up with a brilliant idea, excitement builds, and before you know it, we’re off to the races. But without a clear process in place, things can get messy fast. Bugs slip through, priorities clash, and suddenly, what started as innovation feels more like firefighting. That’s why standardizing the innovation process is a game-changer. Creating simple, repeatable steps for experimenting, testing, and deploying new ideas helps teams move fast without breaking things. It keeps everyone aligned, reduces risks, and makes scaling innovation so much easier.

Innovation and stability is always hard, but both necessary for long-term success. I would focus in two things: 1. A strong architecture that makes everything easier: I prefer a modular monolith for starting, because it keeps things structured while allowing flexibility. With great opportunities to scale and eventually migrate to another architecture (microservices) when needed. A solid foundation means I can add features without fearing unexpected breakages. 2. Always put the user first: It's easy to overengineer while trying to innovate, but if it don't solve a real problem for users, what's the point? The best solution is the one that makes our customer's life easier and adds real value to their experience. Not just add fancy features.

For me innovation is the key to long term stability. They are not conflicting. But let's be realistic, innovation needs R&D and time. With overarching timelines, I would first go for the proven approach which meets the basic need without spending any build time. In parallel, I would spend time researching a more optimised and scalable way in lower environment and eventually release the enhanced version achieving long term stability without hampering timeline.

I think for balancing between innovation and stability, the most important thing is to have a realistic view. Realistic view by itself is a guide to stability and help to understand the true meaning of stability through instability of real world and life. The team should see and make sense about real users and their requirements and then using agile methodologies help to stay in line with real world and real users, so every innovation can help to make a more comfortable life for everyone involved.

As a backend developer, I'm always curious about updates of libraries I use every day. Sometimes you cannot just follow and apply the updates, but if you want to apply them, nearly 100% unit tests coverage and ready to go ci/cd tools are must have to feel comfortable with the process. Event if the team has more important features to be implemented, it is always valuable to commit some part of the sprint to review and apply dependencies upgrades (or replace them with a better one!) to (in most cases): 1. be less vulnerable to security issues, 2. gain some performance boost, 3. avoid a bigger headache in the future (making an update faster is easier to do earlier than later... e.g. migration to Pydantic v2...).