Software Delivery Systems: Fix the Process Before Adding More AI

AI can produce code faster, automate repetitive work, analyze enormous amounts of information, and move development tickets at a pace that would have seemed impossible only a few years ago. Yet faster execution does not automatically create better software delivery systems. In fact, speed can expose weaknesses that organizations previously managed to hide.

That distinction becomes central in the second part of Dana Hetté’s conversation with Rob Broadhead and Michael Meloche on Building Better Developers. The first part explored the organizational cracks that form between roles and how developers can use systems thinking to recognize them. Part two moves from recognition to action: What happens when delivery is already struggling? Where should an organization start? And what role should AI play when the underlying system is not healthy?

Hetté’s answer challenges a common technology reflex: tools do not define the solution. They enable a solution that has already been defined.

About Dana Hetté

Dana Hetté, also known as Blondie Geek, is a fractional operator who works with founders and leadership teams at startups and small product organizations. After earning a degree in computer science, Dana spent roughly seven to eight years as a software engineer before moving toward roles centered on product, operations, and the connection between business strategy and execution.

Dana describes her work as occupying the operator seat: the connective role between what leadership intends and what teams ultimately deliver. Her approach combines the systems-thinking foundation of software engineering with product discovery, organizational operations, and cross-functional communication. Rather than focusing only on what individual teams are doing, she looks for the cracks between roles where context, ownership, and business intent can disappear.

You can learn more about Dana at BlondieGeek.com, connect with Dana Hetté on LinkedIn, or subscribe to her newsletter, Closing the Loop.

Software Delivery Systems Need Diagnosis Before Automation

Consider an organization where code is still shipping, deadlines are still being met occasionally, and every department appears busy. Underneath that activity, however, pipelines are breaking, quality is deteriorating, bugs are increasing, and teams are getting closer to the red line.

Leadership sees the symptoms and understandably wants a solution. Maybe another project-management platform will help. Perhaps a new AI development tool can increase productivity. Maybe another automation will remove the bottleneck.

Hetté argues that this is precisely where organizations need to resist the urge to start with technology.

“Tools are not the solution, they enable a solution that you’ve already defined.” — Dana Hetté

When an organization does not understand why its delivery system is breaking, automating that system can simply make the dysfunction operate faster.

Instead, Hetté returns to something far less glamorous: discovery. She describes getting into the organization, talking to people, observing stand-ups, examining project-management tools, reviewing tickets, and investigating what is actually happening. AI can assist with that process by analyzing meeting transcripts, tickets, sprint information, and other organizational data, but human judgment remains necessary to understand what those signals mean.

The objective is not immediately to fix everything. It is first to define what is actually broken.

Software Delivery Systems Improve When You Find the Real Problem

Hetté points to the classic Five Whys technique as an example of how straightforward the diagnostic process can be. Something is broken. Why? Then ask why again. Continue until the team moves past symptoms and reaches the underlying cause.

This sounds elementary, particularly to developers accustomed to sophisticated debugging tools, observability platforms, AI assistants, and complex architectures. Yet the underlying principle is remarkably similar to debugging software.

A developer encountering an exception does not permanently solve the problem by hiding the error message. The exception is evidence. You trace the execution path until you understand the condition producing it. Organizational problems deserve the same discipline.

Hetté describes the balance as spending much of the effort defining the problem. Once the actual problem is understood, the solution often becomes surprisingly straightforward.

Complicated symptoms do not necessarily require complicated solutions. The complexity may come from not knowing which problem you are actually solving.

This is also why firefighting becomes dangerous when it turns into a permanent operating model. There are legitimate emergencies where a team has to use what Hetté calls “duct tape and chewing gum” to cross the finish line. Production needs to be restored. A deadline cannot move. A customer needs an immediate resolution.

The distinction is whether the organization recognizes that temporary stabilization is not the same as solving the underlying problem.

Align Software Delivery Systems Around Trade-Offs

Even after identifying a problem, teams can struggle because leadership and engineering are optimizing for different outcomes. Engineering may want time to improve quality. Leadership may be focused on speed to market. Finance may be focused on cost. Product may be trying to protect scope.

None of those priorities automatically makes one group wrong. The organization needs to decide what matters most.

Hetté uses what she calls project sliders during discovery. The idea involves familiar project constraints such as speed, quality, and cost. Leadership needs to determine where those sliders sit rather than pretending every priority can simultaneously be maximized.

A company may say it needs to reach the market tomorrow while spending as little as possible. The next question becomes unavoidable: What is the organization willing to compromise—quality, scope, consistency, or time?

Many disagreements that appear technical are actually disagreements about priorities that were never explicitly decided.

Those decisions provide developers with something extremely valuable: guardrails.

Hetté shares an example involving an engineer who wanted an increasingly agentic workflow. Instead of manually associating work, the engineer wanted one agent to determine what another agent was doing. Hetté suggested a dramatically simpler solution: put the ticket number in the pull request. The engineer could even have an agent perform that step.

The exchange highlights an important distinction between technological possibility and operational value. An organization does not need to automate something merely because it can.

Once leadership has established its priorities, those principles can become the North Star for deciding which practices are worthwhile.

AI Needs Human Inspection Points

The role of human judgment becomes particularly important when AI enters development workflows.

In Part One, Hetté described developers using AI agents to move rapidly through tickets only to discover during user acceptance testing that the output did not match what was actually needed. Part Two reinforces why those failures matter.

