I believe true innovation isn’t about overlooking key principles—it’s about turning ideas into solid, sustainable solutions. Just like how the invention of the smartphone revolutionized communication, software development needs both creativity and structure. I usually ensure this balance by assembling a diverse team of innovators, builders, testers, and managers, all working together to keep things agile and efficient while maintaining high standards.

Innovation often gets mistaken for a free pass to ignore long-term strategy and foundational engineering principles. True innovation in engineering isn't just about the idea—it's about effectively implementing it. Think about how the dream of flying evolved into today's advanced airplanes. Effective software development follows a similar path, with an experienced team guiding, educating, and critically reviewing the process. A successful project needs a diverse team: idea generators, seasoned builders, bug hunters, product managers, and testing specialists all play crucial roles. And agility and efficiency should be common goals, enhancing rather than slowing down progress.

Innovation has two phases 1) Proof of concept 2) Productization Let us say we are trying to check if LLM can work for us instead of conventional AI. I can do a quick PoC to check the hypothesis. I may not need the high coding standard for the PoC. If it is failure, I can throw the code. If it is successful, productization needs to adhere to the high standards.

Innovation is best achieved through thoughtful, incremental steps rather than by chasing changes all at once. It starts with listening actively, observing carefully and retaining insights that might otherwise be overlooked. When we try to reach a grand outcome in one leap, failure (usually) becomes inevitable. Instead, creating proof-of-concepts (POCs) and minimum viable products (MVPs) allows us to test and refine ideas in real time. This process lets us learn, adjust and grow with each step. By placing trust in well-founded ideas and nurturing them, meaningful results emerge, bringing us closer to success.

Balancing innovation with high code standards is really about finding a rhythm that works for the team. I believe that by breaking down code into small, manageable pieces, it’s easier to experiment without impacting everything. Also,tools that catch little issues up front are lifesavers, keeping the focus on the creative side. Last but not least setting aside time for “innovation days” keeps fresh ideas flowing, while simple, clear documentation helps everyone stay aligned as we evolve.

Innovation is often the result of leveraging existing technologies. It's about how you perceive, integrate, and refine them to create something new that addresses a specific problem. For instance, the motorcycle evolved from the bicycle, and videography from photography—both advancing on earlier concepts. When developing solutions, always identify the most robust and proven technologies as your foundation. Prioritize components that are reliable, scalable, secure, and cost-effective. This approach not only fosters high coding standards from the outset but also simplifies maintenance, providing a solid codebase to build upon efficiently.

The question suggests that innovation and coding standards are in direct conflict, i.e. that one suffer in order for the other to improve. When code standards hinder software delivery, they should be revisited with an understanding of the purpose of code standards. Coding standards should support innovation by setting best practices and avoiding common pitfalls of complex software systems. The bigger challenge is understanding when to update standards or when some innovation pushes beyond what current practices are able support. Software is all about innovation and the practices, tool, and standards need to innovate with it.

We promote an Innovation Sandbox. Creating a safe, low-risk environment where developers can experiment with new ideas without affecting production code is crucial. Sandboxes allow teams to test out-of-the-box solutions, validating their potential. Also pwc coding standards are not rigid rules but evolving guidelines that adapt to new tools and innovations. We even make room for key-developers to propose changes to standards when they find better ways. Innovation shouldn't be stifled by outdated practices.