The Resurgence of ML

Part one ended on a blocker. Until the foundational steps are in place (mature, boring, trusted, secure and governed), you cannot enable anybody to go do anything. That was the groundwork. So when we sat back down with Scott, the question we brought was what happens when that work finally gets the attention it deserves. His answer started with a decade of losing the argument.

Scott spent the better part of ten years making the case for machine learning. He made it to executives who agreed with him, to committees that liked the numbers, and to organizations that then found somewhere else to put the money. The math was rarely the problem. He made the case in the same rooms part one described: Fortune 10 boardrooms, airline operations centers, manufacturing plants, logistics hubs. The analysis was usually sound, but the answer was usually next year.

“By definition, ML is a science project,” he says. “And sometimes science projects result in nothing. More often than not, the projects resulted in massive improvements, but were hard to sell.” Then AI arrived, and inside of roughly two years the argument he kept losing stopped being an argument at all.

“Now the investment in AI is a given,” Scott says. “So let’s try to maximize the output.” Make no mistake, the given isn’t a win, it’s the room changing around him.

The Money Arrived for the Wrong Reason

Ask an organization why it is funding data infrastructure this year and you will hear about AI: agents, copilots, assistants, whatever the internal deck happens to call them. Then follow the dependency chain down. Agents need models, models need training pipelines, and pipelines need clean, accessible, governed data. Near the bottom of that chain sit the feature stores, the model registries, the monitoring, and the retraining systems.

That’s the plumbing. It is also the exact category of work that has been cut from budgets for a decade, for the simple reason that nobody has ever been promoted for building it.

In Scott’s framing, the attention being paid to AI started to trickle down. Organizations that could never justify serious ML investment on its own merits were now building the case a different way. The science project had become a prerequisite for something the company had already decided it wanted.

“A lot of the actual AI solutions, when you get into them, are just core ML features,” Scott says. “So it’s almost like because the trickle-down hit ML next, there’s a lot more attention and focus on it. Now you’re seeing the motivation for data science teams to provide more ML outputs, because the AI and agent frameworks rely on it.”

So the investment that should have been happening all along is happening for a reason that has very little to do with the original argument. Scott is not troubled by this.

“I’m just happy that it’s happening,” he says. “If AI results in more data science, and more data science results in more data driven decisions, that’s a win.”

Velocity Is the Constraint

Ask a data science team how many models it put into production last year. Not how many it built, not how many appeared in a slide, but how many moved from someone naming a problem to something running in production that somebody is maintaining.

“Most data science groups are currently running at one or two a year,” Scott says. “And that’s just not the kind of speed that most organizations have a need for.”

One or two a year is not a talent problem, and this is the part that gets misdiagnosed inside almost every organization. It is an infrastructure problem. When every model needs its own pipeline, its own monitoring, its own governance conversation, and its own negotiated path to production, the fixed cost of a single deployment is enormous. So the team rations. It spends that cost only on problems big enough to obviously justify it, and everything smaller stays on the list.

You know the list. Somebody in your operations group has been keeping it for years.

And if you have worked inside one of those teams, you know the rhythm too. A promising idea in February. A scoping exercise in April. Something that performs well on historical data by July. A conversation in September about who will own it, where it will run, and who gets called when it drifts. By the time anything reaches production, the analyst who proposed it has rotated to another team and the business context that made it worth doing has changed.

The Databricks stack is where Scott sees that arithmetic changing, and MLflow specifically. Feature stores make curated data reusable instead of rebuilt every time. Model registries track versions, so nobody is guessing which one is actually live. Monitoring answers the question part one kept circling back to: is the thing that worked six months ago still working now?

None of that is exciting. That is the point, and it is the moment part one of our series with Scott came back around on me. If it’s not boring, you’re doing it wrong. Scott said that the first time we talked, when he described production systems. It turns out that the machinery that gets you there fits the “boring” circumstances just as well. Nobody demos feature stores, and nobody presents registries in a steering committee. The apparatus that creates velocity is the least interesting thing in the building, and that is the clearest evidence it is working.

The other half of velocity is proximity. A model trained on aggregated data will reach conclusions. A model trained on granular data will reach better ones. “The closer you are to the data, the more likely it is that you can get access to broader and broader sets,” Scott says.

In a medallion architecture, that means gold-level aggregates for business logic and silver-level detail for the nuance underneath it, spread across business units, regions and teams. The organizations doing the best work have access to all of it, and what gives them that access is the semantic layer. On the Databricks platform, that is Unity Catalog.

A data scientist who knows nothing about fuel systems sits down with someone who has spent twenty years in fuel and a data engineer who knows where everything lives. Three hours to map the problem. Two days to something testable. Two weeks to a model running parallel to production.

The subject matter expert has knowledge the data scientist cannot get to. The data scientist has tools the subject matter expert cannot reach. The platform is what puts them in the same room.

That is what velocity means here. Not a faster model, but a shorter distance between somebody who knows something and a system that can act on it.

