After running my consulting business over the last years, I’ve started to see a pattern in the engagements with large companies. The engagement often starts with senior R&D management, one or more lead architects and perhaps a couple of experienced engineers. The focus is some major transformation, platform effort or other topic that starts off as an R&D initiative. As our work progresses, however, it becomes increasingly clear that the project affects all aspects of the company, including business, processes and the organization. Everyone then gets a little fidgety and realizes that perhaps it’s necessary to bring in the business side for a discussion. After some time, typically my next visit, the meeting between the team from R&D and some general managers and a sprinkling of sales, marketing and other non-R&D roles takes place and the weirdest thing happens: the business side actually thinks that they are setting the business strategy! And funnily enough even the team from R&D believes that this is the case! The result typically is a Kafkaesque scene where everyone is really polite, but at the same time the business folks are expounding on their vision and strategy without much connection to the technical feasibility or even market desirability and R&D desperately tries to derive some insight into how the business side is thinking that they can bring into their work.
So, let’s do away with this illusion once and for all: in all software-intensive companies R&D sets the real business strategy. And as all companies are software companies these days, this means that R&D sets the business strategy everywhere. With “real” business strategy, I mean the one that gets executed and not the power-points. The reason is that the architects and R&D leaders take strategic decisions concerning the software and IT architecture that make certain business directions easy, fast and shoe-ins and other directions virtually impossible without major investment, re-architecting and writing off major parts of the infrastructure and existing functionality. Despite all the agile methods, continuous integration and deployment and A/B testing, the fact of the matter is that when you have a couple million lines of code of functionality, you simply can’t turn on a dime. Changes in response to business strategy will take significant amounts of time. In fact, these changes will take much more time than the business side needs to make up their mind and tell everyone what they want.
The consequence is that architects and R&D leaders think long and hard about the likely business directions that the company will take in the coming years. Based on their best bets, they take architecture and R&D investment decisions to enable the most likely business directions. These decisions may happen years before the business side is ready to go there, but that’s fine as it may take the R&D organization all that time to get ready. Not because they’re slow and inefficient, but because there is a lot of code affected by the changes. And there is the sprint heartbeat to get new functionality out every couple of weeks, so the bandwidth is limited.
In fact, my belief is that most cases, where the business side is dissatisfied or even flabbergasted at the lack of R&D capability, are caused by the R&D leaders and architects having made the wrong decisions some or several years earlier. They simply misjudged the business directions that the company ended up taking. Of course, it’s easy to blame the R&D folks, but my experience is that when there is too little interaction between the business side and R&D; when the business side treats R&D as a place where you order functionality, rather than engaging in a strategic partnership, the likelihood of R&D setting the wrong direction goes up dramatically. Similarly, R&D leaders and architects that fail to spend significant time understanding what business the company is in and how this business is likely to evolve, also own responsibilities when R&D and IT go off the reservation.
The main reason for me writing my “Speed, Data and Ecosystems” book was to offer a source that both business leaders and R&D leaders can use to obtain an improved understanding of the societal and industry trends that will likely set direction for the business as well as to offer a rich set of techniques to understand, model and execute on the consequences of these trends. Similar to most of my engagements with large, successful companies, my book offers a bridge where business and R&D jointly develop a common understanding and language to collaborate on preparing all of the company for a bright future, including business and R&D strategy.
Figure: Cover of my Speed, Data and Ecosystems book
Since the book came out, I realized that many want more than just a book. Consequently, I am preparing for a two day course later in the spring where business and R&D leaders can participate to understand and apply the trends and techniques and to explore the consequences for their company and business. If you’re interested in learning more, send me an email at jan@janbosch.com.
