Council Post: AI Won’t Close The Ownership Gap In Software Delivery

Posted on October 23, 2026 in business-finance

Steve Taplin is CEO & founder of Sonatafy Technology, a software consulting & engineering firm focused on delivery, quality & accountability

I have founded more than 30 companies over the past 25 years, and 20 of them failed. One lesson keeps showing up: companies are usually quicker to add people, tools and activity than to clarify who owns the result.

Generative AI is creating another version of that problem. I know because I have made the same mistake myself.

The Teams Were Busy, And The Results Were Not There

Inside my own company, I have run into what looked like a capacity problem more than once. The backlog was full. Tickets were moving. Releases were going out. Everyone looked busy, and the natural conclusion was that we needed more engineers.

Before approving more hires, I started asking questions I should have asked earlier: What was each team actually responsible for improving? Who owned that result from beginning to end? How would we know whether the software we released improved anything?

The answers were much less clear than the amount of activity would have suggested. That was when I started thinking about the problem as an ownership gap. Plenty of people are doing the work, but no one person clearly owns the outcome all the way through. On top of that, parts of our operating model were worsening the problem.

Infrastructure was one example. Only a couple of our teams could stand up environments, so everybody else had to wait on them before work could move. We reworked it so that more teams could build, test and deploy on their own rather than everything going through the same few people.

We had another problem between product and engineering. AI made it easy to create prototypes and move ideas forward quickly, but that also meant some work was reaching engineers before it had been properly vetted. In some cases, developers were still trying to figure out what the team actually wanted after the work had already reached them.

We tightened that process so the product could test ideas quickly, make decisions earlier and hand off engineering work that was much closer to being ready to build. Once we fixed those issues, adding people finally made sense. I have done it the other way around before. It just put more people into a process that was already slowing everyone down.

Companies Are Making The Same Mistake With AI

Executives see developers producing code much faster and reasonably start asking whether they need fewer engineers. In some cases, they probably do if someone is spending hours writing repetitive code that AI can handle in minutes, which creates real leverage.

But code production is only one part of software delivery. When I ask leadership teams the same questions I eventually had to ask inside my own company, I often hear the same uncertainty.

Who owns the result? What business problem are we actually trying to solve? How are we measuring whether the change helped?

If developers can produce code faster but only a few people can approve environments or deployments, the bottleneck has not disappeared. It has just moved. Someone still has to decide whether a problem is worth solving. Someone has to think about reliability, security and maintenance once the software is in production.

Fix The System Before You Add Capacity

Before adding people, tools or an outside partner, I would look closely at how the work gets done today to close the ownership gap. I would evaluate whether teams could build, test and deploy without waiting on the same handful of people. I would also check to see if the steps in the process exist because they are necessary or simply because nobody had challenged them in years. Once the operating model is in place, new hires, AI tools and external partners can add real value. Add them too early and you usually end up putting more resources into the same problems you already had.

It’s important to ask these three questions before adding capacity:

1. What Are We Actually Trying To Improve? That sounds obvious, but teams often begin with the solution. We need three engineers. We need an AI tool. We need a new platform. I would rather start with the result the business wants and work backward from there.

2. Who Owns That Result? I want one person whose name is on it, not five people who share it. Shared responsibility sounds collaborative. But when something slips, it gets surprisingly hard to figure out whose job it was to catch it.

3. How Will We Know Whether It Worked? Pick the measure before implementation. It might be cycle time, defect rates, uptime, cost, customer retention or something else. The exact metric matters less than agreeing on it in advance and making sure someone is responsible for reviewing it.

And I would ask the same questions of any outside software partner. Instead of starting with hourly rates or asking how many developers they can provide, ask whether they are willing to examine how your teams currently work before recommending headcount. Ask who will own the outcome. Ask how they will show that the work improved something once the software is in production.

If the answer comes back mainly in hours, resources and tickets, they are still selling capacity. And capacity is getting cheaper. AI is going to put pressure on firms whose primary value is supplying developer hours. Clients expect more from every engineer they pay for—and they should.

For years, software companies could point to hours worked, sprints completed and tickets closed as evidence of progress. AI is going to make that kind of activity much easier to produce. What it will not make easier is deciding what matters, making sound technical judgments and ensuring someone owns the result.

That was the bigger lesson inside my own company. Fixing how work moved through the organization and making ownership clear had more impact than simply hiring more engineers. The companies that figure that out will get much more from AI than the ones that mainly use it to produce more code.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?