Leave a comment

Leave a comment

I’ve watched companies roll out AI initiatives with all the right language and none of the real intent. Leadership gets excited about possibilities, middle management gets cautious about disruption, and the teams on the ground are left trying to fit something new into a system that was never designed to support it. A few pilot programs show promise, some efficiency gains appear, and then the entire effort gets absorbed back into the old way of operating. The structure wins every time.

That’s the part no one wants to admit. Most organizations don’t want to change. They want to improve just enough to stay competitive without disturbing the internal balance that keeps everything predictable. AI becomes a layer on top of the business instead of a force that reshapes it, and that’s why so many of these efforts stall out long before they deliver anything meaningful.

AI Doesn’t Transform—It Exposes

If you want to become a real change agent in the age of AI, you have to start by rejecting that entire approach. You can’t treat AI like an upgrade to an existing system because the system itself is the problem. The processes, the approvals, the incentives, all of it was built for a different era, and layering intelligence on top of it only makes the cracks more visible.

Most people aren’t comfortable with that level of honesty. They’d rather focus on tools because tools feel manageable. You can learn them, measure them, and present them in a way that looks like progress. Questioning the system is different. It creates tension, and tension is something most organizations are designed to avoid.

What AI really gives you isn’t just speed. It gives you clarity. It exposes redundancy in ways that are hard to ignore, and it highlights how much of the work inside an organization exists simply because it always has. When you start to see that, it changes how you think about everything from decision-making to ownership.

You Have to Choose What to Break

At that point, you have a choice to make. You can use AI to reinforce what already exists, or you can use it to challenge it. One path keeps you aligned with the organization, and the other puts you at odds with it. Only one of those paths leads to real change.

I’ve learned that the people who drive transformation aren’t the ones with the deepest technical knowledge. They’re the ones who are willing to question why things are done the way they are. They look at a workflow and ask whether it still makes sense, and they don’t accept “because we’ve always done it this way” as an answer.

That mindset creates friction, and friction is unavoidable if you’re serious about changing anything that matters. Organizations resist change because it threatens existing power structures, and AI has a way of accelerating that threat. It doesn’t just make work more efficient/ it reveals where control is being held for the wrong reasons.

Where Most AI Initiatives Quietly Die

That’s where most initiatives break down. The technology works, but the organization quietly rejects what the technology exposes. People protect their roles, their influence, and their version of how things should operate, even when it’s clear that a better approach exists.

If you’re stepping into this environment as a change agent, you can’t ignore that dynamic. You have to move directly into it. That means pushing beyond pilot programs and forcing successful ideas into the core of the business, where they actually have an impact. It means taking something that works in isolation and proving that it can outperform the existing system at scale.

That’s when resistance becomes visible.

Don’t Wait for Alignment—Create It

I’ve seen teams build AI-driven capabilities that could fundamentally improve how a company operates, only to have those capabilities sidelined because they didn’t fit neatly into existing approval structures. I’ve seen leaders celebrate innovation in public settings while quietly slowing it down behind the scenes because it disrupted their span of control. None of this is accidental, and none of it is new.

What is new is the speed at which these tensions are surfacing.

AI compresses time in a way that organizations aren’t used to. It lowers the cost of experimentation and increases the pace at which results show up, which means the gap between what’s possible and what’s actually happening becomes impossible to ignore. That gap is where change agents operate.

They don’t wait for consensus because consensus usually forms around maintaining the current state. Instead, they create undeniable proof that a different way works better. They build, test, and implement faster than the organization can debate, and they let results force the conversation.

AI Is Pressure, Not the Solution

The mistake most people make is assuming that AI is the change itself. It isn’t. AI is the pressure that forces change to happen. It exposes inefficiencies, accelerates feedback loops, and makes weak thinking more obvious. If you’re not willing to confront those things directly, AI won’t help you. It will simply highlight the problems you’re avoiding.

Becoming a change agent in this environment requires a different posture. You have to be willing to challenge assumptions that have been in place for years, and you have to do it in a way that produces tangible results. Talking about change isn’t enough. You have to demonstrate it, even when it creates discomfort.

There’s no version of this where everyone is aligned from the beginning. Some people will resist you because the changes you’re driving will alter how they operate or reduce the control they currently have. That resistance is a signal that you’re pushing on something real.

The companies that come out ahead in this era won’t be the ones with the most advanced AI models. They’ll be the ones willing to rethink how their business actually functions. That shift doesn’t happen through consensus or careful alignment. It happens because someone decides the current state isn’t good enough and starts building something better.

If you’re waiting for permission to do that, you’re already behind.

LEARN MORE

Leave a comment

Most organizations approach artificial intelligence the same way they approach any new technology. They look for cost savings, productivity improvements, and return on investment. Those metrics matter, but they only tell part of the story.

Leave a comment

Leaders are asking the wrong question about AI. They want to know how much value artificial intelligence can create for the organization. That question matters, but it’s incomplete. A better question is this: How much value can AI create, how effectively are we using it, and what are we risking in the process?

AI value can’t be measured by productivity gains alone. It can’t be reduced to saved hours, lower costs, faster workflows, or fewer employees. Those numbers may look good in a board presentation, but they don’t always tell the truth. A company can move faster and become sloppier. It can cut costs and lose institutional knowledge. It can automate processes and weaken the judgment of the people who once understood the work.

Benefit. Utilization. Consequences.

The first measure is value creation. This is where most companies begin, and for good reason. AI can help teams work faster, reduce repetitive tasks, improve analysis, draft content, summarize documents, write code, support customers, and identify patterns buried inside large amounts of data. These gains are real and we should measure them.

The mistake is stopping there. A company that uses AI to save ten hours a week hasn’t automatically created strategic value. The real question is what happens with those ten hours. Are employees using that time to deepen customer relationships, improve products, make better decisions, and pursue growth? Or are those hours disappearing into more meetings, more noise, and more low-value activity?

AI Utilization & Efficiency

Leaders shouldn’t only ask whether AI creates value. They should ask whether the organization is using AI efficiently enough to capture that value. That means looking at adoption, training, workflow integration, quality control, and use-case discipline. Are employees using AI in ways that improve outcomes, or are they just experimenting without direction? Are teams applying AI to meaningful business problems, or are they forcing it into places where it doesn’t belong? Are managers measuring the quality of AI-assisted work, or only the speed of completion?

AI utilization efficiency is the difference between owning a powerful tool and knowing how to use it. Many organizations will buy AI platforms, announce AI initiatives, and still fail to gain meaningful advantage because they never redesign the work around the technology. They add AI to broken processes and expect transformation. That doesn’t work. It only makes poor systems move faster.

Leaders should begin with clear use cases. AI should be tied to a real business problem, not vague pressure from the market. If a company adopts AI because competitors are doing it, the initiative starts from fear rather than strategy. That usually leads to scattered pilots, weak governance, and inflated expectations.

A solid use case answers basic questions. What problem are we solving? Who benefits? What processes change? What improves? How will we know? What could go wrong? Without those answers, AI becomes theater. It looks innovative from the outside, but inside the company, it creates confusion.

What Are the Consequences?

Every AI gain should be measured against its potential harm. Speed is a good example. AI helps organizations move faster, but leaders should ask whether they are moving too fast. Faster research can support better decisions, but it can also create false confidence. Faster content production can increase output, but it can also flood the market with generic thinking. Faster software development can accelerate innovation, but it can also introduce errors, security risks, and technical debt.

The same applies to cost reduction. AI can reduce headcount, but leaders should be careful about what else gets lost. When experienced people leave, they take judgment, context, relationships, and cultural memory with them. Those assets rarely appear on a spreadsheet, but companies feel their absence when things get difficult.

This is one of the hidden dangers of measuring AI only through efficiency. An organization may look leaner while becoming weaker. It may process work faster while losing the human knowledge that helped it interpret complexity. It may reduce payroll while damaging morale, trust, and collaboration.

Corporate culture also matters. If employees experience AI as a threat, adoption suffers. If they see it as a tool that helps them do better work, adoption improves. Leaders need to measure trust, not just usage. They should ask whether AI is strengthening people or making them feel replaceable. The answer will shape how deeply the technology becomes embedded in the organization.

The best AI measurement system balances four questions.

1. What value did AI create?

2. How efficiently did we use AI to capture that value?

3. What did we gain in speed, cost, quality, insight, or capability?

4. What did we risk, weaken, or lose along the way?

That last question may be the most important one. AI can make an organization more intelligent, but only if leaders use it with discipline. It can amplify judgment, but it can also replace judgment with automation. It can increase capacity, but it can also create dependency. It can help people do better work, but it can also flatten the human expertise that makes the company distinct.

The real measure of AI value is not whether the organization becomes faster. It is whether the organization becomes better.

LEARN MORE

