Scott Prugh

My name is Scott Prugh. I'm a CTO at ACI Worldwide for the biller platform. I've been in that job about 90 days, so I'm learning a ton. I've also been fortunate enough to be involved in this community now for about 10 years. I think the first time I presented was 2014. I think I missed presenting last year, but I think I've presented maybe 12 or 13 times, whether virtually or here in person.

I want to thank Gene and the team for the opportunity. The learning that has happened here has been amazing. And of course I want to thank ACI, and I see a lot of my friends from CSG and U-Turn and the other community folks, and I want to thank all of you too.

I'm going to talk today about coordination costs and rewiring organizations and winning with AI. I've spent a lot of time over the last couple years with coordination costs, and I've been thinking about how we apply that to what AI is bringing us, and how we supercharge what we learned in DevOps. I like to keep things current, although AI changes so quickly that even in 30 minutes you're out of date, and integrate things that we heard this week, both with vibe coding and, of course, with a lot of this based on the work in Wiring the Winning Organization.

There are two streams I think of with AI and software engineering. One is AI product engineering, and that's putting AI into your products. That's very important. A lot of people want that, whether it's chat, machine learning, or AI-augmented software. But I like to talk first about what I call AI process engineering, which is being ambitious about using AI to rewire your processes and your organization's processes to make how you build software more efficient. That's really what this talk is about.

Start with the problems. What do we see continuously? Teams struggle to make progress. Escalations are required to get anything done: send an email, call someone, Slack them, and do that all the time. You have to rework a lot. Folks have a lot of meetings. You call a meeting, then another meeting, then a third or fourth meeting, and those meetings are trying to force coordination and understanding between individuals.

Then you also inject project managers. When you need to do more and more coordination in these organizations, you add more and more project managers. We have seen places where you have more project managers than developers, and that indicates that you have something wrong. Your investment is going into folks doing the coordination instead of folks doing the work.

And then, of course, what we're hearing today from executives is: can we just smear AI on all this stuff and make these problems go away? It's not that easy. Everyone is getting pulled into that conversation right now. Executive teams and boards are saying, how are you using AI to make things better, and how will it solve everything?

The journey I take folks through is first to talk about the physics and coordination costs, and the golden rule we need to continue to think about with dependencies. Then the three layers and how you rewire organizations. We'll recap how DevOps solved some of these problems with very similar models. Then we'll apply AI to reduce those coordination costs. I have a couple of examples around AI process engineering and the AI enablement properties. These are real examples from real-world cases. They are not as ambitious as Steve Yegge's examples, but they are pragmatic examples of how you can start using AI to improve your processes. Finally, we'll close out with AI silver bullets and cultural change.

This is everything you need to know about the physics of work on one slide. There is more, but this is a pretty good start. There are three formulas. The first came from The Phoenix Project: wait time equals percent busy over percent idle. Very simply, the busier people get, the slower work comes out. If people are 90% busy, the work you expect to get out is going to take nine times as long, because 90 over 10 is nine. That's why we don't like to drive people's WIP up really high.

The next is coordination risk, which degrades at one over two to the N. This is about your odds of arriving on time. Every time you add a handoff, your odds go down that you'll actually arrive on time. Try to get four couples to dinner at the exact same time and the odds of that happening are relatively low. That's what happens in work and organizations.

The next is knowledge loss, which is how knowledge degrades. Very simply, this is the telephone game. As you hand information from one person to another, you lose tacit knowledge. It makes it harder and harder to understand what the initial ask was.

These costs incur in organizations. You get things like contention, coupling, and the need to reach a state of coherence. You're fighting all these things in organizations, and it makes it unlikely that you arrive on time with quality. You might arrive on time but with poor quality, or you might arrive really late and miss your deadline.

The golden rule I push to people is: when you see a dependency, ask, how can I remove it? Tickets create dependencies. People say, put a ticket in, but that's now a dependency for someone else to close that ticket for you. How do you remove that ticket? How do you make it self-service? Those are the things we want to do to improve our odds of arriving on time.

