Innovation is Disruptive -- and sometimes forbidden

Saw this on Twitter from @hunterwalk:

Startups piss people off because their existence is a statement that incumbents aren't doing their job well enough

Also true of IT internal innovation.  Pitch a novel, innovative idea to management, and most organizations will find ways to avoid it.  Suggesting a bold new direction makes it look like someone isn't doing their job.

If  you want to see real push-back, try suggesting that the incumbent technology platform needs to be replaced.

As an example, consider an all-singing-all-dancing all VB shop.  The idea that C# might be better is met with a variety of responses.

• It's too costly to change now.  We can't afford the training or the licenses or something.  The list is long and often includes silly costs based on a really bad adoption strategy.  A bad adoption plan allows someone to defend their incumbent technology.
• It's too risky to change now.  What risks?  The list of risks is often surprising and frustrating.  My favorite is the blanket "We don't know what we don't know" risk statement.  That's designed to be a complete show-stopper because there's no evidence to counter it.
• The new Visual Studio has features that make VB acceptable for development.  It's so important to keep the legacy technology that excuses can be made and work-arounds applied to preserve it.

As another example, consider replacing a 30-year old COBOL system.  As part of stalling an innovative plan, I've been told that the only scalable transaction-processing technology is COBOL-CICS-VSAM.  This was about five years ago, when the incumbency of COBOL might have seemed doubtful.  But to IT staff, the idea of Java was too innovative.  

The other problem was the innovative idea of a phased implementation.  Yes.  Agile thinking can be seen as disruptive to project managers; it can appear that they don't add much value.  The idea that we'd build "bridges" between legacy applications and new applications was so unpleasant that we had to spend a long time discussing the maintenance and support of throw-away code that existed just long enough to be sure that all the relevant COBOL had been rewritten.  

Bridges between old and new were portrayed as costly and risky.  These are the usual responses to a proposed new way of looking at the problem.  And, of course, a phased implementation was inherently low-value.  I've been told that a project was absolutely "all or nothing" and no piece had value separate from the complete scope.

Suggesting a change means that there's a problem, right?  It means their 30-year track record of COBOL support is less than perfect.  It means their ability to use VB is flawed in some way.   The only reason for a change is because -- somehow -- they have failed.