Slowly but surely, non-software vendors have been waking up to realize that Silicon Valley, specifically, software vendors, are out to eat their lunch. In 2011, Marc Andreessen stated that software is eating the world, in 2015, Geoffrey Immelt said that GE is in the information business, and now in 2020, Volkswagen declared itself to be(come) a software-driven automobile vendor. However, this is more easily said than done, and the path to taking charge of your software future is fraught with possibly serious mistakes. One such mistake is to create your own internal software organisation. A better choice is to leave developers close to the products, but set-up an inner source program to connect them across the organization. Let me revisit this topic.
The most common reaction of large vendors to the rise of the significance of software in their products is to create an internal software organization that develops the software as an in-house service for the established product lines. An existing or new software executive will run this software organization, and existing product units will transfer most or all of their software engineers to the new organization. Existing managers are often happy to let their software engineers go, after all they never really understood software well. The software exec is also happy, because a large the headcount feels good. Even the software engineers are often happy, because they get to be more with their own and the standing of their work clearly improved.
As I previously explained, to a manager the creation of such a software organization feels intuitively right. Based on many years of studying software product line organizations, I can also say that it is a poor decision. Moving software engineers from product organizations into a separate platform organization that feeds the products creates many problems. According to our research, the top three problems are:
- Never enough people to get work done in time. A product organization can more easily acquire new people than the software organization, because it can more convincingly show how these new people will lead to new revenue. This leads to a natural and persistent imbalance in manpower, leaving the software organization always understaffed for the needs of the product organizations.
- Won’t get requirements right fast enough. To understand a product’s requirements, you need to be close to its market. A software organization, separate from the product organizations, is not close enough. We have found over and over again that the so-called domain engineering process in which the platform determines the requirements to support the products, is not fast enough. It takes too many iterations to get it right.
- Won’t get requirements prioritized right. The software organization serves too many masters (or none). Each product organization has its own requirements. We have found that in the fight for prioritizing these requirements, either one strong product organization wins (at the expense of the others) or all product organizations get disillusioned and the software organization gets to prioritize the features (at the expense of everyone but the software organization).
Our work shows that rather than setting-up a new software organization, the existing product organizations should learn to work with each other in the development of a shared reusable components that supports all products. For this, no large new organization is needed, but rather software engineers stay in their current product organization, close to their markets and negotiate open-source-style how to collaboratively develop the shared software they need. This form of collaboration is called inner source. I leave the details of how to do this to my inner source stream of blog posts.
Such collaboration is inevitable. Even if a large vendor has a central software organization, the product organizations will quickly wise up and start (re)hiring software engineers to ensure their products get to market fast enough and with right features. If they survive, that is.
Leave a Reply