Leave a comment

Share

The metric that matters isn’t how many lines of code AI can generate. It’s how much software gets successfully delivered, adopted by users, and translated into business outcomes. That distinction is becoming harder to ignore.

A recent MIT-led analysis found that AI tools dramatically increased coding activity. In some environments, file edits nearly tripled after AI coding assistants were introduced. Yet much of that increased activity disappeared as projects moved through testing, review, deployment, and adoption. The researchers found that while coding output surged, software releases increased by only about 30 percent. Even more striking, many of those additional releases failed to generate meaningful user engagement or business value.

In other words, AI is accelerating code production faster than it’s accelerating value creation.

That finding aligns with what our team at SONATAFY has seen across the industry. Many leadership teams are celebrating activity metrics because they’re easy to measure. They track commits, pull requests, story points, and development velocity. AI makes all of those numbers look better. A developer who once produced ten units of output can now produce twenty.

Code Generation is Not the Problem

The problem is that software development has never been a code-generation problem. It’s about problem-definition, prioritization, customer-adoption, and ultimately business-value. Code is only one step in a much larger chain.

Imagine a construction company measuring success by the number of bricks delivered to a job site. If the building is never completed, nobody would call that productive. Yet that’s effectively what many organizations are doing with AI-generated code. The danger is that AI creates an illusion of progress. When executives see development activity rising, they naturally assume more value is being created. The dashboards look impressive. The engineering organization appears more productive. Teams are shipping more artifacts into repositories.

Yet customers don’t buy code. Customers buy solutions. A feature that nobody uses has exactly the same business value whether it required ten lines of code or ten thousand.

That’s why some of the latest research on AI productivity is so important. Another study conducted by the research organization METR found that experienced developers working on familiar codebases actually took longer to complete tasks when using AI coding tools. Even more surprising, developers believed they were becoming more productive when the measured results showed the opposite.

That finding highlights a broader challenge. AI can make work feel faster because it reduces the effort required to generate output. However, software engineering involves much more than generation. Developers still need to review code, validate assumptions, test integrations, resolve edge cases, address security concerns, and maintain the resulting systems. As AI-generated code volumes increase, so does the burden of verification.

Organizations that focus solely on code output risk creating what I call synthetic productivity. Activity rises. Repositories grow. Dashboards improve. Yet the underlying business outcomes remain unchanged. The better question isn’t how much code AI generated. The better question is what value that code created.

The companies that benefit most from AI won’t be the ones generating the most code. They’ll be the ones that become disciplined about connecting software development to measurable outcomes. AI has given us the ability to manufacture code at industrial scale. That’s a remarkable achievement. The challenge now is ensuring we don’t confuse production with progress.

History is filled with examples of organizations that optimized the wrong metric. Factories produced inventory nobody wanted. Sales teams generated leads that never converted. Marketing departments celebrated clicks that never became customers. Software development is facing a similar moment.

Steve Taplin

Leave a comment

WANT TO LEARN MORE? DOWNLOAD YOUR FREE REPORT.

I recently read McKinsey’s latest CEO Playbook for Leading Through Uncertainty, and one idea stood out above the rest. The organizations that thrive over the next decade won’t be those that respond to disruption. They’ll be the ones that reinvent how they operate before disruption forces them to.

Leave a comment

No executive faces that challenge more directly than the Chief Technology Officer.

For years, the CTO playbook was well understood. Build a talented engineering organization. Adopt Agile. Embrace DevOps. Move to the cloud. Automate testing. Accelerate software delivery. Improve developer productivity.

Those practices transformed software development. Now, Artificial intelligence is changing the equation.

AI isn’t another development tool. It is a new participant in the software development lifecycle. It writes code. It recommends architectures. It creates documentation. It generates test cases. It identifies defects. Increasingly, it performs work that only human developers performed a few years ago.

The New Software Risks

AI is creating tremendous opportunities. It’s also creating an entirely new category of software risk.

Much of the current discussion around AI focuses on productivity. Research from GitHub has shown that developers using AI coding assistants complete many programming tasks significantly faster. Organizations everywhere are investing in AI to increase engineering velocity and reduce development costs.

Speed has never been the ultimate measure of software success. Quality is.

The 2025 DORA Accelerate State of DevOps Report delivered an important warning to technology leaders. While AI improved individual developer productivity, higher levels of AI adoption did not consistently improve organizational software delivery performance. In several cases, software stability, delivery performance, and developer satisfaction declined when AI was introduced without corresponding changes to engineering practices.

Artificial intelligence is allowing organizations to generate more code than ever before. At the same time, it introduces risks that traditional software development frameworks were never designed to address.

• AI can hallucinate nonexistent functions

• It can recommend insecure programming patterns

• It can generate inconsistent coding standards across teams

• It can introduce hidden technical debt that developers fail to recognize because they did not write the original code

• It can create intellectual property concerns when developers unknowingly incorporate generated content with uncertain licensing histories

• Most importantly, AI can produce software that appears correct while concealing flaws that become visible only after deployment

Traditional software quality frameworks were built for software created almost entirely by humans. Tomorrow’s software will be built by humans working alongside intelligent machines. That demands a different quality framework.

The New CTO Playbook

The new CTO playbook is no longer about maximizing coding productivity. It is about maximizing confidence in AI-assisted software delivery. That begins with a new AI Software Quality Framework built around six core principles.

1. Human Accountability

Every AI-generated artifact should have an accountable human owner. AI can generate code. Humans remain responsible for approving what enters production.

2. Architecture Integrity

Large language models excel at solving isolated programming problems. They don’t understand long-term enterprise architecture the way experienced software architects do. Every AI contribution should be evaluated within the broader system design rather than accepted in isolation.

3. Continuous Security Validation

Every AI-generated component should undergo automated security scanning, dependency analysis, vulnerability testing, and compliance review before deployment. Security can no longer be a checkpoint at the end of development. It becomes a continuous discipline integrated throughout the software lifecycle.

4. AI Verification

Testing now extends beyond verifying functionality. Teams must validate AI-generated business logic, identify hallucinated code, evaluate model-generated recommendations, and confirm that software behaves consistently across changing AI outputs.

5. Governance and Traceability

Organizations need to know where AI contributed to software development, which models generated the code, who approved it, and how decisions were validated. As regulations evolve, that visibility will become a strategic requirement rather than an operational convenience.

6. Continuous Organizational Learning

Every production defect, security incident, and architectural failure should improve both the engineering organization and its AI workflows. AI systems learn from feedback. Engineering organizations should do the same.

Collectively, these principles redefine the CTO’s role. Tomorrow’s technology leaders will spend less time asking, “How can AI help us write more code?” Instead, they will spend more time asking, “How do we ensure every line of AI-generated code meets the quality, security, reliability, and governance standards our customers expect?”

That’s a different leadership challenge. The next decade won’t belong to the organizations generating the most software. It will belong to the organizations delivering the most trusted software.

The last twenty years gave us Agile, DevOps, and continuous delivery. Those frameworks transformed how humans build software. The next era requires something equally important: a comprehensive AI Software Quality Framework that governs how humans and artificial intelligence build software together.

The CTOs who embrace that challenge today will do more than deploy AI successfully. They will define the new standard for software excellence in the age of artificial intelligence.

Leave a comment

WANT TO LEARN MORE? DOWNLOAD OUR FREE REPORT

Leave a comment

Share

Journalists and researchers soon discovered that the chatbot was providing inaccurate information on a variety of legal and regulatory topics. In some cases, it advised employers they could take actions that appeared to violate labor laws. In others, it offered guidance that conflicted with existing regulations. The chatbot wasn’t intentionally deceptive. It was doing exactly what large language models are designed to do: generate plausible answers based on patterns in data. Plausible and correct are not the same thing.

A Dangerous Assumption

What struck me about this story wasn’t the chatbot’s mistakes. Software systems have always contained bugs and inaccuracies. What caught my attention was how many people assumed the AI’s confidence was evidence of its accuracy.

As organizations rush to integrate AI into software development, we’re creating systems that can generate code, write documentation, produce test cases, recommend architectural decisions, and even suggest security controls. The productivity gains are extraordinary. Tasks that once required hours can now be completed in minutes.

Yet the New York City chatbot illustrates an important lesson: AI can generate an answer long before it can guarantee the answer is correct. That reality sits at the heart of AI risk management.

Speed Creates Its Own Risk

A lot of today’s tech leaders approach AI primarily as a productivity tool. They focus on accelerating development cycles, reducing costs, and increasing engineering output. Those benefits are real, and companies that ignore AI risk falling behind competitors who embrace it.

The challenge is that speed can create its own form of risk.

A developer who writes code manually has time to think through design decisions, edge cases, and potential consequences. When AI generates hundreds of lines of code instantly, that natural pause disappears. The development process becomes faster, but the opportunity for flawed assumptions to enter the system also increases.

