(This is a true story, happening to the company I currently work for. Names, domains, algorithms, and roles have been shuffled around to protect my anonymity)

Company A has been around for several decades. It is not the biggest name in its domain, but it is a well respected one. Risk analysis and portfolio optimization have been a core of Company A’s business since the 90s. They have a large team of 30 or so analysts who perform those tasks on a daily basis. These analysts use ERP solutions implemented for them by one the big ERP companies (SAP, Teradata, JD Edwards,…) or one of the Big 4 (Deloitte, Accenture, PWC, Capgemini) in collaboration with their own in house engineering team. The tools used are embarrassingly old school: Classic RDBMS running on on-prem servers or maybe even on mainframes, code written in COBOL, Fortran, weird proprietary stuff like ABAP or SPSS…..you get the picture. But the models and analytic functions were pretty sophisticated, and surprisingly cutting edge compared to the published academic literature. Most of all, they fit well with the company’s enterprise ecosystem, and were honed based on years of deep domain knowledge.

They have a tech team of several engineers (poached from the aforementioned software and consulting companies) and product managers (who came from the experienced pools of analysts and managers who use the software, or poached from business rivals) maintaining and running this software. Their technology might be old school, but collectively, they know the domain and the company’s overall architecture very, very well. They’ve guided the company through several large scale upgrades and migrations and they have a track record of delivering on time, without too much overhead. The few times they’ve stumbled, they knew how to pick themselves up very quickly. In fact within their industry niche, they have a reputation for their expertise, and have very good relations with the various vendors they’ve had to deal with. They were the launching pad of several successful ERP consulting careers.

Interestingly, despite dealing on a daily basis with statistical modeling and optimization algorithms, none of the analysts, engineers, or product managers involved describe themselves as data scientists or machine learning experts. It is mostly a cultural thing: Their expertise predates the Data Science/ML hype that started circa 2010, and they got most of their chops using proprietary enterprise tools instead of the open source tools popular nowadays. A few of them have formal statistical training, but most of them came from engineering or domain backgrounds and learned stats on the fly while doing their job. Call this team “Team X”.

Sometime around the mid 2010s, Company A started having some serious anxiety issues: Although still doing very well for a company its size, overall economic and demographic trends were shrinking its customer base, and couple of so called disruptors came up with a new app and business model that started seriously eating into their revenue. A suitable reaction to appease shareholders and Wall Street was necessary. The company already had a decent website and pretty snazzy app, what more could be done? Leadership decided that it was high time that AI and ML become a core part of the company’s business. An ambitious Manager, with no science or engineering background, but who had very briefly toyed with a recommender system a couple of years back, was chosen to build a data science team, call it team “Y” (he had a bachelor’s in history from the local state college and worked for several years in the company’s marketing org). Team “Y” consists mostly of internal hires who decided they wanted to be data scientists and completed a Coursera certification or a Galvanize boot camp, before being brought on to the team, along with a few of fresh Ph.D or M.Sc holders who didn’t like academia and wanted to try their hand at an industry role. All of them were very bright people, they could write great Medium blog posts and give inspiring TED talks, but collectively they had very little real world industry experience.

As is the fashion nowadays, this group was made part of a data science org that reported directly to the CEO and Board, bypassing the CIO and any tech or business VPs, since Company A wanted to claim the monikers “data driven” and “AI powered” in their upcoming shareholder meetings. In 3 or 4 years of existence, team Y produced a few Python and R scripts. Their architectural experience consisted almost entirely in connecting Flask to S3 buckets or Redshift tables, with a couple of the more resourceful ones learning how to plug their models into Tableau or how to spin up a Kuberneties pod. But they needn’t worry: The aforementioned manager, who was now a director (and was also doing an online Masters to make up for his qualifications gap and bolster his chances of becoming VP soon – at least he now understands what L1 regularization is), was a master at playing corporate politics and self-promotion. No matter how few actionable insights team Y produced or how little code they deployed to production, he always had their back and made sure they had ample funding. In fact he now had grandiose plans for setting up an all-purpose machine learning platform that can be used to solve all of the company’s data problems.

A couple of sharp minded members of team Y, upon googling their industry name along with the word “data science”, realized that risk analysis was a prime candidate for being solved with Bayesian models, and there was already a nifty R package for doing just that, whose tutorial they went through on R-Bloggers.com. One of them had even submitted a Bayesian classifier Kernel for a competition on Kaggle (he was 203rd on the leaderboard), and was eager to put his new-found expertise to use on a real world problem. They pitched the idea to their director, who saw a perfect use case for his upcoming ML platform. They started work on it immediately, without bothering to check whether anybody at Company A was already doing risk analysis. Since their org was independent, they didn’t really need to check with anybody else before they got funding for their initiative. Although it was basically a Naive Bayes classifier, the term ML was added to the project tile, to impress the board.

