Innovating when software is boring

Bridging the Gap: Understanding the Divergent Desires of Enterprise Customers and Software Developers in Lean Startups.

Enterprise software is boring (rare exceptions apply). Despite how great, useful, and profitable it could be, the boring nature of it has an accumulating, negative impact on the development teams that make this software - the vendors. The smaller, the leaner, the faster an enterprise vendor is, the bigger the gap between what the customer needs (a.k.a. the business goals of the vendor) and what engineers aspire to work on.?

It should be obvious that in this equation, the business goals, the product that solves the problem for the customer in a way the customer is ready to adopt, trump the personal aspirations and desires of a developer. After all, the goal of the company is to make money, and making customers happy has everything to do with it.?

This disparity influences the perception and morale of those at the coding helm. Customers of enterprise software generally prioritize stability, reliability, and efficiency. They prefer solutions that integrate seamlessly into their existing workflows, enhance productivity without disruptive changes, and offer robust support and security. Frequent updates or new features, while potentially innovative, can be seen as risks that might complicate or destabilize systems that are central to their business operations. Enterprise customers want to be updated about coming changes months ahead of release. They don’t want to retrain the personnel if a change to the user journey is introduced. They worry that the new “killer feature” will disrupt their process and create more risks. Corporate IT will never push a new update to the endpoint devices - they will wait for the service pack with the fixes. Enterprises, despite how innovative they can be with their products, have allergic reactions to changes in software provided by 3rd party.?

On the other side of this divide are the software developers who work in the companies that supply the so-needed software to the mentioned enterprises. The professional satisfaction of those developers is often tied to innovation and the creation and use of cutting-edge technologies. Developers thrive on change and improvement, eagerly exploring new technologies and methodologies that promise to revolutionize how problems are solved. However, when their day-to-day work seems disconnected from these aspirations—mired instead in routine updates and the maintenance of legacy products, delivering minor changes, and cosmetic improvements —their perception of their roles can skew towards the mundane, leading some to feel that their skills are not being fully utilized or appreciated. This goes beyond personal frustration. The whole product strategy of the company they work at is perceived as non-innovative. There are no “game-changers”, no “killer features”, and not enough “wow factor”, despite the company producing what the customers need.

This misalignment can lead to a sense of stagnation within development teams, especially when they perceive their work as lacking in innovation and impact. It can happen even if the company is successful and valued by its customers with feedback and the depth of their wallets. Connecting the financial metrics with engineering, transparency, and articulation of the perceived value translated into money has a limited impact on engineers, as I noticed. They are happy the company does well, but they are not happy with what they do for it. This feeling, if left unattended can lead to a zombification of the organization, loss of engagement, and churn.

The role of product management in this is important, but cannot offer a complete cure. It is up to the product organization to identify the right amount of innovation the enterprise customers can accommodate and work around it, finding creative ways to innovate on customers' behalf and finding a way to reduce friction by creating self-explaining systems, simplifying onboarding and pushing customers towards novel and more efficient ways of doing things. It is difficult, it is twice as difficult to ensure the engineering is bought into this "dripping innovation" approach.

Yet, it is precisely within this context that the concept of "innovating inwards" becomes crucial. Innovating inwards refers to the practice of focusing on internal improvements and innovations that may not be immediately visible externally but significantly enhance the technical landscape of a product and improve the development process itself. Every engineer wants to do a great job and take pride in their delivery and there is more than one way to do it. There are ways besides delivering a groundbreaking feature to a customer that would freak out.?

Innovating inwards can take several forms. Here are some examples in the non-exhaustive list:?

• Refactoring existing code: to improve its structure and maintainability without altering its external behavior and making it run smoother, faster, and less coupled.
• Adopting new software development tools and practices: that enhance productivity and collaboration, such as Continous Delivery, TDD, pairing, Trunk Based Development, or even more advanced version control systems.
• Implementing modular architectures: to make applications more flexible and easier to manage, setting the stage for smoother future expansions.
• Focusing on security enhancements and optimizations: that, while not flashy, are crucial to maintaining the trust and loyalty of enterprise customers.
• Increasing observability: Gaining visibility into how your product works by investing in observability leads to the discovery of dark and uncharted areas that are great targets for refactoring and simplification. I have seen tracing uncovering unnecessary hops between interfaces no one knew about, just because there was something removed a couple of years ago.
• Investing in internal capabilities: Scalability, reliability, elasticity, availability.?The enterprise customers highly appreciate those capabilities and getting to an advanced level of those requires a lot of deep and sometimes low-level knowledge and innovative approaches.
• Cost-effectiveness: Cloud and other infra costs can spiral out of control easily. Embracing the FinOps approach, and making sure the infrastructure and the product are developed most efficiently require innovative thinking and the use of very novel tools and services that your cloud provider offers.??

By channeling the drive to innovate into these internal advancements, companies can reconcile the divergent desires of customers and developers. Customers receive the reliable, stable software they require, and developers engage in meaningful work that pushes their capabilities and enhances their engagement.

This strategy not only improves the product but also cultivates a culture of continuous improvement and innovation within the organization, ensuring that both customer satisfaction and developer engagement are maintained. As such, innovating inwards is not merely a compromise; it is a strategic approach that maximizes the strengths and meets the needs of all stakeholders in the enterprise software ecosystem.

To the happy teams!?Hear, hear!

#innovation #management #technology #leanstartups #enterprisesoftware