At Sonatafy, we’ve reviewed AI-generated code that looked polished and professional while containing security vulnerabilities, inefficient database queries, and subtle logic errors. Nothing appeared obviously wrong. In fact, the code often looked better than what an average developer might write from scratch.

That is precisely what makes the risk so difficult to manage. The issue isn’t poor quality. The issue is misplaced trust.

AI-generated code should be treated as a first draft, not a finished product. Every recommendation should be reviewed. Every architectural suggestion should be challenged. Every security control should be validated independently. AI can accelerate the work, but it cannot replace engineering judgment.

Security is a Significant Concern

Many developers interact with AI systems by sharing code snippets, logs, architecture diagrams, and production issues. In the rush to gain efficiency, organizations sometimes overlook the possibility that sensitive information is being exposed to external systems.

A developer troubleshooting a customer issue may paste confidential data into a chatbot. An engineer may upload proprietary source code to generate recommendations. A product manager may share strategic plans while creating requirements documents.

Each individual action appears harmless. Yet collectively, they can create serious exposure.

That’s why effective AI governance begins with clear rules. Teams need to understand which AI tools are approved, what information can be shared, and how sensitive data should be protected. Organizations that skip this step frequently discover their governance gaps after a problem occurs rather than before.

The Erosion of Expertise

There’s another risk that receives far less attention than it deserves. The gradual erosion of expertise. One reason experienced engineers are valuable is that they understand context. They know why previous decisions were made. They recognize patterns from past failures. They understand tradeoffs that aren’t obvious from documentation alone.

AI doesn’t possess that organizational memory.

As development teams become increasingly dependent on AI-generated solutions, there is a danger that engineers begin accepting recommendations without fully understanding them. Junior developers may receive answers without developing the skills required to evaluate those answers critically. Over time, this can create an organization that becomes highly efficient while becoming less capable.

That may sound contradictory, but it isn’t. Efficiency and capability are not always the same thing.

The organizations that will succeed with AI are not the ones that automate the most tasks. They’re the ones that preserve human judgment while using AI to eliminate repetitive work. They understand that technology should amplify expertise, not replace it.

Managing AI risk ultimately comes down to discipline. It requires strong code reviews, rigorous testing, security validation, clear accountability, and continuous monitoring. These practices were important before AI arrived. They are even more important now.

I also believe leaders need to evaluate both sides of the equation. Most organizations measure the value AI creates. Fewer measure how effectively they are using AI to create that value. Even fewer assess the unintended consequences.

AI can accelerate development, but is it increasing technical debt? AI can reduce costs, but is it weakening institutional knowledge? AI can improve efficiency, but are teams becoming too dependent on automated recommendations?

Those are the questions that matter. Are you ready to answer them?

Leave a comment

WANT TO LEARN MORE? DOWNLOAD OUR FREE REPORT.

Leave a comment

Yet many executives struggled to identify a corresponding increase in completed software products, customer adoption, or business value. One technology executive summarized the situation to me perfectly. “We’re producing more code than ever. I’m not sure we’re producing more software.”

At Sonatafy, we call this the AI Productivity Paradox. Artificial intelligence is dramatically increasing coding activity while delivering far smaller gains in shipped software products.

For years, I’ve seen software leaders have measured productivity through engineering outputs. Lines of code. Story points. Features completed. Development velocity. AI excels at all of those metrics.

Developers can generate boilerplate code in seconds. Documentation can be drafted automatically. Unit tests can be created almost instantly. Entire application components can be scaffolded through natural-language prompts. The result is an explosion of code generation.

Yet software products don’t succeed because code exists. They succeed because customers use them, businesses support them, and organizations can maintain them over time. Those challenges remain largely human. The evidence is beginning to support this distinction.

Productivity Gains?

GitHub’s 2024 Developer Survey found that developers using AI coding tools reported significant gains in productivity and efficiency. Participants said AI helped them complete repetitive tasks faster and reduced time spent searching for information. The survey showed that developers overwhelmingly believed AI was making them more productive. At first glance, that sounds like an unqualified success story.

The Stanford University 2025 AI Index Report painted a more nuanced picture. While AI coding assistants continued to improve software development speed, Stanford researchers noted that organizations were still struggling to translate AI-driven productivity gains into measurable business outcomes. The report highlighted a growing gap between task-level productivity improvements and organization-wide performance gains. In other words, developers were completing coding tasks faster than companies were delivering business value.

The 2025 Microsoft Work Trend Index revealed a similar pattern. Researchers found that employees increasingly relied on AI to accelerate individual work activities. Yet many organizations continued to face bottlenecks involving decision making, collaboration, approval processes, and organizational complexity. Faster execution at the individual level did not automatically eliminate constraints elsewhere in the business.

Writing Code is Only one Stage of Software Delivery

Before a product reaches customers, teams need to gather requirements, align stakeholders, perform testing, address security concerns, manage deployment pipelines, train users, support customers, and continuously improve the product based on feedback. AI helps with some of those activities. But it doesn’t eliminate them.

Research from Atlassian’s 2024 State of Teams report found that software developers spend substantial portions of their week on communication, coordination, planning, meetings, and information gathering. Coding represents only part of the software development process. Accelerating code creation therefore improves only one segment of a much larger workflow.

This helps explain why many companies report impressive AI adoption statistics while struggling to identify dramatic improvements in software delivery.

A 2025 McKinsey Global Survey on AI found that organizations were expanding AI deployments across business functions, yet relatively few had achieved significant enterprise-wide financial impact. Most reported gains remained localized to specific teams or individual workflows rather than transforming overall organizational performance.

That finding shouldn’t surprise us. Businesses don’t buy code. And customers don’t purchase pull requests. They purchase solutions to problems.

Many executives assume that if AI allows developers to generate twice as much code, software products should arrive twice as fast. Reality rarely works that way. That’s because the constraint was never purely technical. The constraint was organizational.

The Metrics That Matter

At Sonatafy, we believe that the companies that benefit most from AI will stop measuring success by the volume of code generated and start measuring outcomes customers actually experience.

Did adoption increase? Did revenue grow? Did deployment cycles shorten? Did customer satisfaction improve? Did business objectives get achieved?

AI is becoming an extraordinary amplifier for software developers. It is reducing friction, accelerating experimentation, and making coding more accessible than ever before. What it hasn’t done is eliminate the hard work of building products people actually want. That remains a human challenge.

The AI Paradox is that we now possess technology capable of generating more software code than any previous generation of developers could imagine. Yet the organizations that win won’t be the ones producing the most code. They’ll be the ones producing the most value.

Leave a comment

WANT TO LEARN MORE? DOWNLOAD OUR FREE REPORT:

After 195+ episodes of the Software Leaders Uncensored podcast and 30 companies of my own, the reasons software projects fail stopped looking random. The same four patterns kept appearing, regardless of industry, team size, or budget. This newsletter exists to name those patterns and show you how to fix them.

Here is the map. Each pattern links to the best place to begin.

1. The Backlog Illusion

The belief that a growing backlog means a working delivery system. Velocity is stable, but impact is not. Features deliver, but nobody uses them. Roadmap resets keep reproducing the same problems. The work is motion mistaken for progress.

Start with this article, THE BACKLOG CRISIS: When Everything is a Priority, Nothing Ships, or go deeper with the free interactive book experience, The Backlog Illusion.

2. The Coordination Tax

You have the right people and still cannot deliver. The cost lives at the seams: handoffs between teams, vendors blaming each other, releases that require five-team alignment, weekly status churn that produces no decisions.

Start with: The late delivery isn’t the problem. It’s the symptom

3. The Ownership Gap

Ask one question of any struggling delivery organization: Who is accountable for the outcome? When the answer is a list of names, the answer is nobody. Missed deadlines and finger-pointing are symptoms. The missing single owner is the cause.

Start with: Why Nobody Owns the Outcome

4. The AI Validation Gap

Teams are delivering AI faster than they can prove it works. No evaluation framewor

k before launch. Hallucinations escaping to production. A board asking whether the AI is working, and no data to answer with.

Start with: AI is changing the entire software development process

The data behind all four

The 2026 Software Delivery Failure Index is the study from which these patterns came: 195 podcast conversations, 48 qualifying failure narratives, and four patterns. Download it free: here.

If your own delivery looks like one of these patterns, I’d start with the diagnostic readout at sonatafy.com/diagnostic-readout.

New issues every week. Subscribe, and you will get the Index in your welcome email.

Leave a comment

Prediction markets force people to reveal what they actually believe. The concept is deceptively simple. Instead of asking someone for an opinion, you ask them to put something on the line. Money, reputation, status, or some other form of skin in the game suddenly changes the nature of the conversation. People stop repeating corporate talking points and start evaluating risks more honestly. They become less concerned with what sounds good and more concerned with what is likely to happen.

