Why do companies underinvest in internal AI tooling, and what does it cost them?

Interviewer's question: "Why do companies underinvest in internal AI tooling, and what does it cost them?" Windward Regional Airlines flies a fleet of turboprops out of one regional hub. Yusuf Karahan has managed maintenance parts planning there for eleven years.

How to answer this, stage by stage

Nobody is grading whether you can list reasons companies under-fund things. They're grading whether you can name the one check that tells you which reason is actually true here.

Let's learn

PartsPilot is a tool that would read maintenance logs and parts-usage history and tell planners which parts to reorder before a plane actually needs them.

Before it, and still today, Yusuf predicts parts demand from memory and a shared spreadsheet, checking stock counts across three hangars by hand, about six hours a week on top of his regular planning work.

The turn: the underinvestment was never one decision. It was the ordinary budget process, working exactly as designed, applying a "does it have a projected revenue lift" scorecard to a request that was never going to score well on that question, no matter how good the tool would have been.

Same team of six engineers. One ask always wins the comparison before anyone even reads the details.

At its worst: an aircraft sat grounded for fourteen hours because a part everyone "knew" was running low never got flagged in time. Yusuf was on vacation, and the backup planner was working from a different, older version of the spreadsheet.

None of this was ever the plan. It's what fills the gap when the sanctioned tool never shows up.

What I would leave alone: not every internal ask deserves its own dedicated headcount. A tool with no evidence test result behind it, just a hunch that "AI would help," is a fair thing to deprioritize. The problem isn't caution, it's caution applied by the wrong yardstick.

The lesson: a rejected proposal and an ignored one look identical from the outside, and they need completely different fixes. Find out which one actually happened before arguing about anything else.

Now here is the same thing as a story

The short version above is what you'd say defending the diagnosis to Windward's finance committee. Read this one for how Yusuf actually spent those three years.

Yusuf Karahan has planned maintenance parts at Windward for eleven years. Ask him which hangar is short on brake assemblies and he can tell you before he's finished his coffee.

He filed the first ask for PartsPilot the way the process asks you to: a short write-up, no attached cost estimate, because nobody told him one was expected. It sat in a queue for four months, then quietly dropped off the next planning cycle's list. Nobody told him no. It just wasn't there anymore.

The second time, he learned from the first round and filed with real numbers attached. That year, the same review cycle was also deciding whether to fund a customer-facing chatbot for flight delay notifications. The chatbot had a name, a launch date, and a marketing plan built around it. PartsPilot got eleven percent of the engineering time it asked for, enough to build a prototype that nobody had time to finish.

By the third year, Yusuf had quietly stopped asking through the official process at all. There was no single day he decided this. He just noticed, somewhere over those two years, that filing the ask took an afternoon and produced nothing, while building his own version, badly, in a spreadsheet only he fully understood, at least produced something he could use on Monday morning.

Same four steps, three years running. The only thing that changed was which year it happened in.

The near miss came on an ordinary Thursday in October. Yusuf was on vacation. His backup, a planner from a different hangar, pulled up what he thought was the current parts-forecast spreadsheet and reordered against it. It was two revisions old. A brake assembly that Yusuf's real, current spreadsheet had already flagged as critically low never got reordered. The plane sat grounded for fourteen hours while a part got couriered in from another hub.

Here's the decision I'd take back: scoring every AI ask, internal or customer-facing, against the same "projected revenue lift" sheet. It made sense when most of what came through that committee did have a revenue story attached, and using one scorecard for everything felt fair, not biased. It stopped making sense the day a fourteen-hour AOG cost more than three years of the tool would have.

Replayed with a separate scorecard, one that asks "what does it cost us if this specific thing goes wrong" instead of "what revenue does this add": PartsPilot gets scored against the AOG cost it actually prevents, not against a chatbot's marketing plan. It clears the bar in year one. Eighteen months later, the same brake-assembly shortage gets flagged automatically, three weeks out, while Yusuf is on the very same vacation, and nothing grounds.

I filed that first ask with no cost estimate because nobody told me the committee needed one to take it seriously. It took a grounded plane and a scared phone call from ops to see that the committee wasn't refusing to take internal tools seriously. It just had no honest way to measure what one was worth, and defaulted to the only number it knew how to read.

The five letters, run against a budget meetingNot a checklist for blaming a company. TRACE is what tells you which of three real causes actually explains a specific underinvestment.

All three were true at Windward in different years. The evidence test is what tells you which one to fix first.

PartsPilot sat in the bottom two branches for three years running. Nothing about the tool itself ever changed that.

The recap, one line per letter: timeline is three losing cycles, not one; recut is maintenance starving before revenue-facing teams; assume nothing rules out AI skepticism; cause candidates are the three named reasons; evidence is the planning-doc check that tells them apart.

And if you want to be sure it really works, try it somewhere elseSame five letters, a credit union's fraud-review desk instead of an airline hangar. Nothing about the two jobs is alike.

Cedarholm Credit Union wanted an internal assistant to pre-screen wire transfer requests for fraud indicators before a human reviewer signed off. Basil Antczak has worked fraud review there for six years.

Mapped onto TRACE: timeline is two budget cycles, the ask filed and quietly dropped both times, never once formally rejected. Recut: fraud review, a cost center with no product owner, loses every cycle to the mobile deposit team, which has a visible growth number attached. Assume nothing: the credit union's leadership approved a customer-facing chat feature the same year, so it isn't skepticism about AI itself. Cause candidates: no member ever complains that fraud review is slow, the same three engineers who'd build it are needed for the mobile app, and a fraud loss that didn't happen shows up nowhere. Evidence: pulling the planning docs shows the ask never once reached a capacity review, the same-engineers cause, not the ROI one, which points at a completely different fix than Windward's.

Windward's own timeline. Cedarholm's runs two cycles instead of three, but the shape is the same: quiet, then sudden.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "internal tools starve because nothing complains, they compete for the same engineers, and the cost hides until it breaks. Find out which by checking the planning docs," and stop.
Cost: if pulling three years of planning history isn't possible, ask the one person who filed the original ask what happened to it. They usually remember exactly.
The model gets better, for real: even a genuinely excellent internal tool proposal loses this fight if it's scored on the same sheet as a customer feature, so the fix is about the scorecard, not the pitch.

Where people run it wrong.
They treat every underinvestment story as the same cause, usually "leadership doesn't get it," without ever checking whether leadership funded something else that same quarter.
They count the visible incident cost and skip the quieter cost of the workaround people built while waiting.
They fix the scorecard company-wide before confirming which of the three causes actually explains this specific case.

How to use it live. When someone asks why internal tooling gets starved, ask yourself first: did this ask ever reach a real review, or did it just get quietly forgotten? The answer changes which of the three causes you should even be arguing about.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0