As they progressed with their work however, tensions started to build. They had asked the data warehousing and CA analytics teams to build pipelines for them, and word eventually got out to team X about their project. Team X was initially thrilled: They offered to collaborate whole heartedly, and would have loved to add an ML based feather to their already impressive cap. The product owners and analysts were totally onboard as well: They saw a chance to get in on the whole Data Science hype that they kept hearing about. But through some weird mix of arrogance and insecurity, team Y refused to collaborate with them or share any of their long term goals with them, even as they went to other parts of the company giving brown bag presentations and tutorials on the new model they created.

Team X got resentful: from what they saw of team Y’s model, their approach was hopelessly naive and had little chances of scaling or being sustainable in production, and they knew exactly how to help with that. Deploying the model to production would have taken them a few days, given how comfortable they were with DevOps and continuous delivery (team Y had taken several months to figure out how to deploy a simple R script to production). And despite how old school their own tech was, team X were crafty enough to be able to plug it in to their existing architecture. Moreover, the output of the model was such that it didn’t take into account how the business will consume it or how it was going to be fed to downstream systems, and the product owners could have gone a long way in making the model more amenable to adoption by the business stakeholders. But team Y wouldn’t listen, and their leads brushed off any attempts at communication, let alone collaboration. The vibe that team Y was giving off was “We are the cutting edge ML team, you guys are the legacy server grunts. We don’t need your opinion.”, and they seemed to have a complete disregard for domain knowledge, or worse, they thought that all that domain knowledge consisted of was being able to grasp the definitions of a few business metrics.

Team X got frustrated and tried to express their concerns to leadership. But despite owning a vital link in Company A’s business process, they were only ~50 people in a large 1000 strong technology and operations org, and they were several layers removed from the C-suite, so it was impossible for them to get their voices heard.

Meanwhile, the unstoppable director was doing what he did best: Playing corporate politics. Despite how little his team had actually delivered, he had convinced the board that all analysis and optimization tasks should now be migrated to his yet to be delivered ML platform. Since most leaders now knew that there was overlap between team Y and team X’s objectives, his pitch was no longer that team Y was going to create a new insight, but that they were going to replace (or modernize) the legacy statistics based on-prem tools with more accurate cloud based ML tools. Never mind that there was no support in the academic literature for the idea that Naive Bayes works better than the Econometric approaches used by team X, let alone the additional wacky idea that Bayesian Optimization would definitely outperform the QP solvers that were running in production.

Unbeknownst to team X, the original Bayesian risk analysis project has now grown into a multimillion dollar major overhaul initiative, which included the eventual replacement of all of the tools and functions supported by team X along with the necessary migration to the cloud. The CIO and a couple of business VPs are on now board, and tech leadership is treating it as a done deal.

An outside vendor, a startup who nobody had heard of, was contracted to help build the platform, since team Y has no engineering skills. The choice was deliberate, as calling on any of the established consulting or software companies would have eventually led leadership to the conclusion that team X was better suited for a transformation on this scale than team Y.

Team Y has no experience with any major ERP deployments, and no domain knowledge, yet they are being tasked with fundamentally changing the business process that is at the core of Company A’s business. Their models actually perform worse than those deployed by team X, and their architecture is hopelessly simplistic, compared to what is necessary for running such a solution in production.

Ironically, using Bayesian thinking and based on all the evidence, the likelihood that team Y succeeds is close to 0%. At best, the project is going to end up being a write off of 50 million dollars or more. Once the !@#$!@# hits the fan, a couple of executive heads are going to role, and dozens of people will get laid off.

At worst, given how vital risk analysis and portfolio optimization is to Company A’s revenue stream, the failure will eventually sink the whole company. It probably won’t go bankrupt, but it will lose a significant portion of its business and work force. Failed ERP implementation can and do sink, see what happened to National Grid US, SuperValu or Target Canada.

One might argue that this is more about corporate disfunction and bad leadership than about data science and AI.

But I disagree. I think the core driver of this debacle is indeed the blind faith in Data Scientists, ML models and the promise of AI, and the overall culture of hype and self promotion that is very common among the ML crowd.

We haven’t seen the end of this story: I sincerely hope that this ends well for the sake of my colleagues and all involved. Company A is a good company, and both its customers and its employees deserver better. But the chances of that happening are negligible given all the information available, and this failure will hit my company hard.