The more I think about prediction markets, the more I wonder what would happen if we applied the same concept to software development.

Imagine that every software project inside a company operated like a prediction market. Every executive, product manager, engineer, architect, and stakeholder would have the opportunity to place a wager on the success of a project. The question wouldn’t be whether they hoped the initiative would succeed. It would not be whether they supported the strategy or believed in the vision. The question would be whether they were willing to risk something of value on the project’s outcome.

Would they bet that the software would be delivered on time? Or that it would stay within budget? Or that it would achieve the business objectives promised in the boardroom? I suspect the answers would be revealing.

Imagine a company launching a $10 million software initiative expected to take eighteen months. The project receives executive approval, the timeline is announced, and the organization rallies around the effort. Everything appears healthy from the outside. Then each participant is asked a simple question: Would you personally invest $10,000 on the prediction that this project will launch on time, remain within budget, and deliver its promised business value?

The room would become much quieter.

What makes this thought experiment fascinating is that none of these concerns are necessarily hidden from the people closest to the work. In many organizations, the warning signs are visible months before a project begins to struggle publicly. The people doing the work frequently understand the risks long before executives see them on a dashboard.

A project that should be classified as yellow remains green because nobody wants to trigger concern. A project that should be classified as red remains yellow because leadership hopes the issues will resolve themselves. Eventually reality catches up with the narrative, but by then significant time and money have already been invested.

Prediction markets would expose this disconnect immediately because they force participants to convert opinions into probabilities.

If software development operated this way, organizations would gain access to a remarkably valuable signal. They would see where confidence is genuinely high and where doubts are quietly accumulating. They would discover which projects inspire conviction and which projects survive primarily through organizational momentum.

The irony is that software organizations already possess enormous amounts of information that could support this kind of forecasting. They track deployment frequency, defect rates, cycle times, backlog growth, technical debt, team velocity, production incidents, and delivery performance. Most companies have years of historical data describing how projects actually perform.

They would create a mechanism for aggregating knowledge from the people closest to the work. Rather than relying solely on executive forecasts, companies could measure the collective confidence of the entire organization. Engineers, architects, quality assurance specialists, product managers, and operations teams all possess information that rarely appears in a slide deck. A prediction market would capture that information and convert it into actionable insight.

The most successful engineering organizations already operate with a mindset that resembles this approach.

They constantly update their assumptions as new information emerges. They measure outcomes, evaluate risks, and challenge forecasts when evidence changes. They do not treat deadlines as sacred commitments disconnected from reality. Instead, they treat them as predictions that become more accurate as information improves.

This mindset creates resilience because it encourages learning rather than wishful thinking.

In the end, the value of a prediction market is not that it predicts the future perfectly. No system can do that. Its real value lies in revealing what people already know but have not yet said out loud. It exposes hidden concerns, surfaces collective wisdom, and creates a clearer picture of organizational confidence.

That leads to a question every technology leader should consider. If software development were a prediction market, would you bet on your company’s next major initiative? More importantly, would the engineers building it place the same bet with the same confidence?

Leave a comment

WANT TO LEARN MORE? DOWNLOAD OUR FREE REPORT.

That difference is what the Sonatafy Software Delivery Failure Index is built on.

For the past year, I have been recording Software Leaders Uncensored: unfiltered conversations with CTOs, VPs of Engineering, CIOs, and founders at software organizations from growth-stage through enterprise. The format is built for honesty rather than promotion. Leaders are asked what actually broke, what they would do differently, and what the cost of the lesson was.

The 2026 edition draws from 195 episodes recorded between April 2025 and April 2026. Of those, 48 met the selection criteria for inclusion as qualifying failure narratives: the practitioner named a specific failure, its root cause, and its consequence in enough detail to extract structured insights. Vague difficulty did not count. 41 of the 48 produced publication-grade quote evidence. The remaining 7 informed pattern recognition without clearing the quote bar.

This is not a survey of opinion. It is a structured extraction of failure narratives where a practitioner named the cause, the consequence, and the change.

What surprised me most

I went into this research expecting to find that most software failures were technical. Bad architecture decisions, accumulated technical debt, wrong frameworks chosen at the wrong moment in a company’s growth.

That is not what the data showed.

The three most frequent root cause patterns each appeared in nine qualifying conversations, and none of them were primarily technical. They were structural. Building before validating. Process breakdown under deadline pressure. People scaling without context or accountability.

The finding that stuck with me most: teams that hired the fastest were often the ones struggling hardest with delivery. Adding engineers was not solving the problem. In many cases, the data showed it was making it measurably worse.

That was not what I expected. It is what the leaders told me.

What I got wrong going in

I expected the AI section to be the dominant finding.

It is not. At least not yet.

The AI Validation Gap is real, the incidents-per-customer data is alarming, and the severity per instance puts it at framework status despite a smaller qualifying sample. But the three structural failure patterns have more evidentiary weight in this dataset, and they are also more actionable right now for most organizations.

I also expected recovery to look like a change in talent or tooling. It did not. Across the qualifying conversations, the leaders who turned delivery around almost always made a structural change before a personnel or technology change. They installed ownership. They enforced process discipline. They reframed what delivery meant.

That shift in my own framing shaped how the report is organized.

The dataset at a glance

Recording window: April 18, 2025, to April 24, 2026.

Industries represented: SaaS and vertical software, fintech and insurtech, healthcare technology, real estate and automotive technology, IT services and AI infrastructure, workplace and DevOps tooling.

The primary finding

Teams that added engineers without fixing their delivery model got slower, not faster.

This finding appeared across the dataset with sufficient consistency to anchor the entire report. New hires needed months to ramp. Information dissemination broke down. The collaboration advantages of smaller teams disappeared as organizations scaled from 10 to 100 engineers. The organization chart grew while delivery throughput plateaued or declined.

Adding headcount to a structurally broken delivery model does not yield a better one. It produces a bigger broken one.

Framework distribution across the dataset

The three confirmed frameworks each surfaced across nine independent conversations, producing a combined 31 data insights. The AI Validation Gap earns inclusion not through frequency but through severity per instance, and through the consistency of the signal pattern across multiple sub-types.

The Backlog Illusion

The false signal when backlogs show activity without progress. Tickets close, sprints complete, velocity looks healthy, but the team is not delivering business outcomes.

It appeared in nine qualifying conversations across ten data insights, making it the top-ranked root cause by cumulative severity in the dataset.

The Backlog Illusion manifests when teams build features no one uses, when roadmaps are driven by competitor imitation rather than validated user need, and when engineering is measured by output volume rather than business impact.

The $42M case. Armando Viteri, President and CEO of Neubloc, described in Episode 81 what he called the catastrophic failure of his career: scaling into 20 geographies under the assumption that the model working in the first market would generalize. The assumption was never validated against local market conditions, regulatory differences, or distribution dynamics before the engineering and operational footprint was committed. Capital was available. Market validation was not. As Armando framed it: capital availability is not market validation. The ability to raise money and the ability to build something people need are entirely separate questions.

The 12-month case. Nathan Miller, Founder, President, and CEO of Rentec Direct, described in Episode 165 a different expression of the same pattern. Rentec hired a senior software developer and committed a full year to building an integration with a partner company. The partner had sold them on the platform’s potential. After a year, the integration was launched. No one used it. The partner had not delivered on its claims and was not as popular as it had represented. The cost was a full year of a senior developer’s salary plus the opportunity cost of everything else that developer could have built.

Justin Farris, VP of Product at Read AI, described the emotional cost of this pattern in Episode 151: months of work and energy, products shipped that did not gain adoption, and the organizational toll of resetting the roadmap and starting over.

The recovery move practitioners described consistently: reframe the unit of delivery from “feature shipped” to “outcome validated.” Smaller experiments before commitments. Explicit kill criteria for in-flight work. Product leadership is empowered to stop engineering before the sunk cost grows.

The Coordination Tax

The hidden overhead is created when teams skip alignment. Every rework cycle, handoff, and clarification meeting taxes delivery velocity, and the tax compounds.

It appeared in nine qualifying conversations across eleven data insights. The pattern surfaced most heavily in distributed teams, scaling teams, and teams without effective product-engineering alignment.

Under timeline pressure, the practices that protect delivery quality were the first thing teams sacrificed. Requirements were written after development started. Testing windows were compressed to hit fixed deployment dates. Agile ceremonies persisted in name but lost their substance. The damage rarely surfaced during the sprint, when corners were cut. It surfaced two or three sprints later, as rework.

William Steenbergen, Co-founder and CTO of Federato, described it in Episode 167 as a cascading effect: rushing testing, rushing decisions, and making more mistakes as a result of shortcuts that, individually, seemed minor.

