You Don't Need an Engineering Team. You Need an Owner.

The most common objection we hear isn't about cost, and it isn't about whether the technology works. It's some version of: that's great for companies with engineers. We don't have any.

It usually comes from someone running a few-hundred-person business that does something real. They move freight, process claims, manage properties, pack food, close escrow. They have an IT function, and that function keeps the network up, the laptops patched, and the phones working. Nobody in the building has ever shipped software. And every article they read about AI transformation uses examples from companies whose entire competency is building things.

The objection is fair. The conclusion most people draw from it is not.

That conclusion usually takes one of two shapes. Either they decide this isn't for them yet and wait, which is a real decision with a real cost that never appears on any report. Or they buy a tool, because buying is the move available to a company that can't build. Nine months later the tool has four active users, the annual renewal is coming up, and nobody can articulate what actually changed.

Both outcomes trace back to the same misdiagnosis. People assume the missing ingredient is engineering capacity. In our experience it almost never is.

Here's what we've found instead. The hard part of putting AI into an operations-heavy business isn't the building. Building has gotten dramatically cheaper — that's the whole story of the last two years. The hard part is that somebody has to be able to say, precisely, how the work is done today. Not how the policy manual says it's done. How it's actually done, including the exceptions, the judgment calls, the three cases that always get escalated to Denise because she's been here nineteen years and she just knows.

That is not an engineering skill. That's an operations skill, and the good news is you already have it in the building. The person who can describe your claims intake process in enough detail to automate it is the person who runs claims intake. Not a developer.

We watched this play out at a distributor last year. Their estimating team quoted from contractor takeoffs — PDFs arrive, someone reads them, someone keys line items into a quoting system. Hundreds a week. Textbook automation candidate. The build took a few weeks. The part that took months was getting agreement on what should happen when a takeoff is ambiguous, because three branches had each developed their own convention and none of them had ever been written down. No amount of engineering talent would have shortened that. It required someone with the authority to say: from now on, we do it this way.

So when we say you need an owner rather than an engineering team, this is what we mean. Somebody inside the business who can define the process, decide the exceptions, and carry the authority to change how the work gets done. That person is your actual bottleneck, and if you can't name them, no vendor and no partner is going to fix it for you.

There's a second thing, and it's the one that quietly kills more projects than anything else. Whatever gets built has to survive contact with a business that keeps changing. Your payer mix shifts. A carrier changes its portal. A new state gets added. Somebody renames a field in the ERP. If nobody owns the system after launch, it degrades — not dramatically, just gradually, until the exception rate climbs high enough that the team stops trusting it and quietly reverts to the old way. We've inherited a number of projects where that had already happened and nobody upstairs knew.

You do not need engineers on staff for this either. But you do need a maintenance path that exists on paper before you start, with a named person on your side and a named person on your partner's side. "We'll figure that out later" is how you end up owning a system nobody can fix.

Which brings us to what we'd actually suggest asking, if you're a non-technical company evaluating this. Three questions, and they're not the ones most people lead with.

First: who on my team will own this, and do they have the authority to change how the work is done? If the answer is a committee, stop. If the answer is someone who has to ask permission to standardize a process, stop.

Second: what happens when it breaks in month seven? Ask for the specific mechanism. Who gets called, what's the response time, what does it cost, and what happens if the partner disappears. A good answer is boring and concrete. A vague answer is a forecast.

Third: can I see this working on my data, on one narrow process, before I commit to anything wider? Not a demo on someone else's data. Yours, on one workflow, with a real number attached to the outcome. If a partner won't scope something that small, they're selling a program rather than solving a problem.

The reason we push so hard on narrow scope is that it's the only honest way to find out whether the ownership question has a good answer. A four-week engagement on one workflow tells you more about your own organization's readiness than a six-month strategy exercise will. You find out fast whether the process can be defined, whether the exceptions can be decided, and whether the person you named can actually make a call.

None of this requires you to become a technology company. It requires you to be precise about how your business runs, which is a thing good operators are already good at, and to decide who owns the answer when the system meets a case nobody anticipated.

The firms we've seen do this well have something in common, and it isn't technical sophistication. It's that somebody senior treated the rollout as an operations project rather than an IT project, and stayed close to it after launch. The firms that struggled usually did the reverse — handed it to IT, called it a tooling decision, and were surprised when adoption never came.

If you've been assuming this isn't for you because you don't have engineers, it's worth revisiting the assumption. The more useful question is narrower and more uncomfortable: which process do you understand well enough to describe completely, and who gets to decide what happens on the edge cases? If you can answer that for even one workflow, you have enough to start.

We're always happy to walk through that question with an operator and be straight about whether there's something worth doing.