The Opportunity Is Hiding in Operations

Ask where the machine learning opportunity in an airline sits and nearly everyone says revenue management. It is a defensible answer. Pricing, forecasting and inventory control are well-understood problems, the value is measurable, and those systems have been running sophisticated optimization for decades.

Scott points somewhere else.

“Inside the airline, if half of it is in operations, that operational world is primarily driven by people. To me, there are thousands of use cases within the operations.”

The problems in operations are small, if viewed individually. Half a percent here, a quarter of a percent there. Individually, not one of them would survive a steering committee, but collectively the list of problems may be the largest unclaimed value in the airline because the base they apply to is so large.

If you are anything like me, at this point I wanted the list. Scott could have gone on for an hour, but that conversation deserves its own installment. We’ll save it for one.

“The cost of operations is so enormous,” Scott says, “that if you add up quarter-percent improvements that might only be a million dollars a year each, you’re going to start to see multi-million dollar improvements. But that’s only possible if you can start knocking out one a week.”

Which brings us back to velocity. At one model every six months, a quarter-percent improvement is never worth the paperwork. At two models a week, it is obvious. The opportunity did not change. The cost of going after it did.

In part one, Scott described institutional knowledge sitting in every corner of an airline: operations centers, commercial teams, maintenance organizations, airports, network groups. Those people have been naming these problems for years. Naming them was never the constraint.

That is the switch. Not a new strategy and not a better model. The same list, finally worth working through.

The Fifth-Best Way Still Beats Nothing

There is a failure mode buried inside all the enthusiasm, and Scott runs into it constantly: organizations reaching for a generative AI solution to a problem that structured ML would handle better, faster, and for a fraction of the money.

“If you put time and energy into solving a problem, regardless if you do it the best way or the next best way or the fifth best way, you see a net positive result.”

Then he frames the real cost precisely. Say you found a ten-million-dollar benefit and spent five million getting it. That is a win, and it will be reported as one. The fact that the same benefit was available for one million is a different conversation, and it is one most organizations never have, because nothing in the reporting exposes it.

“That’s a maturity conversation,” he says. “And this is where having experienced people that have a broad understanding of the tools, the problems, and the solutions provide more value than people that can just use tools.”

The gap between what an organization achieved and what was available to it is the truest measure of AI maturity anywhere in the business and almost nobody can calculate it. You tend to find out it existed only when somebody walks in who has seen the cheaper path before.

That is an uncomfortable thing to build a governance process around, because the organization cannot audit for it. A project that delivered its business case closes as a success. There is no line on the review for the version that was never proposed.

In part one, we landed on an intriguing distinction: boring old versus boring new. Legacy systems are already boring, and that is their virtue. The mistake is replacing them with something exciting instead of something equally dependable that can do considerably more.

This time he filled in what sits at either end of it.

“Old boring was a lot of people doing manual tasks they didn’t want to do,” he says. “New boring is checking off that the boring tasks have been done, and now you get to apply your time to the things you really wanted to do.”

What neither of us had named was the distance between them. And as he described it, data living in two places at once, processes half migrated, nobody willing to authorize switching the old system off, I found myself reaching for a name for the territory itself: the messy middle.

The Messy Middle

He answered it with an image of his own.

“It’s like no man’s land,” Scott says. “It’s the worst part.”

And that is the stretch nobody plans for.

Two systems of record and an unwritten convention about which one people actually believe. A weekly export that exists only to reconcile the two. Somebody who knows how to resolve the discrepancy and has never been asked to document it. People whose jobs were built around manual work that is no longer strictly necessary. None of it is broken enough to escalate, which is exactly why it survives.

So the organization runs both systems and pays for both, because it has not yet decided whether it trusts the new one enough to switch the old one off.

His advice is unglamorous and, given everything else he says, entirely consistent: move through it as fast as you can, with someone who has done it before. Stalling is the failure mode. Organizations stall not because they doubt the destination but because the middle is uncomfortable. Every month spent there costs twice and produces once.

What Happens After the Hump

Scott is most animated describing the moment an organization comes out the other side.

The systems work, the data is reachable, models are running, and somebody is maintaining them. Every business unit that spent eighteen months watching from the sidelines shows up at once with a list.

“For the first time in most people’s careers, something actually works between the business and IT that tangibly improves the operation’s efficiency, satisfaction, and performance,” Scott says.

What follows are better problems: how to meter the demand, who gets supported first, how to scale access to something that finally does what people always hoped it would do.

This is the first time the whole stack has existed in a form mature enough to carry what companies want to do with it. “It wasn’t until AI really lit the fuse that you saw just how valuable the platform really was,” Scott says.

By this point in the conversation, velocity had stopped sounding like a delivery metric to me. Two models a week is not really a claim about tooling, it is a claim about how much an organization can act on what it already knows. The infrastructure sets the ceiling. The list has been sitting there the whole time.

After a decade of advocacy, the science project has its budget. The blocker is coming loose.

Now somebody has to decide what to build.