With rewiring organizations, the next thing is the three layers from Gene and Steve's book Wiring the Winning Organization. The first layer is the technical object, or the workers: the code, developers, architects, testers, the folks at the lowest level doing the work. Layer two is the tools: IDEs, version control, work tracking tools, even AI tools. Layer three is the organizational architecture, the norms, how information flows, the processes, and how teams behave. You really need to think about how you affect layer three to get the returns in improving organizations.

This is a value-stream flow analysis of a software development process. Some folks in the room might recognize it because it's real data, although the AI use case here is elaborated on what we originally found. We originally found this value-stream flow and made process improvements to greatly improve the 281 days it was taking to get features to market.

We have it overlaid on the three layers. The lowest layer is the developer. The developer is writing code and doing their job at their desktop. We look at this and ask how we could improve it. We find that developers spend maybe half their time, and that's generous, in the IDE. Of the 65 days of development time, they spend around 32 days coding. That's 12% of the total lead time.

Executive management says it takes so long to get things done, the developers are slow, so let's add AI to these processes and make things better. But if we make developers faster and more efficient, what's the best result we can hope for? We give them great tools: Copilot, Claude, we buy all of them because more tools are better. The best we can hope is maybe those tools improve 50%, and we know that's generous too. You're probably getting more like 20% to 30% improvement at the developer desktop level from these AI tools. If you do that, you get about 16 days total lead-time improvement. That 16-day improvement represents 6% in the total workflow time.

Copilot might help and you should give it to people, but it's not going to save you from this problem and make the dramatic improvements you would like, because this is a misattribution of a system problem. You're trying to fix the problem in the wrong place. It is useful to give folks those tools, but it's not going to help the overall issues. AI can improve individual effectiveness, so get the tools to your people, but alone it's not going to rewire your org. You need to apply systems thinking to your org and processes to get the returns.

Daniel Brock had a good quote: AI can annihilate the coordination costs between devs and the rest of your org, but now you have to rethink how your processes are going to address that overall system problem.

How did DevOps deal with it? DevOps did a couple things. It had technical practices, which made things highly reliable and move faster. It addressed work practices by making things visible and putting measurement in place. It had the concept of platform engineering and enablement, where you made self-service available to lots of teams, gave them consistency in how they approach problems, and lowered cognitive load. You also addressed team structure by creating cross-functional teams, which created flow, knowledge-flow efficiency, and modularity at the team level. All these things lowered coordination costs in the organization and allowed folks to go faster.

In traditional org structures, you are often siloed by different functions. You might have product management, design, development, test, and operations. They are either formally different orgs or formally different roles that hand off the work. What we did in DevOps is collapse those people together on teams and create modularity. That gave us flow and knowledge efficiency. The technical practices, work practices, platform enablement, and team structure affected more than just layer one and two; they affected layer three, how everything flows. This supercharged things with DevOps, and we can learn from that as we go forward.

Before I get into that, I want to go back to technical practices. This is what I call don't put the AI cart before the CI horse. Remember that integrating AI is software engineering. It was really hard to get ChatGPT to draw this because it hasn't seen many horses pointed the wrong way at carts. It took a lot of prompting to get it right.

To be great at integrating AI into your processes, you need to be great at DevOps and CI also. That ends up being your safety net. If you're going to go faster, AI magnifies the strengths of high-performing orgs and the dysfunctions of low-performing orgs. This was a recent finding in the DORA 2025 report. Don't forget these things are important. We're seeing organizations say they'll just buy the AI tools, but if you don't have automated testing, you're going to generate a lot of code that you have no way to prove the quality on. You need to fix and address those things.

AI process engineering starts from the fact that the flow and speed of work in organizations is dominated by wait time and coordination costs. These costs occur when you wait on others for their capabilities, for specialists, for knowledge, or for a task you need them to do. With AI process engineering, the question is how you use AI to rewire the org to reduce those costs. That can have outsized benefit. That's how you get 10x, 100x, or more returns in lead time and quality in the things you develop and build.

Here is an update to the AI enablement properties. I gave the first version of this back in March virtually. There are five, and they relate closely to the FFAAO ideas from vibe coding. All of these make things faster, make it fun, allow you to be ambitious, allow you to act alone or autonomously, and open up optionality.

