Skip to content

Practical Innovation Lessons from Software Vendor R&D

I recently had the chance to listen in on a roundtable discussion involving a software developer’s R&D group, discussing some of their thoughts on architecture. Some interesting ideas around “innovation” …

Innovation vs. Cost Control

A question from the floor – how sensitive are the R&D arms of major vendors to existing investments in infrastructure for their installed base? Response was framed with a pair of quotes: “Innovation without disruption” is apparently one of their goals. However, is that just fancy talk? Doesn’t true innovation only come from disruptive technology? And “Invention only happens once or twice, in the lab. Innovation is about taking Invention up to scale”. This last one, I think, is the powerful bridge to reality; good ideas are just that, until you can make it a reality for the whole corporation, given limitations of scale plus existing policies / standards.

Innovation vs. Resistance to Change

This line of discussion also made me think that new IT tools / initiatives should be sensitive to our internal user’s existing investments in knowledge / understanding. For internal IT, maybe an important, required conversation would be to agree on the layer / level down to which you will allow “disruption from innovation”. A sensitive balance, and a tough level to identify.

Measuring Success

How does this R&D lab at a software developer measure success? “Productive end-customer adoption” – how many current customers are adopting this stuff in production? It’s one of their KPI’s, and a potential learning for corporate IT – could an internal development group’s KPIs include metrics for internal rate of adoption / use of new stuff we put out into production? They also quoted “Crossing the Chasm”, saying that 80% of innovation is “wasted” – never gets into production, sees the light of day. Is this bad? Nope, the nature of R&D is that a majority of the interesting ideas “fail”.

Corporate IT rarely thinks of themselves like a software developer, but there are many lessons to be learned from those folks.

Comments (0)

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles
AI transformation ownership

Who Owns Your AI Transformation?

IT, Marketing, and Operations can all claim ownership of your AI strategy. Committees claim nothing. The right owner is defined by what they can see, connect, and serve.

Read more
ai innovation environment

Building an Environment of Possibilities – Where AI Innovation Actually Happens

Most AI innovation programs produce demos, not results. The environment that actually ships sits between the sandbox and the cowboy - and it requires judgment, not just enthusiasm.

Read more
AI strategic thinking

Getting Your Team to Think Strategically About AI

Most teams respond to AI with tactics - a demo here, a pilot there. Strategic thinking is a skill that can be taught, starting with three deceptively simple questions.

Read more
ai change leadership

The Empathy Gap in AI Transformation

Experience replaces feelings with competence. That's its job - but it costs you the emotional memory your team needs you to have right now about AI.

Read more