The downstream cost of skipped alignment was consistently reported as larger than the time it would have taken to do the work correctly the first time, but it was paid in a different week, by a different team, in a different ticket. That displacement makes it invisible until the cumulative damage is already significant.

The recovery move was structural, not motivational. Teams that recovered installed a hard contract on the entry of work into the sprint: written specs, definition of ready, signoffs upstream. They protected that contract from the pressure of the timeline. Process discipline was treated as a forcing function, not overhead.

The Ownership Gap

The structural gap between having engineers and having delivery accountability.

Nine qualifying conversations, ten data insights. The clearest predictor of healthy delivery in the dataset was a single named owner per product surface, with headcount added to that ownership structure rather than replacing it.

Jeff DePascale, CTO of CallRevu, described in Episode 36 the experience of believing alignment existed, confirming it verbally, going to sleep, and waking up the next day to discover nothing had actually been understood or acted on.

The headcount trap. An anonymized Director of Engineering at a genomics and health-tech company was promoted from senior engineer but continued operating as an individual contributor, staying deep in the technical weeds on projects that should have been delegated. Simultaneously, the team was hiring new engineers to scale delivery capacity.

The result: eight months of operating as a single point of failure, with the team unable to keep pace with commitments made by sales and leadership. New engineers needed nine to twelve months to reach full domain expertise. More headcount. Less throughput.

This is the Ownership Gap operating at two levels simultaneously. At the leadership level, the director retained execution responsibility instead of building the team’s capacity to own outcomes independently. At the team level, new engineers lacked the domain context needed to move fast.

Recovery looked the same across organizations: a deliberate move from team-of-engineers to team-with-owner. One person is made accountable for the sprint cadence, architectural decisions, and code quality of a defined product surface. Headcount additions came after the ownership structure, not before.

The AI Validation Gap

I want to be direct about what this framework is and is not.

Unlike the first three frameworks, the AI Validation Gap is still emerging in the dataset. The sample size per sub-signal sits at N=1 to N=2, below the report’s publication threshold for confirmed framework status. I am including it because the severity of the incidents and the consistency of the signal across independent sources suggest it deserves immediate attention, not because the frequency warrants the same evidentiary confidence as the first three.

That transparency is part of the research discipline. An emerging pattern observed at low frequency but high severity is not the same as a confirmed pattern. It is a warning signal worth watching closely.

With that context established, the signal is alarming.

Sylvain Kalache, Head of AI Labs at Rootly, stated in Episode 185 that incidents per customer have increased by a factor of three over the last three years. Companies are experiencing three times more outages and more incidents than in 2023. AI-accelerated development velocity is outpacing the tooling and processes teams use to detect and resolve failures.

The AI Validation Gap is clustered into four sub-signals.

The reliability paradox: shipping faster means more changes, more surface area, and more failures arriving at the worst possible moment.

The knowledge transfer problem: AI tools promise to accelerate delivery, but only for teams where knowledge is distributed. When context lives in one person’s head, AI amplifies nothing. The bottleneck is not compute. It is the single engineer who has not yet taught the system, or the team, what they know.

Stakeholder expectations outrunning reality: Matthew Peters, CTO of CAI, described in Episode 125 the persistent organizational pressure to explain why AI has not yet multiplied productivity by a factor of ten. The expectation is real. The delivery capacity is not. The gap between them compounds silently until a missed deadline makes it visible.

Hidden trust and governance debt: In Episode 180, Bradley Friemel, CTO of Fullsteam, described the specific compounding risk of technologists overselling what AI can accomplish in production environments. Overpromising builds governance debt. The gap between what stakeholders expect and what teams can deliver gets hidden by workarounds until delivery exposes it.

The twelve warning signs

Across the 48 qualifying data insights, project failure followed a recognizable lifecycle. Warning signs appeared months before the failure became visible to leadership.

The four stages: quiet drift (cost of correction measured in days), process erosion (weeks), compounding pressure (quarters), and the failure event (cost already paid).

The report includes a twelve-point scorecard. Score each warning sign 0 to 2 based on observed instances in the last 90 days, then sum across all twelve.

The twelve signs: no single named owner per outcome; roadmap reacting to competitor releases rather than user validation; specs written after development started; ramp-up consuming more than three months per hire; deadlines met by cutting testing; velocity declining as headcount grows; AI features shipping without an eval framework; incidents per customer increasing; partner-built features with no adoption signal; unresolved product-engineering-design tension; replatforms running without explicit kill criteria; stakeholder AI expectations exceeding delivery capacity.

Score bands:

0 to 5: structurally sound. Run the scorecard quarterly. 6 to 12: one framework is likely active. Targeted intervention this quarter. 13 to 18: two or more frameworks compounding. Structural change required, not motivational. 19 and above: multiple compounding patterns. Redesign the delivery model before adding capacity.

Run it independently with three or more leaders, then reconcile. A ten-point spread between the highest and lowest score is itself a signal: the leadership team lacks a shared diagnosis.

What high-performing teams do differently

Five structural differentiators appeared consistently across organizations that avoided or recovered from delivery failure. None of them is heroic. All of them are designable.

They treat ownership as architecture, not a hiring outcome. One person, not a committee, is accountable for the outcome of each product surface. The clearest predictor of healthy delivery in the dataset.

They protect the entry of work into the sprint. A hard contract on what enters: written specs, definition of ready, upstream sign-offs. The contract is enforced under timeline pressure, not relaxed.

They measure delivery in terms of outcomes, not outputs. Sprint reports lead with what shipped to production and what changed in the customer or business signal. Ticket velocity is a hygiene metric, not a leadership metric.

They run replatforms and AI features with eval frameworks staged in advance. Major engineering bets are run with explicit success criteria and kill points. AI features have evaluation frameworks before they launch dates.

They surface product-engineering-design tension at a named forum. Standing executive forum where the three disciplines are required to bring unresolved decisions before they become delivery commitments. Soft alignment fails under pressure. Structural alignment does not.

Five things to start. Five things to stop.

Start: score your team against the twelve warning signs with three independent leaders. Name a single accountable owner per outcome before adding headcount. Install a sprint-entry contract and enforce it under deadline pressure. Re-cut the sprint review around outcomes, not tickets. Stage AI evals before AI launch dates.

Stop: adding headcount to a broken delivery structure. Scaling before validating unit economics in the first market. Committing to multi-quarter integrations without kill criteria. Shipping integrations without partner adoption commitments. Accepting boardroom AI projections, you cannot measure against current tooling and team throughput.

If there is one lesson from 195 conversations

Software projects rarely fail because of technology.

They fail because organizations mistake activity for progress, coordination for ownership, and hiring for execution.

The warning signs appear months before the failure becomes visible to leadership. Most teams simply do not know where to look.

The full report

The Sonatafy Software Delivery Failure Index, 2026 Edition, is 25 pages. It includes the full root cause analysis with practitioner quotes, the AI failure mode sub-signal detail, three case studies with dollar-level cost analysis, the twelve-point scorecard, five recovery patterns with time-to-impact estimates, and the full framework-to-delivery-model mapping.

Download it at https://www.sonatafy.com/reports/why-software-projects-fail

If your score is above 12 or if you are already in a late-stage delivery failure, the 60-minute Software Delivery Failure Diagnostic provides a structural read of your delivery model. Book at sonatafy.com/diagnostic-readout.

Steve Taplin is CEO of Sonatafy Technology and host of the Software Leaders Uncensored podcast. He is the author of Fail Hard Win Big and co-author of The Backlog Illusion with Sonatafy CTO Chris Horvat. The Software Delivery Failure Index, 2026 Edition, draws from 195 episodes recorded from April 2025 to April 2026.

Learn more at www.sonatafy.com

Listen at www.softwareleadersuncensored.com.

Contact: info@sonatafy.com

Every time, my response is the same. You are looking at the wrong metric. Output is up, yes. But what happened to your backlog? It did not shrink. It grew. What happened to your integration complexity? It expanded. What happened to the number of systems your team is now responsible for maintaining? It doubled.

They are describing a pattern that we have seen at Sonatafy and which economist William Stanley Jevons identified in 1865, and it is about to reshape how every technology leader thinks about AI, engineering teams, and software delivery.

A 160 Year Old Prediction About Your Engineering Org

Jevons studied coal. In the mid 1800s, Britain was making steam engines dramatically more efficient. The assumption was that better efficiency would reduce coal consumption. Use less coal per unit of work, use less coal overall. Simple.

Jevons argued the opposite. When coal became more efficient to use, it became cheaper per unit of output. When it became cheaper, industries found new uses for it. Factories that could not have justified the cost suddenly could. Applications that did not exist were invented. Total coal consumption did not decline. It exploded. Efficiency did not reduce demand. It unlocked it.

That is exactly what is happening with code in 2026.