The first is knowledge. This is the original AI use case. It can improve how you assimilate knowledge, synthesize it, reason with it, and make it available to other people. The next is capability. I'm not good at some things. I'm not very good at Terraform or React development. I'm really good at backend development and database development, but AI can bring me those capabilities so I don't have to go to someone else.

Capacity is simple: AI types way faster than you. It can do a variety of things way faster than you can. It enables parallelism. It can be in multiple places at once. Humans are very bad at multitasking. Once you codify knowledge, multiple people can go after it, leverage it, and do things in parallel. The final property is optionality. It lowers the cost of exploring opportunities to a level where it becomes feasible to build things, throw them away, and take the best option.

When we get into rewiring, the question is how to apply those enablement properties and address layer three at the organizational level to improve overall flow. We're rewiring the processes in the org, and addressing organizational architecture, system architecture, and process architecture.

The first example is a real one from a services domain, where you're collecting requirements from customers to execute a project. In this case it's a cloud migration. Collecting requirements and doing the subsequent analysis is very time consuming, can be inaccurate because people describe things in different ways, and requires handoffs from multiple folks across the organization.

What we do is use transcription. Every requirements call goes into transcription. We take all the documents, notes, contracts, and all the things people are generally reading and feeding back and forth, and push those into AI. Then we prompt it: pretend you're a cloud migration expert. Create a summary for a compelling presentation that highlights the current state, risks, problems, future state, suggested approach, business justification, timeline, and approximate cost for migrating to public cloud. Provide a summary of data-center renewal dates, because those are a risk. Provide a summary of the DR and backup issues. Generate a document from this conversation that outlines a compelling presentation to give to the client.

I get 18 pages of summarized notes from hundreds of pages of transcriptions and other material, summarized cleanly for me. Then I can create the presentation from that documentation. These things would have taken weeks of rereading documents, reading people's notes, and holding meetings. Now I can leverage AI to make this significantly better.

Before, the client worked with a solution group, then with engineering and architects, and they went back and forth. Now we put AI in there, and AI acts as the intermediary between the client, the solution architects, and engineering. We can significantly affect lead time. We drop lead time on something like this from 10 weeks to two weeks.

It cleans up many messy conversations. Yes, AI is non-deterministic, but humans are really non-deterministic also. They use different vocabulary for the same things. You spend a lot of time normalizing conversations with people to understand what they're talking about. Some people talk about RTO but mean RPO and don't even understand it. AI does a great job at that. The information codified via RAG is available to everyone, so everyone can ask it questions. I don't have to go to a person and have a meeting and ask what they learned from the client. It goes into reusable RAG and enables independence of action. I decouple the time and places for people to be so they can leverage the AI. It's a simple use case but a powerful example of how you remove dependencies from traditional roles and use AI there.

The next example is legacy system analysis. A lot of researchers found that AI is a great enabler for onboarding, and that we can cut onboarding time in half by leveraging AI. This is a great example because AI is really good at reading code. It loves code, database schemas, APIs, wikis, and documentation. We need to do new integrations and understand what a system someone wrote 20 years ago does. Traditional approaches require heavy coordination costs with key stakeholders, maybe engineers who built the thing many years ago and haven't looked at it, or engineers who are no longer there. People have to look at a lot of code to analyze this.

Can we leverage AI? We give it code and ask it to analyze the code and draw a Mermaid diagram of the API calls, and tell me how those API calls make it to the database. Out comes a Mermaid diagram showing this API goes to this code path and calls the database. Now I understand what that API is trying to do. Next, create a table for analysis with each function name and the database call, with these columns, and dump it out. Now I can create a pivot table and see all the APIs and database calls. Next, generate a professional report. I need to give a readout to executives, tell them what I learned, analyze these APIs, functionality, database calls, lines of code, and all that. Now I can present what the system looks like and what it does.

This has dramatic improvements. The knowledge assimilation of reading the code is a huge return. It gives me the capability of understanding systems. I didn't even have to read the code. It might have been in a language I've never seen before. It codifies all that and makes it accessible to other people. It cleans up messy conversations where multiple architects describe things in different ways. The code analysis is vastly superior. This Claude analysis dropped the work from about 50 hours down to five, a 10x improvement.

