The Business Applications Team Is About to Change

AI development tools are changing the old division between the people who understand a business problem and the people who build the solution. This week, I compare that shift with the changing relationship between product managers and engineers, explain the blended delivery lead, and follow one employee onboarding workflow across several company systems. I also cover workplace recording, how companies are choosing between cheaper and more capable AI models, the voice ElevenLabs created for actor Eric Dane, and my reaction to the book and movie versions of Remarkably Bright Creatures.

Read the full issue: https://quanta-bits-newsletter.beehiiv.com/p/quanta-bits-july-18-2026
Subscribe to Quanta Bits: https://quanta-bits-newsletter.beehiiv.com/subscribe

Transcript

SPEAKER_00 0:02

If you have ever tried to improve employee onboarding inside a large company, you know how quickly one reasonable request can turn into a tour of the technology organization. HR owns the process, the HR applications team knows the employee system. Identity handles access. Another team owns training. Service management owns the tickets. Payroll has its own rules and systems. Everybody may be doing their job well and the new employee can still spend the first week waiting for access. The person who understands the problem is often separated from the person who can build the answer. Then the work moves through several cues before anybody owns the whole result. Hey, I'm Reza Mercabadi. Welcome back to QuantaBits. This week I want to talk about what happens when AI tools let people build software faster, what that changes inside business applications team, and a role I think company technology leaders should start testing. By business applications, I mean the internal systems that run HR, sales, finance, and support such as Workday, Salesforce, and SAP. This started with something Aaron Levy, the CEO of Box, posted after meeting with a couple dozen corporate technology leaders. Box helps businesses store and manage documents. They were discussing AI agents, software that can act across company systems instead of only answering questions. His point was that agents work best when tied to a real business process, but these processes do not stay inside the technology organization's need boundaries. Onboarding crosses HR, account access, training, equipment, and support. Levy also said that people who know how to put agents to work inside companies are hard to find. I think the shortage is not only people who understand AI, it is people who understand the business process and can build across it. I've spent a lot of my career around business applications and technology organizations. The basic delivery model is familiar. An analyst talks with sales, HR, Finance, or another business team. They understand the request, document the requirements, and send the work to a developer who knows Salesforce Workday, SAP, or whichever application is involved. That arrangement made sense when software took significant time and specialized skill to produce. Many requests also lived inside one application. A change to a sales screen could stay with the Salesforce team. The model becomes harder when the request is about a workflow, the full chain of work from beginning to end. Employee onboarding does not belong to one application, neither does resolving a customer issue. The organization is designed around the applications while the business problem cuts across them. Every handoff adds waiting time, it also creates a natural temptation for each team to solve the part it owns and declare its piece complete. There is a comparison from software companies that makes this easier to see. Product managers have traditionally spent their time with customers. They decide which problems matter, set priorities, and explain what needs to be built. Software engineers make the technical decisions and turn those ideas into a working product. That division made sense when writing software took most of the time. AI coding tools can now produce, test, and revise code much faster. Product managers do not become engineers, and engineering expertise is still essential. But engineers can spend more time deciding what deserves to be built, while some product managers can build the working version instead of only writing requirements. Business application teams are heading toward the same change. The analyst knows the workflow, the developer knows the system. As building gets faster, the line between understanding the problem and producing the solution starts to move. Coding agents help write and test software. Combined with reusable components and improved APIs, the controlled connections between company systems, they let one capable person build much more than a few years ago. I want to be careful here, connecting systems managing access, security, testing, adoption, and support still take real work. A prototype that looks good on a laptop is not ready to be trusted in daily work. Some analysts can learn to use these AI development tools well enough to build and ship smaller applications themselves. Some developers can work much closer to a business team and take on more of the judgment that used to sit with an analyst or product manager. I call this a blended delivery lead. This person knows a business area and can actually build. They know when fixed automation rules are enough, when AI should help, and when an agent needs to take action. They also bring in specialists for security, scale, account access, or a difficult system connection. Most importantly, they stay with the problem until the workflow works. Go back to employee onboarding. An HR-aligned delivery lead would start with the result. How long does access take? How many setup errors and support tickets does each new hire create? Where do people wait? HR still owns the process goal and policies. The access team still sets access standards. Application and data owners still decide what can be read or changed. The delivery lead uses these approved services to build across the workflow. They can connect the new hire record to account access, training, equipment, and support tickets. They can also build a simple place where HR can see what is complete and what is stuck. If something crosses a security or technical boundary, they bring in specialists who owns it. The difference is continuity. One person remains close to HR and accountable for the complete flow. Success is whether onboarding improves, not whether every technical team closes its ticket. Essentially, that person that is close to HR doesn't just do requirements, but they also help build the workflow across the systems to the extent that they can and only go and access other people and bring them in if it becomes way too complicated. It should improve speed and the way that organizations can experiment and pilot the ideas and even push them to production without waiting for long cues and traditional boundaries to come through. I will keep these rules inside the company technology organization under the chief information officer. They need the same rules for security, testing, release, and support, plus access to specialist and shared technical services. Otherwise, each business unit may create its own fragile applications with unclear ownership. At the same time, the delivery lead has to be close enough to the business to understand the roadmap, the people doing the work, and the trade-offs. An HR-aligned lead should understand employee operations, a sales aligned lead should know how pipeline reviews work, a marketing aligned lead should understand campaigns and lead routing. The business owns the outcome, and the deliberate lead owns getting a working solution into use. Teams responsible for security, data, account access, and shared technical systems provide the boundaries and help around that work. I would not start with a reorganization. Pick one business area, one meaningful workflow, and one person who already has some of the right instincts. Give them approved development tools, access to the relevant system connections and company knowledge, clear authority over what they can change and specialists help when they need it. Record the current result before they start. How long does the work take now? Where are the delays? What errors or support costs does it create? Then see whether the new model changes those outcomes. The talent question matters too. Some analysts will want to learn the AI development tools well enough to ship real applications. Some developers will want to learn a business area well enough to make product decisions. Companies will still need deep specialists. Amazon Cloud Business AWS recently announced a billion-dollar group that will put AI engineers directly inside customer teams. I would not copy that vendor model directly, but the instinct is right. Move people who can build closer to the people living with the problem. He can learn a lot before changing anybody's title or redrawing the organization. Three other stories from the newsletter are worth a quick look. The Wall Street Journal reported that workplace transcription is moving beyond scheduled video calls. Phones, variables, and apps can now capture office conversations and conferences. Better recall is useful, but companies need rules for consent, ownership, access, and deletion before searchable company memory becomes the default. The Financial Times reported that companies, including DoorDash and Airbnb, are moving some work to lower cost Chinese AI models. The Wall Street Journal found Shopify paying for the most capable models because engineering mistakes can cost more than the AI. Both choices can be right. The model, meaning the AI engine doing the work, should match the cost and the risk of the task. One story was much more personal. Actor Eric Dane was losing his ability to speak as ALS gradually took away his muscle control. AI voice company Eleven Labs rebuilt his natural voice from old recordings so he could communicate with his family. His daughters heard it and immediately recognized him. Dane died before they could fully use it. AI voice can sound abstract or threatening until it gives somebody back a part of themselves. Dane and his family chose this use and that consent changes the story. On the personal side, I recently watched the movie version of Remarkably Bright Creatures after reading Shelby Van Pelt's book a few years ago. I enjoyed the movie. It kept what mattered to me about grief, family, closure, and the idea that what you're looking for may be right in front of you. The ending still worked. The book is the stronger version. You spend more time with the two main human characters, Tova and Cameron, and especially Marcellus, the octopus who understands their connection before they do. Marcellus has less to do in the movie and I missed his perspective. I gave the book five stars and the movie four. The movie is worth watching, the book stayed with me. That's it for this week. The full issue with all the links and sources is in your mailbox or at quanta bits newsletter.phive.com. I'm Reza Markabadi. Thanks for listening. See you next week.