In an effort to drive innovative thinking in my engineering team I have had them read "The Innovators Dilemma" by Clayton M. Christensen. One of the key concepts in the book is how Value Network’s prevent otherwise successful companies from initiating or responding to Disruptive Innovation.
Though this term is overloaded, Christensen defines a Value Network as:
"The collection of upstream suppliers, downstream channels to market, and ancillary providers that support a common business model within an industry. When would-be disruptors enter into existing value networks, they must adapt their business models to conform to the value network and therefore fail that disruption because they become co-opted."
Value Networks are inherently self-reinforcing and cause often-catastrophic organizational inertia. Counter-intuitively, the more successful an organization is (in the traditional sense anyway), the more valuable the network is, and the greater the inertial effect that network has on the organization’s ability to innovate. Being in a Value Network seems to amount to signing up for collective-blinker-wearing in the name of short- to mid-term success. Not only do the members of the network not want disruptive innovation, they also don’t seem to see it coming; and when they do, they are often powerless to do anything about it because of the need to maintain short- to mid-term revenue.
"The Innovators Dilemma" was first published in 1997, making it a relatively old book, and its position as the state of the art in Innovation Management has been usurped by "The Lean Startup" and its ilk, but most of the ideas contained within are still highly relevant. I am routinely amazed, and not in a good way, by how few professionals, in either explicit or tacit Innovation Management roles, have read this book, or are even aware of the principles it expounds, despite how accurate they have been shown to be. This book should be required reading for everyone involved in Innovation Management, which is just about everyone involved in commercial software development in my opinion.
I have found that the notion of inertia-causing value networks is applicable to more than just organizations; it is also a very useful metaphor for planning one’s career as a software professional. As a software engineer one develops one’s own Knowledge Value Network simply by using languages, tools, platforms and technologies on a day-to-day basis.
Microsoft SharePoint is a very good case in point; a SharePoint Developer is not just a .Net Developer with some SharePoint knowledge; SharePoint has enough breadth and depth that it is a domain in its own right, and becoming expert in all its APIs, services, models, schemas, languages (CAML anyone?), and other technical concepts, is at least a fulltime job and maybe two. One could have spent the last decade just doing SharePoint development, making lots of money and getting ahead in the world of software development, and never have heard of Hadoop, Node.js, Scala, or even other Microsoft technologies like ASP.NET MVC.
So what happens when SharePoint's star starts to burn through the heavier elements? When does one become aware of the fact that one’s future success is no longer assured by being a SharePoint expert? Probably too late in one’s career to do anything about it, spending one’s technical twilight years doing legacy SharePoint application support. Old software does not die; it simply becomes covered under different clauses in the support policy.
I am not making any assertions about the specific future of SharePoint; this is most definitely a product with long legs, but it is a truism that those legs will get shorter at some point in the not-too-distant future and then disappear entirely.
I have also seen this phenomenon time and time again in large-scale enterprise development; a team of talented young engineers are hired to develop, enhance and maintain a complex line of business application. After a few years, and dozens of releases, the software has become so complex that it is a knowledge domain in its own right. New developers on the team take six months to get up to speed, despite being experts in the tools and technologies with and on which the application is built. Knowledge of the product’s minutia becomes the developers’ personal value proposition and source of job security. They live and breath the technical intricacies of the application every day, to the exclusion of emergent and alternative technologies that are simply not part of the technology-mix used by the application. The line of business application, its tools and technologies become their personal Knowledge Value Network. And like organizational value networks it is closed and self-reinforcing. These same developers often struggle to find financially and intellectually rewarding work when they literally emerge from under the rock.
Developers who do not recognize this will find themselves technically irrelevant at a critical point in their careers. One hopes that they have decided to follow the management track before this point, otherwise they are going to find themselves grey-haired individual-contributors with technical skills only relevant for supporting legacy applications. That it not to say that this will be a poor source of income, but no amount of money is worth the soul-death that becoming a professional manager means for many software engineers.
So how does one avoid this fate? Set aside time each week to research emergent and competitive technologies, products, platforms, tools, methodologies, languages, architectures, designs, metaphors, patterns, anti-patterns, philosophies and domains. And don't just be reading edge; if you can actually play with these technologies, do so, even if you can't leverage that work in your day-job. Not only will it give you real job security and maintain your sanity, it will also make you a better software engineer.
A personal example was learning Dynamic and then Functional Programming. A few years ago I decided to learn Python and then F#, despite the fact that my day job at the time required neither. Learning these languages has made me a significantly better C# programmer, though I still can’t tell you exactly why a space suit is like a monad; or is that the other way round? No matter. I also find that I am now able to solve programming problems far more elegantly and simply that I would have before learning these languages.
My personal practice is to set aside a few hours per week and let my curiosity drive me. My most recent endeavour has been to work through Daniel Shiffman’s excellent new book, “The Nature of Code”, which is about simulating real-world phenomena in code. The examples are all in Processing and I have had a lot of fun creating random animated 3D surfaces using Perlin Noise. And no, it doesn’t have anything to do with SharePoint; but that is the point.
Stay curious. Disrupt thyself.