The final example is the prototypical optionality example. It seems incredibly dated when we hear what Steve Yegge is doing and his agents are generating a hundred different solutions, but this is a real one. Building solutions and proofs of concept is costly in time and money. The traditional approach requires coordination of many stakeholders. Topo gave an example where he got a quote for six months of work, and in a week or so he produced a fully functional solution. That's amazing, and that's the type of results you can get.

Here, this was Cursor using Claude on the back end. You give it schemas, the integrations you need, OpenAPI, a sample database schema of your current system, and API documentation for three systems to integrate with. In this case it was Twilio to send SMS, SendGrid for email, and payment systems. Generate me a C# solution that maps the orders in the schema and sends customer notifications via email and SMS. Add a set of tests and mock those integrations for me. Writing mock tests for hundreds of APIs takes weeks and is mind-numbing. Those things used to be miserable, and now it's fun: generate me all those tests and take care of that.

Then generate me a Dockerfile and OpenTofu and configure the solution on ECS. I'm terrible at Terraform, and this makes it enjoyable. You don't do all the good stuff and then have to write all the infrastructure code to get the thing working. This is the prototypical example. It took something people thought would take 12 weeks just to do a proof of concept and brought it down to two weeks.

The things to remember are that AI loves code and types way faster than you. The idea-code-test-deploy loop gets greatly collapsed. DevOps gave us modularity at the team level with different capabilities. Now we're using AI to give us modularity and enclose all those capabilities with the person and the AI that solves the problem. In this case it can be done with one person, and the AI takes on the roles of developer, tester, and deployment operations expert. That's why everything collapses so much: I can iterate quickly and I don't have to coordinate with other folks.

Getting into the summary: the silver bullet, warnings, benefits, and snake oil. This happens with everything. It happened with Agile and DevOps: people say we won't need developers anymore, or ops folks, or whoever. We have to take real caution with that. It's not practical. We still need talented people. The next thing would be saying we don't need people who think, and that's not where we're headed. AI will dramatically change organizations, but it's not going to get rid of all developers.

Giving AI to developers is not a silver bullet to productivity. We have to look at all these other things, but we have to understand the power. AI makes experts dramatically stronger. Technical maestros and architects get boosted. People great at AI are going to do substantially better in the job wars than folks who aren't. It loves code and types way faster than you. We need to move quickly from chat-oriented programming, which these examples were about, to agents. To quote Steve Yegge, you need to have the IDE talk with folks and ask how you're moving to agent programming using CLIs and agents to build your systems.

But don't remove your critical thinking. You still need to be deeply involved. You still need to review code and understand what AI is doing for you. You are still responsible for its output. It moves cognitive load in weird ways. Steve said, now I'm doing 10 things at once and waiting for the agents to produce results. Cognitive load moves into a different space. The great advances lie in augmenting our current folks versus replacement.

To tackle coordination cost, you need to change you and your org to embrace AI. I always ask my folks: what did you do with AI today? How did you use it to solve a problem? Are you using it in Excel to generate reports and formulas? You need to be comfortable with how you work with AI. It's a partner.

The physics of coordination costs degrades exponentially. The golden rule is: remove a dependency, it doubles your odds. AI process engineering should come before AI product engineering. Rewire layer two and layer three of your organizations to embrace AI because AI enables independence of action. Don't shortcut CI. All the things we learned in DevOps for AI are the good foundations and safety net to reduce risk. Battle your coordination costs with the five AI enablement properties: knowledge, capability, capacity, parallelism, and optionality. Those tie back to fast, fun, ambitious, autonomous, and optionality in vibe coding.

The help I'm looking for is what everyone is struggling with: what does the new AI and agentic org structure look like? Is it a team of one technical expert, one business expert, and a BA? What is a higher-level org structure? Do you have very technical managers managing very small pods? These are things we're all struggling with now. We know AI will dramatically affect that. We also know we have to figure out how we continue to have juniors and train them, because at some point those seniors need someone to help them. This is the organizational challenge that a lot of us need to figure out. Thank you all.