AI tools have made it dramatically cheaper to produce software. GitHub Copilot, Claude, GPT, and a growing ecosystem of coding assistants generate boilerplate, write tests, refactor legacy functions, scaffold entire services, and suggest architectural patterns. What used to take a senior engineer a day now takes an afternoon. What used to require a team of three can often be prototyped by one.

The linear conclusion is that companies will need fewer engineers. The Jevons conclusion is that they will need more, because the volume of software being built, deployed, and maintained is about to expand faster than anyone’s headcount plan accounts for.

The Backlog Illusion at Scale

Here is where the pattern becomes visible if you know what to look for.

When the cost of producing software falls, projects that were once too expensive suddenly make sense. Internal tools that lived on a wish list move into active development. Small firms that relied entirely on SaaS subscriptions start commissioning custom integrations. Mid sized enterprises invest in bespoke analytics dashboards they never would have approved two years ago. Local governments experiment with AI driven tools to manage data and services. The barrier to custom software collapses, and with it, the ceiling on demand.

I call this the Backlog Illusion operating at the organizational level. Your engineering team is closing tickets faster than ever. The velocity charts look excellent. But the total surface area of software your company is responsible for is expanding faster than your team’s capacity to secure it, maintain it, govern it, and evolve it. The backlog is not shrinking. It is shapeshifting. What used to be a queue of features is becoming a permanent, expanding obligation of enhancements, compliance updates, integration maintenance, and architectural refactoring.

After 180+ conversations with CTOs on the podcast, I can tell you this is not theoretical. Every engineering leader I talk to is experiencing the same dynamic. They shipped more this quarter than last. And they are more behind than they have ever been. That is the Jevons Paradox in action.

More Code, More Coordination Tax

There is a second order effect that most CEOs miss entirely.

When your team produces more software, you do not just produce more code. You produce more systems. More services. More APIs. More data pipelines. More internal dashboards. More automated workflows. Individually, each one feels manageable. Collectively, they form a sprawling digital nervous system that grows more intricate every quarter.

That complexity carries a cost I call the Coordination Tax. Every new system your team builds creates dependencies. Every dependency creates coordination overhead. Every layer of coordination requires communication, alignment, testing, and handoffs that consume engineering time without producing features. Research consistently shows that each engineer added to a misaligned model increases overhead 15 to 25% while increasing output only 5 to 10%. AI accelerates the input side of that equation (more code, more systems, more surface area) without addressing the coordination side.

The result is that teams feel faster at the individual level and slower at the system level. An engineer can generate a microservice in an afternoon. But integrating that microservice into the existing architecture, securing it, testing it against edge cases, documenting it, and ensuring it does not introduce a regression somewhere else still requires judgment, context, and coordination that AI does not provide.

What Actually Becomes Valuable

This is the part that matters for anyone making hiring, team structure, or investment decisions right now.

Routine syntax level coding is increasingly automated. That is real and it is not reversing. But that does not mean engineers become obsolete. It means their comparative advantage shifts. The most valuable engineers in 2026 are not the fastest code producers. They are the ones who can design resilient distributed systems, evaluate AI generated output for hidden flaws, anticipate scaling bottlenecks before they become production incidents, and govern complex ecosystems without creating bureaucratic drag.

Judgment replaces repetition as the core differentiator. And judgment is the one thing that does not scale through automation.

For business leaders, this carries a specific strategic implication. Treating AI purely as a cost cutting mechanism is a misread of the cycle. Individual productivity gains do not automatically translate into reduced aggregate demand. Efficiency lowers the marginal cost of innovation. When innovation becomes cheaper, organizations attempt more of it. They automate more workflows, deploy more microservices, integrate more data streams, and embed AI into more operational layers. Each initiative increases reliance on software as critical infrastructure. And each one increases the Coordination Tax.

The Constraint That Actually Matters

The real constraint in 2026 is not the ability to generate code. It is the capacity to manage complexity safely and sustainably. Governance frameworks, cybersecurity oversight, architectural discipline, and long term maintainability become the bottleneck. Companies that expand their software footprint without strengthening their systems thinking will experience fragility. Those that anticipate the paradox and invest in architectural rigor will convert efficiency gains into durable advantage.

This is the decision that our team at Sonatafy keeps seeing technology leaders face. You can use AI to produce more software faster. That is the easy part. The hard part is building the delivery system, the ownership model, the review discipline, and the coordination framework that ensures all of that software actually serves the business instead of slowly becoming a liability.

Jevons saw this pattern in coal powered Britain. Efficiency did not reduce consumption. It expanded it into industries and applications that did not previously exist. AI driven coding efficiency is doing the same thing to software. As code becomes cheaper to create, it becomes embedded in more processes, more industries, and more decisions.

The result is not less code. It is more pervasive code. And the companies that understand the difference between producing more software and delivering more value will be the ones that come out ahead.

Steve Taplin is the CEO of Sonatafy Technology, host of the Software Leaders Uncensored podcast (180+ episodes), and author of Fail Hard, Win Big. He writes about the decisions technology leaders actually face at thetechdilemma.com.

WANT TO LEARN MORE?

DOWNLOAD YOUR FREE REPORT

I’ve watched this happen repeatedly across the industry. Engineering organizations grow larger while delivery becomes slower, more chaotic, and less predictable. The issue isn’t usually talent. Most software teams are filled with capable people working hard under difficult conditions. The real problem is that many companies are operating with broken delivery systems. That realization became one of the driving ideas behind Sonatafy Technology.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

From the beginning, Sonatafy was created to help organizations solve software delivery problems at the structural level. Instead of asking, “How many developers do you need?” the focus becomes, “Why isn’t software getting shipped efficiently in the first place?”

That distinction matters because software delivery problems rarely exist in isolation. Missed commitments, expanding backlogs, communication breakdowns, technical debt, poor QA integration, and unclear ownership are usually symptoms of deeper operational issues. Adding more disconnected developers to an unstable system often increases chaos rather than fixing it.

Managed-Delivery PODs are Revolutionizing the Software Industry.

At Sonatafy Technology, PODs are accountable delivery systems that move projects from roadmap to execution with greater alignment and predictability. Instead of isolated contributors working independently, PODs combine engineering, QA, leadership, communication, and delivery oversight into cohesive operational units that own outcomes together. That ownership changes everything.

A POD is a small, complete software delivery unit designed to own and execute a defined scope of work from start to finish. It’s not a team of developers you manage. It’s not a consulting engagement where experts tell you what to do. It’s a fully accountable delivery mechanism that ships working software and transfers ownership back to your organization when the work is done. A POD doesn’t replace your teams. It exists to absorb a defined slice of work, execute it with discipline, and then disappear without leaving dependency behind.

The structure is deliberate. Six to eight people organized around complementary skills, led by someone with skin in the game, aligned to your standards and tools, measured on outcomes instead of activity. Everything about the design is optimized for one thing: shipping working software that solves real problems without creating new ones.

Tightly Aligned Teams With Shared Responsibility

One of the biggest problems inside traditional software organizations is fragmented accountability. Engineering teams operate separately from QA. Product leaders communicate differently than developers. Architecture decisions become disconnected from execution realities. Vendors focus on billable hours while internal leadership focuses on timelines. Eventually, nobody fully owns delivery itself.

Managed-Delivery PODs solve this by creating tightly aligned teams with shared responsibility for execution.

I’ve seen the impact firsthand. Communication improves because teams operate within a consistent structure. Developers gain better business context. QA becomes integrated into the delivery lifecycle instead of functioning as a late-stage checkpoint. Leadership gains clearer visibility into delivery risk before projects spiral out of control.

The result isn’t just faster software delivery. It’s more reliable delivery.

That reliability has become increasingly important as companies face growing pressure around AI adoption and digital transformation. Businesses are deploying software faster than ever, but speed alone creates new challenges. More code introduces more testing requirements, more integration complexity, and more operational risk. Without strong delivery systems, velocity can quickly turn into instability.

Software Development as an Operational Discipline

Sonatafy Technology positions software delivery as an operational discipline, not a staffing exercise. Its delivery framework emphasizes engineering leadership, communication structures, architecture oversight, and measurable execution improvement.

In many ways, Managed-Delivery PODs resemble startup teams operating inside larger enterprises. They are smaller, more adaptable, and capable of moving quickly without the bureaucracy that slows traditional development structures. That flexibility allows organizations to respond faster to changing market demands while maintaining stronger control over quality and execution.

The old outsourcing model revolved around labor cost reduction. The modern delivery model revolves around operational efficiency.

I believe this is why Managed-Delivery PODs will continue reshaping software development over the next decade. Businesses are realizing that software success depends less on the size of the engineering organization and more on whether teams are structured to execute consistently under pressure.

