With the advent of electric and autonomous vehicles, the amount of software required has grown exponentially. That means newly formed teams must grow overnight, which has two extremes of competing difficulties.
I have watched firsthand as a Napolean-esque CEO fired great talent because the CEO’s hardware background didn’t permit comprehension of building a creative, software team. I’ve seen a frustrated director literally (and dangerously) slam a glass-top, conference table while summarily dismissing managers for being honest about the overwhelming deluge of software defects. I’ve watched dozens of corporations believe a revolving door of low-cost staff augmentation from offshore corners of the world may outperform a more-expensive-per-salary team.
Source: The Complex Creation Of Newly Needed Software Teams In The Auto Industry
Legacy transportation companies making the transition from the ECM-centered software development world to the vehicle-as-a-network-of-computers world should probably rethink their software development methodology, tools, and processes as part of the move. If you adopt a completely-new development platform, but continue to use the legacy process — and the middle management that has been running it — you will transplant 25 years of technical debt into the new paradigm, right at the start. It would seem to be the very definition of the job of “information” and “technology” officers of the company to recognize that their company’s software development systems are 25 years behind the current “meta,” reject the entrenched power structures that have restricted progress for decades, and bring in new people who understand modern software development to setup new teams, tools, and processes.
Well, I guess, that would be the approach if you wanted the company to stay relevant for the foreseeable future. However, if your goals are otherwise, it might not make sense. For instance, if you just wanted to spend the next 10 years collecting stock options to exercise at the opportune time — say, for instance, when you know the company has slid into technical irrelevance to the point of becoming an irresistible target for acquisition by a company which has its software development act together — then your approach to the technical debt problem might be different than mine. It might look a lot like doing nothing at all. Which would hardly be surprising. I mean, look at how much companies in the US are willing to sacrifice long-term success for short-term profits, and how well rewarded such behavior is. You wouldn’t be able to fault people inside the company if they look like they are following the exact same strategy, personally.