AI dramatically increases the amount of work a developer can produce. However, increasing output also increases the consequences of an incorrect assumption. A misunderstanding that once produced one incorrect implementation might now propagate across specifications, tickets, code, tests, and documentation before anyone notices.

The answer is not necessarily a large new governance process. Sometimes it is simply a sanity check.

An AI agent turns raw requirements into a specification. Before the next agent begins producing code, someone reads the specification and asks: Is this actually what we need?

That lightweight inspection can prevent an incorrect assumption from accelerating through the entire delivery pipeline.

Find one AI-assisted handoff in your development process and introduce a deliberate verification point. Do not merely ask whether the AI completed the task. Ask whether its output still matches the original intent.

Human-in-the-loop development should not mean manually redoing everything AI produces. That would eliminate much of AI’s value. Instead, human judgment should be strategically positioned where errors become increasingly expensive if they continue downstream.

Software Delivery Systems Need Ownership

There is another problem that neither AI nor better tooling automatically resolves: ownership.

As organizations grow, a single operator cannot personally inspect every handoff. If that person attempts to do so, the individual who was supposed to eliminate bottlenecks becomes one.

Hetté discusses solving this through mentorship and delegation. In one engagement, she entered knowing from the beginning that part of her responsibility would be finding and developing her eventual replacement. Rather than building an organization permanently dependent upon her, she worked with a more junior person and transferred the systems-thinking and operational mindset needed to continue the work.

That approach provides an important lesson for technical leaders: good systems should reduce dependency on specific individuals.

This is familiar territory for developers. We know the danger of a critical application understood by only one engineer. We recognize the bus-factor problem in software. Yet organizations can accidentally create exactly the same dependency in operations.

The answer is to transfer judgment, context, and ownership.

Hetté argues that systems thinking, product-oriented thinking, and operational judgment can be taught. Instead of requiring one senior person to own every organizational seam, leaders can develop others who learn how to recognize gaps and take responsibility for them.

AI Changes What Makes Developers Valuable

The conversation ultimately moves from organizational systems back to the developer’s career.

Michael Meloche raises a significant concern: If AI increasingly performs junior-level coding work, how do junior developers acquire the experience necessary to become senior developers?

Hetté compares the current transition to earlier abstractions in programming. Developers who worked closer to the machine once worried about newer generations who did not understand the same low-level concerns. She uses the transition from languages such as C++ to Java as an example. Developers could work at a higher abstraction level because the language handled concerns that previously required more direct attention.

AI may represent another, significantly larger abstraction.

Future developers may write less code manually while becoming increasingly skilled at managing AI systems that produce it. Hetté sees the possibility of an AI product builder role that blends characteristics traditionally associated with engineering and product management.

The valuable capability then becomes judgment.

Can you determine whether the generated solution makes sense? Can you understand what the business is trying to accomplish? Can you recognize when an agent has produced something technically plausible but strategically wrong?

These questions point directly back to systems thinking. Knowing syntax matters less when a machine can generate syntax. Understanding consequences becomes more important when a machine can generate enormous amounts of implementation.

Start With One Seam

Hetté closes the extended conversation with a particularly useful challenge for developers who want to move beyond their existing role.

First, adopt an ownership mindset.

Many employees naturally stay within their lane. They complete their assigned responsibilities and leave adjacent problems to whoever supposedly owns them. That approach can be perfectly functional, but it does not develop the perspective required for an operator or broader leadership role.

Hetté describes the alternative as approaching the work with a sense that “the buck stops with me and I own this thing.” That does not mean becoming controlling or assuming responsibility for the entire company. It means becoming interested in whether the overall outcome succeeds rather than only whether your assigned portion is complete.

Then make the exercise manageable.

“Pick one handoff point, pick one seam.” — Dana Hetté

Perhaps it is the transition from requirements to specifications. Maybe it is specifications to tickets, tickets to pull requests, or pull requests to testing. If AI generates code, compare what was produced against the original specification.

Do not attempt to redesign the entire organization. Investigate one boundary.

As Rob Broadhead notes during the discussion, unclear ownership is frequently where the cracks appear. Ask who owns a particular handoff. If everyone starts looking around the room waiting for someone else to answer, you may have found the gap.

Conclusion: Better Tools Require Better Systems

The future of software development will almost certainly involve more AI, more agents, and greater automation. That makes strong software delivery systems more important, not less.

When execution becomes cheap and fast, mistakes can become cheap and fast too.

The organizations that benefit most from AI will therefore not necessarily be those using the largest number of agents or adopting every new development tool. They will be the organizations that understand what they are trying to accomplish, define ownership clearly, establish meaningful guardrails, and know where human judgment creates the most value.

For developers, this creates an opportunity that goes well beyond learning another AI tool. Learn to diagnose systems. Learn to recognize trade-offs. Learn to see the seams between people, processes, software, and strategy.

When you want to start, follow Hetté’s advice: pick one handoff and find out whether it actually works.

Stay Connected: Join the Developreneur Community

👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.

Additional Resources

• Handling Software Delivery Panic: Strategies for Developers
• Software Delivery Clarity: Why Visibility Beats More Process
• Hero Culture Risks: Why AI Is Exposing the Cracks in Software Delivery
• Building Better Developers Podcast Videos – With Bonus Content