The organizations that solve that problem first will move faster than their competitors, adapt more effectively to AI-driven change, and build software organizations capable of delivering at the speed modern business now demands.

WANT TO LEARN MORE?

Book a 30-Minute Discovery Call.

I used to think being a strong software leader was enough. If you could build scalable systems and ship on time, you were doing your job. That was the standard I held myself to. But that world has shifted, and I’ve had to confront something uncomfortable. Software leadership, on its own, isn’t enough anymore.

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

AI has changed the game in ways we never expected. It doesn’t replace software, but it reshapes what software is. It changes how it’s built, how it behaves, and what users expect from it. And if you’re leading software teams without stepping into AI, you’re already behind, even if everything still looks like it’s working.

The first time I felt this shift was when I saw how quickly expectations moved. Users don’t want static workflows anymore. They expect systems to adapt, predict, and respond in ways that feel almost human. Features that used to take months to design and build can now be prototyped in days with the right AI tools. The gap between what’s possible and what’s delivered has widened, and that gap is where companies win or lose.

As a software leader, I used to focus on architecture, performance, and delivery cadence. Those things still matter, but they don’t define the edge anymore. The edge comes from how intelligently your system behaves. It comes from how well you can integrate models, manage data pipelines, and create feedback loops that improve over time. That’s not a side skill. It’s the core.

Rethinking Leadership

I had to rethink what leadership meant in this context. It’s not about becoming a machine learning expert overnight. It’s about understanding enough to make the right calls. You need to know what problems AI can actually solve and where it creates more risk than value. You need to guide your team through decisions that don’t have clear precedents. That requires a different kind of judgment.

One of the biggest shifts for me was realizing that AI introduces a level of uncertainty that traditional software doesn’t. Code is deterministic. You write it, test it, and expect it to behave the same way every time. AI systems don’t work like that. They’re probabilistic. They evolve based on data. They can drift, degrade, or produce unexpected results. That changes how you think about quality, testing, and accountability.

Asking Different Questions

I had to start asking different questions. Not just “Does it work?” but “How does it behave over time?” Not just “Is it accurate?” but “Is it reliable under pressure?” Not just “Can we build this?” but “Should we?” Those questions don’t always have clean answers, and that’s where leadership shows up.

Another reality I had to face is that AI compresses the distance between ideas and execution. That sounds like a benefit, and it is, but it also creates pressure. When your team can move faster, expectations rise just as quickly. There’s less tolerance for slow iteration cycles. There’s less patience for incremental improvement. You have to rethink how you prioritize, how you scope work, and how you protect your team from chasing every shiny opportunity.

At the same time, AI exposes weaknesses in your organization that were easy to ignore before. Poor data quality becomes a blocker instead of an inconvenience. Fragmented systems become liabilities. Teams that aren’t aligned struggle to take advantage of the speed AI offers. As a leader, you can’t delegate those problems away. You have to confront them head-on.

A Cultural Shift

What surprised me most was how much this shift affected culture. Engineers who were comfortable in a traditional stack suddenly felt uncertain. Some leaned in and experimented. Others hesitated, unsure where they fit. My role wasn’t just to set direction. It was to create an environment where people could learn without fear of falling behind. That meant giving them space to explore while still holding the line on delivery.

I also had to become more opinionated about where AI fits and where it doesn’t. There’s a tendency to apply it everywhere because it’s new and powerful. That’s a mistake. Not every problem needs a model. Sometimes a simple rule-based system’s better. Sometimes the cost and complexity of AI outweigh the benefits. Part of being a leader is knowing when to say no.

Navigating Uncertainty

The leaders who thrive in this environment aren’t the ones who know every detail of every model. They’re the ones who can navigate uncertainty, make informed trade-offs, and guide their teams through a landscape that’s still taking shape. They stay curious. They stay grounded. And they don’t pretend to have all the answers.

I had to let go of the idea that my past experience alone would carry me forward. It gave me a foundation, but not a guarantee. If I want to lead effectively now, I have to evolve. I have to engage with AI not as a trend, but as a fundamental shift in how software’s conceived and delivered.

That’s the reality we’re in. If you’re leading software, you’re already in the AI business, whether you acknowledge it or not. The question isn’t whether you’ll adapt. It’s how quickly you’re willing to do it.

Learn More About Steve >

After 195 episodes of Software Leaders Uncensored, the pattern became impossible to ignore.

DOWNLOAD YOUR FREE REPORT

I have spent the last few years asking the same question to every CTO, VP of Engineering, and technical co-founder who sits down on my podcast: what went wrong?

Not the sanitized version they give at conferences. Not the retrospective that blames “scope creep” or “misaligned stakeholders” and moves on. The real answer. The one that comes out 40 minutes into a conversation when the guest stops performing and starts talking.

After 195 episodes of Software Leaders Uncensored, the pattern became impossible to ignore. Software projects fail in patterns, not accidents. The same structural breakdowns show up whether the company is a 50 person SaaS startup or a 2,000 person healthcare platform. The technology changes. The org chart changes. The failure mechanisms do not.

So we built a research report around it.

What the Report Actually Is

“Why Software Projects Fail” is a structured analysis of 48 qualifying conversations drawn from the full 195 episode archive. Root causes, recovery patterns, and the warning signs that preceded each failure.

Not a vendor survey. Not a recycled stat from the Standish Group. Not a think piece dressed up as research. This is primary qualitative data pulled from practitioners who were in the room when things went sideways, told in their own words (anonymized), and organized around the frameworks we have been developing at Sonatafy for years.

The report maps 48 distinct failure patterns back to five root causes. Every pattern includes frequency data across the qualifying conversations, anonymized examples, and a connection to one of three diagnostic frameworks: the Ownership Gap, the Coordination Tax, or the Backlog Illusion.

It is 25 pages. It is free. And it says things most industry reports are too polished to say.

Why This Exists

The software industry has a research problem. The reports everyone cites are either: (a) self-serving surveys designed to validate the vendor publishing them, (b) academic analyses based on data that is five to ten years old, or (c) recycled versions of the same failure statistics that have been circulating since the 1990s.

None of that helps the VP of Engineering sitting in a planning meeting next Monday trying to explain to the CEO why the last three quarters of delivery performance do not match the headcount investment.

That person needs pattern recognition. They need to see their situation reflected in someone else’s failure story and walk away with language they can use in the room. That is what the podcast produces naturally, one conversation at a time. The report packages 48 of those conversations into something a leader can reference before their next planning cycle.

The Five Root Causes (Preview)

I am not going to reproduce the full framework here. That is what the report is for. But here is the shape of what we found.

The first root cause is structural. Nobody owns the outcome. Product defines requirements. Engineering builds features. DevOps manages deployment. Vendors contribute components. Every function does its job. Nobody is accountable for whether the thing actually ships and works. We call this the Ownership Gap, and it showed up in the majority of qualifying conversations. Not as a footnote. As the primary failure mechanism.

The second is mathematical. Organizations add headcount to fix delivery problems without recognizing that every new engineer increases coordination overhead. Past a certain threshold, the additional communication pathways, meetings, dependency chains, and context switching absorb more capacity than the new hire creates. The Coordination Tax. It is the most expensive invisible line item in every engineering budget, and almost nobody measures it.

The third is psychological. Teams treat a full backlog as evidence of a healthy product organization. It is the opposite. A backlog that grows faster than it ships is a liability pretending to be an asset. The Backlog Illusion. It gives product teams the feeling of progress while the delivery engine falls further behind with every sprint.

Root causes four and five connect to decision architecture and delivery model design. They are in the report.

What Makes This Different

Most failure analysis in our industry focuses on what went wrong. This report also maps recovery patterns. What did the leaders who turned things around actually do? In what sequence? How long did it take? Those answers came out of the same 48 conversations, and they are arguably more valuable than the failure data itself.

The report also includes a warning signs checklist. Eight to ten indicators that a project is heading for structural failure before anyone in the room is willing to say it out loud. Derived from the bottleneck predictions and failure stories across the qualifying conversations. Each one comes with a diagnostic question a leader can ask in their next one on one or planning session.

That is the part I wish existed when I was running my first company into the ground 20 years ago. Not a framework diagram. Not a maturity model. A list of questions that would have told me the truth before the quarterly numbers did.

Who Should Read This

If you lead an engineering organization between 50 and 2,000 people and you have felt the disconnect between investment and output over the past 12 months, this report will give you the vocabulary to describe what is happening and the pattern library to diagnose why.

If you are a CEO or COO trying to understand why your engineering team keeps growing but your release cadence is not improving, this report will show you the structural reasons that “just hire more engineers” has not worked and likely will not work.

If you are a product leader managing a backlog that is three to five sprints deep and wondering why velocity metrics look fine but nothing feels like it is moving, this report will explain the math behind the feeling.

The full 25 page PDF is available now at https://sonatafy.com/reports/why-software-projects-fail#download No follow up spam. Just the research.

This is the first report in a series we are building from the podcast archive. 195 episodes of unfiltered conversation with the people actually making delivery decisions. The dataset is unlike anything else in the industry. We intend to use it.

“We have more developers than ever,” he told me. “So why are we moving slower?”

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

Companies believe their SDLC is slowing down because they don’t have enough engineering capacity. Leadership assumes the answer is adding more developers, more vendors, more standups, more process layers, or now, more AI coding tools.

Yet most of the time, the issue has nothing to do with coding speed.

The hidden reason the SDLC slows down inside growing organizations is operational fragmentation. Teams stop functioning as unified delivery systems and start operating like disconnected departments competing for priorities, approvals, and resources. The slowdown doesn’t happen all at once. It creeps in gradually until software delivery becomes trapped inside its own complexity.

That was exactly what happened to this CEO’s company.

At first glance, the organization looked mature. They had Scrum, sprint planning, Jira dashboards, offshore developers, QA teams, architecture reviews, and layers of engineering management. On paper, everything appeared structured and scalable. Underneath the surface, the entire delivery process was clogged with friction.

Developers were constantly waiting for approvals. Product managers changed priorities mid-sprint because sales escalated customer requests. QA teams operated in separate time zones with limited business context. Engineering leads spent more time in alignment meetings than resolving technical risks. Features bounced between departments like luggage moving through a broken airport conveyor system.

Nobody owned delivery from end to end

That’s the part most organizations fail to understand. Staff augmentation increases labor capacity, but it rarely improves delivery architecture. Adding developers to a fragmented system often magnifies the fragmentation. More people create more dependencies. More dependencies create more communication overhead. More communication overhead creates more meetings, approval layers, and coordination bottlenecks.

Eventually the organization reaches a tipping point where adding engineers actually slows the SDLC down instead of accelerating it.

I’ve seen this happen repeatedly over the last few years. Companies scale engineering headcount aggressively because they believe velocity problems are purely technical. In reality, the issue is usually organizational. The software lifecycle becomes overloaded with context switching, fragmented ownership, and decision-making paralysis.

One engineer works on five unrelated priorities in the same week. A product manager manages twelve competing stakeholder agendas simultaneously. A CTO becomes the escalation point for every blocked decision because nobody else has clear authority. Teams become reactive instead of coordinated.

The result is predictable. Releases slow down even while engineering costs increase.

Managed Delivery PODs

This is one of the biggest reasons we shifted heavily toward Managed Delivery PODS instead of traditional offshore staffing models. I realized years ago that most companies didn’t need more disconnected developers. They needed integrated delivery systems designed around accountability and continuity.

Our POD structure combines U.S.-based principal engineering leadership with nearshore developers, embedded QA, product coordination, and delivery oversight operating as one unified operational unit. Not a collection of freelancers. Not a ticket factory. A dedicated delivery engine where technical leadership, execution, and validation remain tightly connected throughout the SDLC.

That changes the dynamic immediately.

When a principal engineer owns technical direction, decisions happen faster. When QA is embedded from the start instead of added later, defects get caught earlier in the lifecycle. When developers remain inside dedicated pods instead of constantly shifting between competing priorities, context switching decreases and throughput stabilizes.

Most executives underestimate how destructive context switching has become inside modern software organizations. Developers rarely spend entire days building software anymore. They spend enormous amounts of time navigating meetings, clarifying requirements, responding to Slack messages, waiting for approvals, and recovering from shifting priorities.

The fragmentation becomes invisible because companies normalize it.

AI is making the situation even more complicated

A lot of executives believe AI coding tools will solve SDLC inefficiency overnight. What I’m actually seeing is AI accelerating code generation while exposing weaknesses in organizational coordination. Teams are producing code faster, but they aren’t improving validation systems, architectural clarity, or delivery governance at the same pace.

That creates dangerous imbalance inside the development lifecycle. Companies can accelerate commits while slowing releases. They can generate features rapidly while increasing downstream instability. AI speeds up production, but it also punishes organizations with weak operational architecture.

The companies succeeding right now aren’t necessarily the ones with the largest engineering teams or the most AI tools. They’re the organizations reducing friction inside the SDLC itself. They have smaller, highly accountable delivery units. Clear technical ownership. Embedded QA. Faster validation loops. Strong delivery leadership. Less bureaucracy. Fewer handoffs.

That’s the hidden reason so many SDLC environments are slowing down today. The problem usually isn’t engineering talent. It’s organizational design. Until companies fix the fragmentation underneath their delivery process, no amount of staff augmentation, outsourcing, or AI tooling is going to restore velocity.

LEARN MORE ABOUT STEVE TAPLIN >

VISIT MY SUBSTACK FOR FREE ARTICLES, VIDEOS & PODCASTS >>

That’s exactly the threat we’re looking at right now. A new capability shows up, productivity jumps, and everyone gets excited. Code gets written faster. Features move from idea to deployment in record time. Entire workflows that used to take days now take hours. The upside is fantastic. What’s not so great, and far more dangerous, is that most teams haven’t adjusted how they validate what they’re building.

Looking Good is Not the Same as Being Good

In October 2024, a lawsuit was filed against Character.AI and Google, after the death of a fourteen-year-old boy. According to the complaint, the teenager had developed an intense relationship with an AI chatbot. Their conversations were not occasional or superficial. They were frequent, emotional, and deeply personal. Over time, he began expressing despair and suicidal thoughts.

The system responded in the way it was designed to respond. It stayed engaged, maintained tone, and continued the conversation. The lawsuit alleges that instead of challenging the boy’s suicidal tendencies, the chatbot reinforced them. It didn’t escalate the situation. But it also didn’t counter it until the boy eventually took his own life. The lawsuit claims that the AI chatbot didn’t simply fail to help. It became a support system that normalized his thinking at a moment when intervention was critical.

Understanding the Blind Spot

What strikes me about this case is not that the system failed. It’s how it failed. From a product standpoint, the chatbot did what it was designed to do. It engaged the user and produced coherent responses. The problem is that none of those metrics captured what happens under extreme conditions.

That’s the blind spot. The system performed well in normal use and failed in the one scenario that mattered most. That’s not a content problem. It’s a validation problem. No one thought about how the system would behave when a user crossed into a high-risk state. No one built a reliable mechanism to interrupt that behavior. The failure wasn’t in the model’s ability to generate language. The failure was in assuming that plausible output was good enough.

It’s Happening Everywhere

I don’t see this as an isolated incident tied to one product or one company. I see it as an early signal of a broader issue that’s already spreading across software development. AI systems generate code that look correct, sound reasonable, and pass superficial checks. Teams trust those outputs because they’re clean and convincing. The system gets deployed. The real test happens later, under conditions that were never fully validated.

In traditional software, failures tend to be easier to isolate. A bug points back to a specific function or a specific line of code. With AI, behavior emerges from patterns. It’s harder to predict, harder to trace, and far easier to trust. That creates a new kind of risk. The system doesn’t break immediately. It behaves just well enough to get into production. The failure shows up when the stakes are higher and the margin for error evaporates.

Why Validation Falls Short

Most development workflows were never designed for this. We test functionality. We test performance. We run security scans. Those are all necessary, but they’re not sufficient when AI is involved. What we’re missing is validation under stress. We’re not systematically asking how the system behaves when inputs become adversarial, emotional, or unpredictable. We’re not building enough safeguards for scenarios that fall outside the norm.

At the same time, AI is compressing the timeline. What used to be a slow, deliberate process now moves like a rocket. That’s where the imbalance comes in. Output scales instantly. Validation doesn’t. If we don’t change that, we end up deploying systems that are technically sound and operationally fragile.

What Has to Change

The lesson I take from the Character.AI case is not that AI is unsafe. It’s that AI exposes where our processes are weak. If validation is shallow, AI amplifies that weakness. If testing is incomplete, AI pushes more unproven behavior into production. The solution is not to slow everything down. It’s to evolve how we validate.

That starts with identifying high-risk scenarios early. Not as an afterthought, but as part of the design process. It means testing systems under conditions that are uncomfortable and difficult to simulate. It means building guardrails that activate when those conditions appear. In some cases, it means introducing deterministic rules or human intervention points where probabilistic systems should not be left alone.

Between 2024 and 2026, something shifted. AI systems stopped being treated as experimental tools and started being treated as accountable products. The courts are now weighing in. Users are relying on these systems in meaningful ways. The expectation is no longer that the system works most of the time. The expectation is that it behaves responsibly when it matters.

That’s a higher bar, and it should be. Because once these systems are deployed, they don’t operate in controlled environments. They operate in the real world, where edge cases are real and the consequences can be dire.

Learn More About Steve Taplin >