Least Privilege for AI Starts With Writing Down What Each Agent Is For

Most AI agent permissions in your organization are the ones that were easiest to grant. Not the permissions the work requires. The ones that made the setup screen stop asking questions. That is not negligence. It is what happens when someone is trying to get a useful thing working by Friday. A service account already exists, so the agent borrows it. A connector asks for read and write scopes, so it gets both. The person who built it knows exactly what it is for, and that knowledge lives in exactly one place: their head. Then they change teams. This is the first and most practical part of governing AI like you hire: least-privilege access, defined roles, and the same review rigor you give a new hire. This post is about the first two, because in practice they are one move. You cannot scope access for a job nobody has written down. The foundation of AI agent governance is a one-page job description for every agent, enforced through least-privilege access.

The Gap Between Confidence and Configuration

The numbers on this are blunt. In an August 2026 survey of 202 IT and security leaders at enterprises with more than 1,000 employees, 94 percent said they were confident their AI agents did not have more access than they needed. Only 33 percent actually provisioned agents with least-privilege access. And 65 percent had already experienced an agent taking an action outside its intended scope ( Read those three numbers together. Most leaders believe their agents are scoped. A third have done the scoping. Two thirds have watched an agent wander anyway. That gap is not mostly a tooling problem. It is a definition problem. “Does this agent have more access than it needs?” is a question you can only answer if someone has written down what it needs. Without that, confidence is a feeling, not a finding. The same survey points at the lifecycle cost. Respondents reported that 31 percent of agentic AI pilots had been paused indefinitely, discontinued, or abandoned, and the researchers noted that many of those pilots had real system access and credentials that were never cleaned up. An abandoned pilot with live credentials is an agent with no job and full keys. Nobody would tolerate that with a former contractor’s badge.

Why “Excessive Agency” Is a Scoping Failure

The security community has already named this risk. OWASP’s guidance for large language model applications lists Excessive Agency as a top risk and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. OWASP’s own example is worth sitting with. A personal assistant is connected to a mailbox so it can summarize incoming email. The plugin it uses can also send messages. A crafted email tricks the model into searching the inbox for sensitive information and forwarding it to an attacker. The suggested fixes are not exotic: a read-only plugin, a read-only scope, and human approval before anything gets sent. Notice what went wrong. The job was “summarize email.” The access was “do anything a mailbox can do.” Nobody decided the agent should be able to send. Nobody decided it shouldn’t. The capability arrived bundled with the connector, and the gap between the job and the access is where the damage happened. Each of OWASP’s three root causes maps to a question a job description answers. Excessive functionality is a question of what the agent does. Excessive permissions is a question of what it can touch. Excessive autonomy is a question of when it must stop and ask. Write those answers down and you have most of a mitigation plan before your security team writes a single policy.

How Do You Govern AI Agents? Start With the Job

Leaders keep asking how to govern AI agents as though the answer were a platform purchase. Platforms help. They enforce what you have decided. They cannot decide for you. Least privilege is an old idea with a precise definition. NIST describes it as the principle that a security architecture grants each entity “the minimum system resources and authorizations that the entity needs to perform its function” . The phrase doing the work is “its function.” Least privilege is defined relative to a job. No job, no baseline, no way to tell whether access is excessive. That is why the job description comes first. It is the reference document your access controls are measured against. Your identity team already knows how to enforce minimum necessary access. What they usually lack, for agents, is anyone telling them what “necessary” means. The identity platforms are starting to require this, which makes AI agent identity a governance question and not only a technical one. Microsoft’s documentation for Entra Agent ID, its system for giving AI agents their own identities, requires at least one sponsor for each agent identity, described as a business representative “accountable for the agent’s purpose and lifecycle decisions,” including access reviews and retention. The same page separates that accountable sponsor from the technical owner who configures the agent. That separation is the right instinct. Somebody has to answer for what the agent is for, and it is not always the person who knows how to wire it up.

The One-Page Job Description

You do not need a framework document. You need one page per agent, written in plain language, kept where your access and service records already live. The page has four core fields, plus two that make it operational.

Start with the outcome, and write it as a result rather than a capability. “Reconciles vendor invoices against purchase orders and flags mismatches for the AP lead” is a job. “Has access to the finance system” is not. The most useful sentence on the whole page is often the one that says what the agent does not do: it flags mismatches, it does not approve payments. That single line tells your identity team the agent needs read access to the payables ledger and no write access at all. Systems touched should be specific enough to configure from. Name the system, the data, and whether the access is read, write, or both. If the honest answer is “it uses the integration account that already existed,” you have found your first fix. The accountable human is a name, not a team. Teams do not answer pages. This is the same owner the agent hangs beneath when you put it on the org chart, and the job description is the document that owner signs. The escalation point is where autonomy gets bounded. Define it in terms of the work: any payment above a threshold, any message to a customer, any change to a record another team owns, any input the agent was not built to handle. OWASP’s recommendation is human approval for high-impact actions before they are taken. The escalation point is where you decide what “high-impact” means for this particular agent. The last two fields keep the page alive. A review cadence turns the job description into a living control rather than a launch artifact, and it is where the third part of the framework, review rigor, attaches. The retirement trigger exists because of that 31 percent. Every agent should be born knowing how it dies and who pulls the credentials when it does.

Least Privilege Is the Job Description, Enforced

Once the page exists, least-privilege access is mostly a translation exercise. Every permission the agent holds should trace back to a line on the page. Every line on the page that implies access should map to a specific, minimal grant. Then compare the page to reality. Pull the agent’s actual permissions and lay them next to the job description. The differences are your backlog. Some of them will be alarming. Most will be mundane: a write scope nobody needed, a shared credential, a connector granted organization-wide when one folder would have done. Two practices keep the gap from reopening. First, prefer access that is scoped to the task and the moment. The Cequence survey found that only 34 percent of organizations evaluate an agent’s authorization at the moment it attempts a specific action. Standing access granted once at setup is the opposite of a job description. It is a blank check. Second, make scope changes go through the accountable human. When an agent needs new access, that is a change to its job, and the page gets updated first. If you cannot get a scope change past the person who owns the agent, it should not happen at the configuration layer either. This is also where AI agent guardrails stop being abstract. A guardrail is only as good as the definition it enforces. With a job description, a guardrail is a boundary you chose. Without one, it is a guess.

A Job Description, Not a Personnel File

The phrase “job description” makes some leaders nervous, and it should be handled carefully. This is not an argument that agents are employees. An agent does not get a title borrowed from a person, a seat in a reporting line next to people, or a performance review. It does not hold judgment the way a person does, and it cannot be asked why in any way that carries accountability. The job description is a borrowed format, not a borrowed status. It belongs with the agent’s identity record, its access grants, and its service documentation, the way a run book belongs with a critical system. The reason to borrow the format is that it works. Every manager already knows how to read one. It forces the same questions you would ask before giving anyone access to anything: what is this for, what does it need, who answers for it, and where does its authority end. Keeping the distinction clear protects your people as well. When an agent’s page names a human as accountable, the answer to “who owns this outcome?” is never “the agent decided.” Someone designed it, scoped it, and deployed it. The page makes that person visible. We run Voltage Control’s own operations with a team of AI agents, and each one starts from a written scope document that says what it owns and, just as plainly, what belongs to someone else. Every one has a human owner. When we have been tempted to widen an agent’s reach, the scope document is where the conversation starts, and that is usually where we discover the request belongs to a different agent or to a person.

Write One This Week

Pick one agent already running on your team. Not the most strategic one. The one you would be least surprised to learn has too much access. Write its page. Outcome owned, systems touched, accountable human, escalation point, review cadence, retirement trigger. If you cannot fill in a field, that blank is a finding, not a formatting problem. An agent with no accountable human is unowned. An agent with no escalation point is unbounded. Then sit down with whoever administers its access and compare the page to the permissions. Remove what the page does not justify. Note what the page needs but the agent lacks. Do it as a working session with the agent’s owner and the people who use its output, not as an audit delivered by email. The people closest to the work know which permissions are load-bearing, and governance they help write is governance they follow. Once one page exists, the second takes half the time. By the tenth, you have the beginnings of an inventory, a set of scoping norms, and a sharp answer to the question your board will eventually ask about your AI governance framework: what can our agents do, and who decided? The organizations that close the gap between 94 percent confident and 33 percent scoped will not do it by buying more confidence. They will do it by writing down, one agent at a time, what each one is for. Everything else in AI agent governance, the access controls, the guardrails, the review rituals, measures itself against that page. If you are working through how to scope and govern the agents already running in your organization, talk with us. Helping leadership teams design governance their people will actually follow is the work we do.

The post Give Your Agents a Job Description appeared first on Voltage Control.

In this episode of the New Friction series from the Facilitation Lab podcast, host Douglas Ferguson interviews Daniel Elizalde, VP of Product and Technology at ReUp Education, about why faster AI-powered building doesn’t automatically produce business results. Daniel describes the “speed fallacy” in B2B, where long sales cycles, security reviews, and limited customer attention cap how fast products can be adopted. He explains how he now treats product and engineering as a portfolio, pausing roadmaps and moving teams to wherever the real bottleneck sits, anchored by a shared company vision that his team communicated through an AI-generated video. The conversation covers misaligned incentives in sales and marketing, the risk of everyone vibe coding their own tools without a shared data layer, and the standardized agents and skills his engineers use with Claude. Daniel closes with the F1 analogy that a faster engine means little if the rest of the car and the track can’t keep up.

Show Highlights

[00:00:00] Welcome and Introducing Daniel Elizalde
[00:01:00] The Speed Fallacy in B2B
[00:04:00] Capital Allocation and Portfolio View
[00:06:00] Re-Teaming Around a Shared Vision
[00:10:00] Rethinking Backlogs, Roadmaps, and Invisible Work
[00:14:00] Incentives Across Sales and Marketing
[00:18:00] The F1 Analogy and Customer Attention
[00:23:00] Vibe Coding, Governance, and Semantic Layers
[00:27:00] Changing How Engineers Work With AI

Links | Resources

Daniel Elizalde on LinkedIn
The B2B Innovator’s Map

About the Guest

Daniel Elizalde builds new products and platforms inside established companies. As VP of Product and Technology at ReUp Education, he leads Product, Engineering, and Design and is building an agentic AI platform that helps adult learners return to college and graduate. He previously served as VP and Head of IoT at Ericsson and built the product function at Stem, the AI-powered energy storage company. He is the author of The B2B Innovator’s Map, has taught over a thousand product leaders at Stanford Continuing Studies, and previously hosted the Enterprise Product Leadership podcast. He lives in Austin, Texas.

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free. So why are organizations still stuck? Because the friction didn’t disappear. It moved and it multiplied. It’s no longer in building. It’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore. The conversation before the work is. That’s the work this show is about. Today, I’m with Daniel Elizalde, a VP of product and technology at ReUp Education, where he’s building an agentic AI platform. He previously led IoT innovation with Ericsson and product at Stem, wrote The B2B Innovator’s Map and has taught over a 1,000 product leaders at Stanford. His view, “AI initiatives rarely fail on the technology.” Welcome to the show, Daniel.

Daniel Elizalde: Thank you, Douglas. Very excited to be here. Thank you for having me.

Douglas Ferguson: Yes, it’s great to have you. Looking forward to chatting more today. I guess, we can get our start here. The series is about the new friction that is emerging, as we’ve discussed in the past, the friction is not always new. It might be showing up in new ways or resurfacing or getting amplified in new ways by AI. I’m curious, when you heard the name of the series and saw that intro, were there any particular frictions that jumped to mind immediately? Like, “Oh, this just happened today.” Or, “This has been on my mind.”

Daniel Elizalde: Yeah, there’s a few of those that are happening, like we mentioned, all at the same time. My focus has always been on B2B and have been lucky enough to be in roles that allow me to see the breadth of the business. So some of the things that I am seeing are around how the speed is there and it’s important, but the impact on the business might not be there. What I’m seeing is that more features don’t necessarily mean more revenue, but adoption is what really moves revenue and margins. So where I try to focus is on the adoption of the products, and there’s a lot of challenges with adoption. And one of the main frictions that I’m seeing is the speed fallacy, especially in B2B, where you have sales cycles that might be six months long, you have security reviews, you have procurement, you have all these different things, before you can actually recognize some of that revenue. And those processes, those teams, they haven’t changed. I work in heavily regulated industries. I’ve worked in energy and telco and education, and sometimes the money comes from the government and it’s even slower. And so all of a sudden … Yes, you can put products faster, but if they’re not landing, the customer doesn’t have the capacity to adopt them, and in six months you’re going to have maybe 10X the products, but you’re not able to close one contract. The impact of the business is not there. And so that’s a really interesting perspective that I’m seeing today.

Douglas Ferguson: Yeah. I always like to say if we were making bad product decisions, AI is only going to help us make those bad product decisions faster. It actually might create more of a problem because you talked about more features not actually driving revenue. It actually might reduce revenue because if folks are already frustrated and unclear on how to use things. There’s just friction in the application and we throw more at them, it might slow them down even more because now they’re even more confused.

Daniel Elizalde: Yeah, exactly. And if we take a pure product management centric approach, where we’re trying to solve a problem from the customer, and sometimes a feature set is enough to solve that particular problem. We have to remember that we are not the center of the world of our customers. We are one vendor with one tool to help them do their job. And there’s a few things here, more features might not help them in that path. In fact, I’ve had complaints in the past where it’s like, “Wait, your software was fine and now these other things are here and I can’t find them or I can’t use them.” Or they break something. So that’s a reality that I think of product and technology a little bit more from capital allocation. If you are a company and you’re thinking about … In my case, you’re driving product and engineering,. Well, it’s not only about, can my teams develop these things faster? Which I know we can, but will that really advance the business or should I just say this product is good enough as it is, it serves its purpose, and now I should deploy my engineering team over here, over here, over here, because those are the real problems that the customer has next. It’s an interesting change in perspective of how we have to operate at a different level, thinking about the bottom line of the company and us technology leaders as stewards of that product.

Douglas Ferguson: Yeah. Have you found that you’ve adjusted your decision making or the lenses that you’re using to make the decisions around how you allocate the capital?

Daniel Elizalde: Yes, I have. I am taking a holistic view about our overall platform. We have a couple of products at my company today for universities and some others, for the learners that we’re serving, and then we have an actual platform that connects everything. And so we have pods that resemble that, that make, but this is where the allocation comes into play because a pod is dedicated to a particular product line, and if that product line is serving their purpose and more features is not going to result in either more adoption or more revenue or more margin or more retention. Then I can take a step back and say, “You know what? The roadmap stops here for two quarters, until the customer is able to catch up with that adoption. And in the meantime, I’m going to move this engineering team to accelerate this other piece.” So it’s a portfolio view. And in the past, years ago, I used to be more driven into my pods and this product is going to be continued to evolve forever and it’s always a roadmap and it’s always features. But when you can do the feature set of three years in six months, then all of a sudden you have to be smarter about, “Okay, I’m not going to go three years at this speed.” Because again, looking at the bottom line, if it’s not moving the needle on the business, then it doesn’t matter. You’re wasting that allocation.

Douglas Ferguson: Yep. You wrote a book on B2B innovation, and you’re making me think about some of the innovation principles around organizational structure and the classic story of … And I’m a big believer in this, that Kodak’s issue was the structural one. The head of product was a chemist. So the thought of innovation from a chemistry lens, not a technology or software certainly, or digital photos were not chemistry. And so to your point, if you’ve got an org structure where these squads or teams are focused on products and that’s how they do their work and that’s how they think about providing value. They’re going to continue to push on something that doesn’t need to be pushed on. So this idea of being willing to re-team and redistribute the resources and reorganize people on a regular basis. So to your point, to align to this portfolio planning or portfolio view. So I’m curious, have you developed any new rituals or processes or cadences for thinking about how to realign the teams and make up and the focus that they’re driving toward?

Daniel Elizalde: Yeah, we’re starting again … Like you said at the beginning, this is very new for everybody. And so one of the interesting challenges that I’m facing right now is just that what you said. I’ve been in technology for 25 years and I’ve run product and engineering for a long time, and this is something new. At this stage of my career, I have to figure out now, how do we run teams in a completely different capacity? So some of the things that I’ve been experimenting is trying to think about the holistic product and engineering team as the overall product and engineering team. And yes, they are assigned to pods, but it’s more because of the work that needs to be done right now. So everybody is really well aware of the company vision. We’ve made efforts to crystallize what that vision is, where we’re going to be in three, five years. We actually use AI. One of my engineers used AI to create an amazing video of that vision for the future that helped us a great communication mechanism, both with leadership, the rest of the departments and engineering. And so now everybody knows where we’re going and they should see their work reflected in that vision. And so with that in mind, it is easier to say, “You know what? This part of the vision is the one that is the bottleneck now. Let’s realign the pods, so that the capacity goes and moves that.” I love the energy and electricity, so some of the challenges that the grid has today. The source exists, you can create a lot of code, the destination exists, the customers, but then sometimes the pipes, the grid itself is where the bottlenecks are. And so I see as myself, as a leader of the organization to try to untangle those and see, “Okay, for the outcome to flow, we need to remove this bottleneck right here. So team, we’re going to focus on this because it unstuck this part and now this part and now this part.” And because everybody understands the overarching vision, we’re starting to get a lot of buy-in because everybody says, “Yeah, I understand that my role here is not to build this widget or this API or this whatever. We’re building towards that vision and that’s what’s needed of me right now.”

Douglas Ferguson: Yeah. I’m able to smooth the path to our ultimate victory. And if people can understand how their contributions fit into something bigger, it’s easier for them to do what’s needed, but also not go beyond. Because sometimes folks in their effort to excel build things that just require extra maintenance and it’s not necessary. So that’s another reason why strong purposes can be such a valuable North Star because it helps us understand what not to do or what’s just enough.

Daniel Elizalde: Yeah, exactly. And I try to be very business focused even with my engineering teams, particularly with my engineering teams, so that they can understand the impact. And we actually have these conversations about the investment and the money. A good friend of mine and mentor, Rich Mironov, wrote this book, Money Stories. And I gave it to everybody in my team because that’s the language of business that we need to talk about. And so when they propose that we need to do this new module, new service, new feature set.. It’s like, “Okay. Well, let’s tie it back to the business. How are we going to monetize it? And yes, this could have this impact, but if we unstuck the pipe in this other way, we can actually improve performance overall.” Right?

Douglas Ferguson: Yeah. Mm-hmm.

Daniel Elizalde: And we’re coming up with prioritization frameworks that actually have those notes and saying, “Well, does this thing that you’re proposing has a point solution impact or does it have a platform impact?” And so that way people can see, “Okay, this serves the bigger picture, this thing is smaller in scope, so yes, I can move.” A change that I didn’t expect is that the actual teams of implementation, product design and engineering, they’re actually more excited about this because they feel like they are contributing to the true impact step by step, as opposed to be working on this thing that’s doing its thing, but it might not be contributing directly. So they feel more empowered. That’s the goal at least.

Douglas Ferguson: Yeah. The thing that comes to mind for me there is the video that you’re talking about someone making. Not only did the organization take the time to clarify that vision, that North Star, but also it was communicated in a way that even inspired engineers to go build a video to help amplify that. Any other things that might be helpful for the listener to understand the dynamics there and what made that possible? Because some of that’s y’all realizing it was important and investing the time. Part of it’s the AI tooling that allowed for him to do that more provocative storytelling. All of that were precursors as well to this situation where people feel bought in and feel supported and working in these re-teamed squads, if you will.

Daniel Elizalde: Yeah. That’s a really good point. And it’s a good example of making sure that you have a vision and you can drive it forward. I credit our CEO. She said, “Well, we need to present this vision not only for the next quarter or the next year, but we’re in the middle of this transformation, not only within AI, but AI is helping us accelerate that transformation. And so we need to be able to articulate where this is going to end up.” And so we actually did an executive retreat. We traveled to San Diego, spent a week with the executive team and whiteboarding and all of these things. We had several things. For example, I had a product strategy that says, “Okay, this is where we’re going,” but there were pieces. And so we were able to come up with a narrative. And then with that narrative, the request from the CEO was how can we make others really feel this vision? It’s like a document won’t do. So the idea of the video came up. So I created a storyboard, so to speak, and one of my engineers is very well versed with AI, so she took it on. It’s like, “Yeah, I can create a video.” And it’s like, “Well, okay.” In three days with Claude, she was able to create this incredible 10-minute video of the overall journey from our customers, of what it would be in the future. And we did a few iterations, just of the power of AI in that sense … A video like that 10 years ago would’ve costed $50,000. And now we’re able to do that in a week, refine it. We’ve been using that video to say, “This is where we’re going.” And it’s been incredibly well received because people can see not only in engineering, but in marketing, in part of success, in our learner services, they can see themselves as like, “Oh, I can see where this is going.” And for some folks it’s like, “I can see how my work maps to that.” Other folks is like, “I can see how my work is going to change significantly, so let’s talk about it.” But at least we’re all having the same vision and the same idea. And so from there now, I can put together the pieces for the roadmap and the prioritization framework. It’s like, “Now what we’re building there is … And the reason why I’m moving this spot from here to here is because we’re building this piece of the vision and that’s what’s coming in Q4.” So it’s been a really interesting way of working that we hadn’t had before, and it’s worked really well for us and for our company.

Douglas Ferguson: Yeah. And how has … I can maybe take a guess here, since you’ve been talking about taking a more portfolio view of things and whatnot and some of the shifts around just pausing something for a moment because you’re at that point, but how has it impacted how you think about backlogs as well as roadmaps?

Daniel Elizalde: Yeah, that’s a really good point. In the past, with agile and just typical product factory, you have this never-ending backlog. And I’m moving to the point where it’s like, “Yes, in the past we have this principle where the backlog never gets done and always prioritize the top things.” But now I am finding a lot more useful to say, “Do quarterly planning.” And say, “In this quarter, we’re going to build this piece of division. And so how do I need to organize my infrastructure team, my systems engineering team, my application team, my design team to build that piece?” And it’s coherent and it’s cohesive. And so that way you are able to advance towards the vision clearly, basically following the video And it’s like, “From this quarter we’re going to do this and therefore the roadmap for this portion is this.” And what has helped us a lot is that that has helped us surface the invisible work. Right?

Douglas Ferguson: Mm-hmm.

Daniel Elizalde: Engineering leaders will relate with me, tech debt, infrastructure. It’s really hard to sell at a business level, but when you have that vision that everybody understands, it’s a lot easier for me to say, “Well, yeah. Our AI agent strategy sits here, but for that to run, we need this infrastructure and this pipelines and this services and the warehouse needs to be like this, so therefore we’re going to build those things.” And so all of a sudden it’s not invisible work, it’s not tech debt, it’s really infrastructure work that is needed to power the vision. But without that understanding of that vision, it’s very abstract and it’s really difficult to sell. And my company’s not particularly technical, so they don’t really … Outside the engineering teams, we can’t really talk services or architectures. That’s my job to translate. But anchoring in that vision really, really helps to sell what is needed. And so what in the past could have looked like, “You spent the whole quarter and you didn’t produce much. Well, we did, but it’s this invisible work?” To now, we’re doing 70% infrastructure work and that is the core to power the vision. So it’s a big mindset shift. It’s months in the making, but I think it’s resonating now. It’s really powerful.

Douglas Ferguson: Yeah. I’ve heard a number of folks taking an approach that’s, again, more portfolio-based, holistic in our thinking around, “What do we need to accomplish? How’s that aligned with the vision?” And then dynamically re-teaming as needed. A cadence can change based on the organization, but the quarterly is fairly popular I’ve seen, where that’s once a quarter look and say, “What are our big rocks, if you will, and how do we need to organize a team to follow along with those?” And then the number is dictated by a healthy understanding of what our work in progress limit should be because we don’t want to jam through too much stuff in the system. But then to your point, these roadmaps and backlogs and things, what’s their purpose in the future if we’re operating these ways? In fact, I’ve heard some folks talk about backlogs going to zero because effectively with AI, we should operate zero technical debt because the whole thesis around technical debt is we need to maintain that just because it’s too costly to build the things right out of the gate. And a lot of that trade-off goes out the window now.

Daniel Elizalde: Yeah, to some extent. I’ve always thought of roadmaps more as a strategic tool because I think that if you use it as themes or business needs or strategic initiatives, then it’s a way to prioritize and catalog, should we do this against this versus this? And it becomes, again, that allocation problem than the tech debt, regardless of what goes underneath. So I think that product owner mentality, the stealing the stories, and that’s your backlog is pages and pages. Yeah, I don’t think that makes a lot of sense. The speed is different, so you can do a lot more, a lot faster, but you still need that idea of the trade-offs and what advances you to the vision to protect that investment, because otherwise it’s very easy to get it pulled off to other things. Right?

Douglas Ferguson: Yeah. And it comes back to something you were saying earlier about you were developing some different mechanisms for prioritization. so I was curious to learn a little bit more about what you tried there, what you found is working.

Daniel Elizalde: Yeah, it’s been a journey there because every company’s different and we’re trying to figure out this roadmapping process that is from … It’s funny. I would say it’s from a different era, from four years ago, but it doesn’t feel as natural as it should be. I struggle with, what do I present to leadership? How do we prioritize? How do we do that? And then in our company, we had the opportunity to work with an external contractor that has been really, really smart and really, really helpful in having a third-party perspective. And so really what we’re trying to solve is a portfolio allocation prioritization challenge. Therefore, it’s not about the huge backlog, it’s about the three to five big things that will move the needle in a particular quarter. And so that’s how we moved. And of course, we still have Jira and we have all those things, but those are more for the actual execution. The roadmap truly goes back to one slide that gets approved be the board, which is very interesting because … As much as I love the product management tools that are out there that are fantastic for roadmapping, I’m starting to find them a little bit like, “I don’t know that I need something like that, as complex.” Maybe for much bigger teams because we’re a small company. All these things are changing and we’re just learning a ton as we go.

Douglas Ferguson: Mm-hmm. Yeah. And I’m curious, what shifts you’re noticing across the roles and functions? You kind of alluded to this too, where it’s like some folks see the vision and know exactly what’s expected of them. Some people see the vision and they’re like, “Oh, I’m not sure. We need to discuss what this means for me.” But also, in addition to just how am I aligned to the mission that’s just like, “Hey, if the rituals and practices are evolving, how is my role even shifting as well?”

Daniel Elizalde: Yes, we definitely have those conversations about what is the role within my teams, product or designer or a systems engineer or a DevOps engineer. But what I’m seeing that I’m finding more interestingly is outside the technology teams, how that alignment and those roles should change. And what I mean is that what I’m seeing … And I wrote this in my book, it’s not necessarily new, but I’m seeing it accelerated, that when you’re doing something new, either a new product, new initiative, or something just much faster. Then you have to have alignment across the various department, not just technology. And it comes down really to incentives, not technology. And so what I mean by that is that in the past, companies have had this very well-structured NPI process, new product … NPI. So new product introduction process, development, engineering does this, gets handoff to maybe operations. There’s a sales enablement, there’s sales and there’s marketing, but now all of that has changed significantly. And so what I’m seeing is that the receiving teams, whether it’s go-to-market, customer success, sales market, et cetera. Might not be ready to take on these new products. And it goes down to incentives. I had this anecdote that I remember from some time ago in a previous company, where we created this very innovative product working with customers. It was a really good problem for a … A very good solution for a strong problem. We launch it to market and it wouldn’t sell. Nobody would buy it. And after we did some digging and some analysis, the culprit was that the sales team could meet quota without this product. So they were not incentivized to even show it. So that caused a change in structure from sales and quota, and all of a sudden, guess what? The product started flying off the shelves and it became super, super successful. And so I’m seeing this, but at a different pace. We see here in the technology, we can put out a new brand new product and say, “Here it is.” And marketing would say, “Wait, I have my OKRs. I’m not ready for this. I don’t have capacity for a new product.” Sales would say, “Wait, I already have my targets and my quota. I don’t know what to do with this.” And so it works both as you try to deploy that product, but also as you try to build this product in a more iterative way. Sometimes you’re going to need interaction end-to-end. For example, if you have a PLC type of product that needs to route traffic to do something. Well, marketing needs to be involved early to test. Well, they are going to have to work at the speed that you’re able to develop, and they might say, “Well, we don’t have the resources right now. This is not in our plan.” And so it comes down to a leadership challenge of looking at the organization, and you have to have the right incentives in all the departments. You can’t just say, “Tech team, move faster. Here’s licenses of Claude or whatever, deliver at 10X.” You can’t be the only group with that incentive and with that mandate, because then whatever you produce just hits a wall with the rest of the organization. And that’s a big friction that I’m seeing. So executive leadership has to understand that when you empower a team to work 10X, that’s going to have to ripple some X’s in all the other departments, so that investment actually produces something.

Douglas Ferguson: Yep, totally agree. And also too, another thing that I was thinking about from something you were sharing around … Part of the prioritization process is identifying where the bottlenecks are. So in the case here, this is not just a bottleneck in product adoption, this is a bottleneck in operations and how we function as an organization. And we have to look at both because if we’re just looking at how users are behaving, it’s only part of the picture. And so in this case, you talked about the bottleneck being incentives for the sales team, but I’m curious, what other bottlenecks have you noticed in the recent few months as things have been shifting around your approach to teaming and setting priorities and even the speed of development?

Daniel Elizalde: Yeah. One thing that I want to point out that I’ve seen talking about this new speed, a bottleneck that I’m finding is that customer attention is a scarce resource. We can’t just say, “Hey, in the past, we need to be very customer-centric. We need to do discovery. We need to put prototypes in front of the customer, and it takes time.” And that’s the right still way to build products because you need that input from real users. But especially in B2B, those customers are busy running their business and they have very limited time to look at discovery with you or to see your latest demo or to see your latest thing. And it needs to be orchestrated with sales. And so all of a sudden, you want to be in front of your customers with 35 new prototypes that you created this week. I mean, it just doesn’t work. There’s an exhaustion from favors you can ask from customers and people to understand that. That is different. So how do you make sure that you’re building the right thing with the right inputs without having to burn all your favors and balance that speed? A main message here is that with AI, you can accelerate your own clock, but you can’t accelerate things that are not in your control. You can’t accelerate the speed of adoption. You can’t accelerate the attention span of the customers. You can’t accelerate grants and things like that. So how do you do it? I’ve had some discussions with other leaders about like, “Well, maybe you just slow down some of the things.” Maybe you say, “We’re not going to produce things as fast because they can’t be consumed by the market, so what’s the point?” So those are philosophical things we’re wrestling in the product and engineering world. Right?

Douglas Ferguson: Yeah. I mean, it’s interesting you talk about … There’s kind of a thread here around … There are some things that can move insanely fast, but then there’s some things that are governed by laws of physics that require … There’s a built-in speed limit. The speed of light is a constant and we can’t go over it. And so we have to be mindful of those. And that’s where … This is something we talked about in the pre-show chat, taking a systems approach is so critical because if we’re not taking a systems approach, we don’t notice those incentives that are biting us in sales. We don’t notice that there’s this speed limit that we’re not accounting for. We’re just throwing stuff through. And to your point, we can build tons and tons of prototypes, but if we don’t have enough people to look at them, then we can’t get the feedback because the prototype’s invaluable. I mean, a prototype is just a tool to answer a question. If there’s no one there to answer that question for us, then the prototype’s of little value. There’s a similar thing, I don’t know if you’ve seen this, but there’s a similar problem where … This hits more on the business side, I think. But I guess even on the product side, people are generating so many artifacts that those that are reviewing the artifacts are just overwhelmed. Take your example of building 53 prototypes. We certainly can’t necessarily show that to the users because we’d overwhelm them, but even the team having to … Who’s the person that’s going to review those and decide which one we do put in front of the user?

Daniel Elizalde: Exactly.

Douglas Ferguson: That’s a whole nother body of work that didn’t exist before.

Daniel Elizalde: Yeah. And just to keep your speed limit analogy, I’m a huge car fan and a big F1 fan. And the way I think about this revolution is that if you have an F1 team and then all of a sudden the engine mechanics figure out how to do engines 10X as fast. Not just by putting the engine in the car, that’s not going to make it 10X faster. The wheels are not designed for that and the suspension is not designed for that, and you’re going to burn your fuel like that. And then you take it outside your team. Well, the tracks are not built for that speed and the pit stops are not built for that. So all of a sudden the suspension team is going to say, “Okay, we’re going to update the suspension for this new engine. Wait, I have three other new models of engines that I created during the weekend.” And it’s like, “It doesn’t work like that.” And so for the team owners, they’re like, “We’re not necessarily going any faster. We’re not winning any races because yes, we have one part that is faster, but it has to work as a whole and the whole is not adapting as fast. And the market, the track in this case is not adapting as fast either.” There’s lots of physics there, right?

Douglas Ferguson: Yep. When you mentioned that, I immediately went to the pit crew and how tuned that has to be. And to your point, if you over optimize one thing, it actually might make things go slower because now the whole … That system is dysregulated.

Daniel Elizalde: Exactly. And you see it even … I don’t know if you follow F1, but you see teams doing an upgrade to the engine and all of a sudden there’s a lot of vibration or it turns out that the brakes are not calibrated the same. And so they actually go slower, instead of faster.

Douglas Ferguson: Yeah, yeah.

Daniel Elizalde: So we’re seeing the same thing. And I don’t know that … Going back to business, the rest of the organization can work at that speed. And so I think there’s going to be a recalculation of what it really means to drive technology in a company because that exponential output that we’re able to create, if it doesn’t have a home to go and drive the rest of the business. Then it doesn’t make sense. Yes, you can do it. I’ve heard some people talk about, “Well, instead of having two pods with six developers, you’re going to have the PM builder and you’re going to have 12 people, each one of them doing their own product and you’ll have 12 products.” And it’s like, “That’s crazy.” As a company, how do you absorb 12 products? How do you sell them? How do you market them? It’s just not realistic. So it’s really interesting. I’m really curious to see where this is going to land, so that we can balance the rest of the car and the rest of the team to truly provide more value to the customer, which is what this is all about.

Douglas Ferguson: Yeah. Yeah, I agree. I also think too, there’s … Other products is certainly one direction that things can go, but also, how are engineers supporting the rest of the organization? Because we’ve never been in a point in history where it’s so easy to build your own tooling for things that … And our need for tooling is probably going to increase dramatically, to your point as the other parts of the organization need to function well beyond what they can today. And so instead of new product lines, what about carving folks out to think about decision making tool frameworks? All sorts of things that we might need and internal admin dashboards. If we’re perplexed on where the bottleneck is, do we need to build a tool to analyze the bottlenecks, rather than just assume and go build, let’s make some scaffolding, so we can understand the business better, understand the user better. These kinds of things.

Daniel Elizalde: Yeah, definitely. And that is an interesting conundrum that I’m also seeing as big friction, when it is so easy for non-technical folks to create solutions, thinking about outside product engineering, anybody can vibe code an application. If you think about the history where we’re coming from, organizations grow when you have legacy systems that took 5, 10, 20 years to fold and now they’re a mess and you have to do a lot of maintenance and that. And so if all of a sudden everybody in the organization can vibe code their own thing, that legacy, that rat’s nest of tools and information and all that becomes accelerated. There’s a big importance on understanding what those applications are using for getting their information. So data pipelines, semantic layers, those things to make sure that, “Okay, if you’re going to allow people to build their own things, the maintenance is hard, but at least they’re all reading from the same data.” And those are the kind of things that are invisible engineering, and you have to come in to the executive team and say, “For us to enable to do this, if we’re going to let everybody in the company vibe their own apps, they’re not going to cross my infrastructure line. I’m going to have to give them a layer that they can poke into and that’s going to take resources to build.” But after that, we’re enabling this vision that more people tap into that. And if you don’t have that initial governance or those discussions, it becomes a free for all, and then everybody has their own data, it becomes a mess. That is organically how companies evolve, but you can get there in six months these days, right?

Douglas Ferguson: Yeah. Yeah. People talk a lot about governance and what’s needed to have safe and reliable and responsible AI use. I think it’s conversations like these around, what semantic layer are we going to provide? How are we firewalling people off, so they can’t do things that are unintended? Just being really thoughtful about these guardrails that we put in place, so they can experiment freely and almost feel unencumbered because they’re hitting the bumpers that are necessary and we can trust those bumpers are where they need to be and will withhold whatever they throw at them.

Daniel Elizalde: Yeah. And I feel like that is one of the frictions because all of a sudden you have this tension of speed. “Hey, technology team. What do you mean you need six months to build a solid semantic layer with services on top so that we can run, I don’t know, agentic analytics or something? When I can just take Claude and vibe code this thing in five minutes.” “It’s like, “Yeah, but that doesn’t scale.” There’s a lot of things that … You don’t want to be the bottleneck either. So you have to say, “Well, if I don’t have the capacity to solve those business problems right now, what are the potential solutions?” You can build them yourself with AI, but it has to be some layer of guardrails and governance, otherwise it becomes a mess. And building that layer both in terms of rules and actual software takes time. So there’s a paradox, like a push and pull of, “Yeah, this should be easy. We can do all these things now. Yeah, kind of.”

Douglas Ferguson: Yep. One of the things we’ve been talking a lot about is what we call friction discernment. It’s often a treacherous path to go just try to assassinate all friction because A, to your point, is solving that friction going to provide business value and how do we prioritize which friction gets attention? But also just because something feels slow and frictionful doesn’t necessarily mean it’s a bad thing. And so being able to acknowledge it like, “Actually that friction is a feature and maybe we leave that in the system.”

Daniel Elizalde: Yes, I think that’s a really good point, understanding what things are better slowed down, especially in my case working with regulated industries. Well, we’re going to take longer, but we’re going to analyze and make sure that nobody can access personal identifiable data or governance around something else. It’s better to take some time on that than the consequences.

Douglas Ferguson: Yeah. We talked a bit about the strategic layer, so taking this portfolio approach, deciding what’s in, even hitting the pause button on things, just because adding more isn’t always necessarily the right business decision. And layered onto that … Well, I guess in the pre-show chat, we talked about you in your purview having to think about three layers. The business use cases of AI, how are folks across the org consuming it? We touched on that just a little bit around the semantic layer, but the second way that you’re thinking about AI is how AI is being embedded and showing up in the product and AI powering certain features and capabilities in the product. But then there’s also one we haven’t touched on yet, which you said definitely is something you’re having to think about and this three-headed beast, which is how is it empowering engineers or even shifting the development process? And so I’m curious, what have you retooled or shifted as it relates to your release train? And so beyond just the deciding what to put into it, once you’ve decided what to build, how’s the day-to-day engineer experience shifted for your team?

Daniel Elizalde: Yeah, that’s a good question. We are in the journey, nobody has fully figured it out, but the reality is that there’s a good level of adoption of tools, development tools, code in particular in my engineering team, and there’s a big amount of the actual code being written by Claude. And so we have mostly … The role of the developers of course is getting the prompts, understanding what we’re building and reviewing, but there’s a lot less of that manual coding. We have discussed a lot of the re-usability. How do we make sure that it is standardized as our operating procedures? So it’s not like this developer happens to be very senior, they use it this way versus this other. It’s like, “What are those guidelines? What are the skills that we need to do? What are the tooling that we need to build?” And my team has built really interesting tools about, this is how we do ticket refinement, this is how we do the pulls and push, this is how we test some corner use cases. So those are already either agents or skills, and so everybody in the team uses those. And so we are able to get a lot of velocity along with consistency across the teams. And that is super important for me because … Talking about this capacity allocation, I want to make sure that the engineering team members are able to perform the same with the same operating principles, whether they are in part A, part B or part C. And so that has to be standardized across. And so that’s a journey. We’re not there for sure, but there’s that understanding from my perspective that it can’t be, “Here’s Claude, have at it.” There has to be some discipline, there has to be some training, there has to be some governance in like, “This is how we use it internally.” And one of my engineering managers, she’s really, really strong and really, really good at this. So she’s setting all those principles and then training the teams and making sure that we have a true operating cadence.

Douglas Ferguson: Nice.

Daniel Elizalde: It made us very, very, very efficient and we’re able to be very productive in a way that we haven’t been in a long time. And definitely in my career, we are producing a ton of output that is solid at a pace and with much smaller teams that I’ve had managed in the past. It’s incredible. And so the challenge really is for me in the leadership seat, where do I point this newly created engine? Where is the best way to do it? Because wherever I point it, it’s going to do a lot very quickly. So I better point it in the right direction. that’s the challenge from a leadership perspective that I’m sure a lot of tech execs are dealing with. Right?

Douglas Ferguson: Yeah. It’s like having a high-powered laser versus a shotgun, right?

Daniel Elizalde: Yeah, exactly. Exactly. It’s always like-

Douglas Ferguson: You can spray a wide range with the shotgun, but it’s not going very far. But a laser, you got to be real specific, but it can go quite a vast distance.

Daniel Elizalde: Yeah, exactly. If you were kind of goofing around and you were pointing it at your feet and it fires, all of a sudden you have a crater in the floor. It can actually put you in the hole very, very quickly.

Douglas Ferguson: Yeah.

Daniel Elizalde: We have started to put a lot of … In addition to the clarity of product management and how the things we’re building fit with the mission, we’re also trying to create a strong architectural blueprint and reference, so that everything we build has patterns, knows where it fits. We can have consistency of how services and APIs and all those things work together. Just trying to make sure that if we’re going to go this fast, we better train for that. If you’re going to be an F1 driver, you better spend so many hours in the gym and learning and on the simulator, so that when you get in that rocket ship, you actually win the race.

Douglas Ferguson: Yeah. Awesome. Well, as we come to a close here, I want to leave you with an opportunity to offer our listeners a final thought.

Daniel Elizalde: Well, I think as a final thought, I think that … My main thesis throughout today is really before we can ask how fast a team can ship, we really need to understand how fast your customer can adopt whatever you are shipping. Because without that, you’re not going to be improving on the business numbers and it’s just development theater.

Douglas Ferguson: Wise words. Thank you, Daniel. Appreciate everything and look forward to talking to you again.

Daniel Elizalde: Thank you so much for the opportunity. I really enjoyed the talk, Douglas. I’ll see you the next time here in Austin.

Douglas Ferguson: Thanks for listening to New Friction. If you enjoyed this episode, share it with a leader who’s in the middle of this right now. They’ll thank you for it. And if you want to go deeper, we bring leaders together through executive dinners and virtual masterminds. To learn more about our work or to inquire about exclusive executive events, visit voltagecontrol.com. I’m Douglas Ferguson. See you next time.

The post Before Asking How Fast You Can Ship, Ask How Fast Customers Can Adopt appeared first on Voltage Control.

It Showed You What Was Already Broken

Somewhere in the last year, the marketing org at a global medical-equipment maker did something a lot of companies are doing right now. They looked at their agency spend, roughly a million dollars a year of it, and decided AI could absorb most of that work. They cut the spend. They stood up AI tools across the team. On paper, it was a clean win. Then the work actually started, and the team found out what the agencies had been quietly doing for years besides writing copy and building decks. They had been the connective tissue. The thing that made five different sub-teams sound like one company. Once that tissue was gone, and AI was doing the generating, the marketing org discovered it had never had a single source of truth. It had brand guidelines in one place, campaign history in another, and no shared understanding of voice that lived anywhere except in the heads of the vendors who had just been let go. Every group had already started building its own custom GPT, trained on whatever slice of data that group happened to have. Each one was fast, confident, and fluent. None of them agreed with the others. The organization had developed a split brain, and AI did not cause it. AI just removed the last thing that had been quietly patching over it.

The organization was already fractured. AI just stopped hiding it.

This is the part leaders get backwards. The instinct, when AI output looks inconsistent or the rollout feels messy, is to blame the tool. Wrong model, wrong prompt, wrong vendor, wrong training. Send everyone to a workshop. Buy a better license tier. None of that fixes what actually happened at the medical-equipment maker, because the problem was never the model. It was that five sub-teams had never agreed on what “on brand” meant, had never centralized what campaigns had already run, and had never built a shared source of truth because a small army of agency staff had been absorbing that inconsistency by hand. Humans were the buffer. Nobody had designed the buffer. It had just accumulated, the way undocumented process always does, until the day someone cut the budget line that funded it. AI does not create organizational dysfunction. It is a speed multiplier, and speed multiplies whatever is already there. A team with a shared foundation gets faster at doing good work. A team without one gets faster at producing confident, fluent, contradictory work, and finds out about the contradiction days sooner than it would have with a slower process and a human buffer catching the seams. The tool is not the diagnosis. It is the thing that made the diagnosis impossible to keep avoiding.

This is not a marketing problem, and it is not a one-company problem

It is tempting to file this under brand consistency and move on. Resist that. The same pattern shows up anywhere a team quietly outsourced its coherence to a human buffer and then automated around that buffer without noticing it was there. A regulated bank rolls out an assistant across the workflow layer and instantly surfaces which teams had informal, undocumented pay bands and who actually approves what, because the tool cannot respect a boundary nobody wrote down. A product organization spins up parallel AI-assisted design sprints across business units that had never shared a single design system, and gets five plausible answers to the same brief instead of one. A research group lets every analyst build a personal assistant on their own corner of the data, and stops being able to explain why two people, working from the same underlying numbers, produced two different conclusions in the same week. None of these are AI failures. They are the same organizational fracture, dressed differently by industry. The tool exposes it because the tool does not know, and was never told, which version of the truth is the real one. This is the new friction in miniature. AI did not eliminate the work of building a coherent organization. It relocated that work, from the years-long background task of quietly patching gaps by hand to a single, unmissable moment when the patches are gone and the gaps are visible in the output. The friction of building coherence never disappeared. It just moved from invisible to unavoidable, and it moved fast enough that most leaders have not caught up to where it landed.

Split brain has two shapes, and most organizations build both at once

Once you see this pattern, it shows up everywhere, and it shows up in two opposite failure modes that somehow coexist inside the same company. The first shape is what happened in marketing: total dispersal. Every team, sometimes every person, builds a custom GPT trained on its own slice of data. Each one is locally confident. None of them share a voice, because none of them share a foundation. You end up with a dozen assistants that are each fluent in their own dialect and mutually unintelligible to each other, which is a strange kind of progress. Everyone got faster. Nobody got aligned. The second shape is the opposite instinct, usually deployed as the fix for the first one. Leadership sees the fragmentation, panics, and points one enterprise-wide tool at everything the company owns. This is supposed to be the unifying move. In practice it produces something closer to a watered-down house style than a shared brain. Feed a model everything, undifferentiated, and it has to average across all of it. The result is often worse and blander than what a focused, well-scoped model would have produced on its own, because breadth without curation is not the same thing as a shared foundation. It is just a bigger pile of unshaped context. Both failure modes trace back to the same root cause: nobody treated context as something that needed to be designed. Context was either left to fragment by default, or dumped in wholesale and left to dilute by default. Neither is a decision. Both are the absence of one.

AI is only as good as the context you give it, and context is not a technology problem

There is a useful discipline hiding underneath the prompting conversation, and most organizations never get to it because they are stuck arguing about prompting instead. Call it context shaping: the deliberate work of deciding what belongs in the shared foundation, what belongs at the team level, and what should never be centralized at all. Too broad, and the model has no way to distinguish signal from noise. It steers off toward the statistical average of everything you have ever written, which is nobody’s actual voice. Too narrow, siloed team by team, and you get a company that talks to itself in a dozen dialects and calls that autonomy. The discipline is finding the altitude in between: a foundation specific enough to sound like your company, general enough that five teams can build on it without diverging. That altitude is not a model setting. It is an organizational decision, and it looks a lot like the decisions good facilitation has always forced onto the table. Who owns the shared definition of “on brand”? What actually belongs in that definition, and what was always going to be team-specific judgment layered on top? Who has the authority to say a sub-team’s fast, fluent output does not count as canonical, even though it shipped first? None of these questions have a technical answer. They have an organizational one, and an organization that has never had to answer them before AI arrived will not enjoy discovering that AI is now the reason it has to.

Audit your context before you audit your AI

If you are looking at inconsistent, contradictory, or oddly generic AI output across your organization, resist the urge to start with the tool. Start with three questions instead. Does a single source of truth actually exist, or does it live implicitly in the heads of people you have not lost yet? The marketing org found out the hard way that “we all basically know our brand voice” is not a source of truth. It is an assumption that survives only as long as the people who hold it stay in the room. Write it down, and write it down before you cut the humans who were quietly maintaining it. Is your context shaped at the right altitude, or has it defaulted to one of the two failure modes? If every team has its own model trained on its own slice of the world, you have dispersal by accident. If you have pointed one tool at everything and hoped scale would produce coherence, you have dilution by accident. Either way, nobody chose this. Someone needs to. And who is accountable for the connective tissue that used to be invisible labor? Before you eliminate a role, a vendor, or a budget line that has been absorbing inconsistency for years, ask what happens to that inconsistency once the absorption stops. It does not disappear. It surfaces, usually in front of a client or a regulator, at the worst possible moment, wearing a very confident, very fluent, completely wrong AI-generated deliverable. Naming the canonical layer is smaller work than most leaders expect, and that is exactly why it keeps getting skipped. It does not require a data platform migration or a six-month governance initiative. It requires someone in the room willing to say, on the record, “this is the version of our voice, our numbers, our brand that every team builds on top of, and here is what stays yours to decide locally.” That sentence is a facilitation act, not a technical one. Most organizations have simply never been forced to say it out loud, because the humans absorbing the gap never asked them to. This is not an argument against cutting the agency spend, and it is not an argument against giving teams AI tools. It is an argument for sequencing. Build the shared foundation first. Name who owns it. Decide, deliberately, what stays local and what has to be canonical. Only then let the speed loose on top of it, because speed on top of a shared foundation compounds, and speed on top of a fractured one just gets you to the fracture faster.

The savings were real. So was the bill that came due

The million dollars the medical-equipment maker cut from its agency budget was a real number, and the efficiency case for making that cut was not wrong. What was wrong was the assumption that the savings and the organizational debt were unrelated line items. They were not. The agencies had been the invisible interest payment on years of undocumented process, and the day the payment stopped, the debt came due all at once, in public, in AI’s voice. Every organization racing to consolidate spend into AI right now is making some version of this same bet, whether it knows it or not. The tool will do what you ask, faster than anything you have used before. It will not tell you that what you asked for was five different answers wearing one company’s logo. That is a question only a leader willing to look at the organization’s own foundation, and not just its tool stack, will think to ask before the invoice comes due. The next time an AI rollout produces something inconsistent, resist the reflex to retrain the model or reshuffle the vendor. Look instead at what the tool just made impossible to ignore. Then go fix that, because that was always the actual job. If you are staring at a pile of confident, contradictory AI output right now and you are not sure whether the problem is your model or your organization, that is worth a real conversation before you spend another dollar on either one.

The post Your AI Didn’t Break Your Team appeared first on Voltage Control.

Why Restricting AI Creates the Exact Problem You Were Trying to Prevent

When AI tools started showing up in enterprise workflows, the response from IT and legal departments followed a predictable sequence. Assess what employees are using. Identify what has not been approved. Block it at the browser or network level. Then wait for the approved tooling to catch up to the problem. That response makes sense on paper. The risks of unvetted AI tools are real: consumer AI products may train on what you feed them, compliance obligations around data handling are still evolving, and the liability questions are still being sorted in courtrooms. Caution was warranted. But there is a critical difference between caution and prohibition. And blanket prohibition has a failure mode that is worse than the risk it was designed to address. When you block AI tools without providing a sanctioned alternative, employees do not stop using AI. They route around you.

The Scale of What’s Happening Underground

This is not a fringe behavior at the edges of the workforce. It is the default response of most employees in organizations with restrictive AI policies. A 2026 PagerDuty survey of office professionals found that two-thirds of respondents, 66 percent, had used unauthorized AI tools at work in spite of explicit organizational policy. When Kong surveyed employees at companies with AI restrictions, 60 percent said they either ignored those restrictions or found ways around them. Twenty-six percent used personal devices. Another 24 percent used alternative browsers or technical workarounds to reach tools that were blocked. This pattern has a name: shadow AI. It refers to the unsanctioned use of AI tools without IT oversight, approval, or monitoring. It includes AI platforms accessed on personal email accounts, AI extensions installed outside enterprise device management, and AI features embedded in SaaS products that IT never noticed when the original tool was approved. Shadow AI governance, or the absence of it, is the problem most organizations are actually managing right now. Most of them do not know it.

The Visibility Trap

Here is what makes the lockdown approach so counterproductive. The premise of blocking AI tools is that it prevents risk. But once an employee is using AI on a personal account, via a personal device, outside any enterprise monitoring, you have not prevented the risk. You have made it invisible. The data being fed into that unmanaged personal AI account is the same sensitive data that would have gone into the approved tool. The difference is that now there is no audit trail, no visibility, no ability to respond when something goes wrong. There is also no way to know what went wrong until long after the fact. The organizations that experience the worst shadow AI outcomes are not the ones that tried to deploy AI tools and struggled to govern them. They are the ones that enforced prohibition confidently, assumed the problem was solved, and discovered eighteen months later that their employees had been routing work through personal AI subscriptions the entire time. Lockdown does not eliminate the risk. It relocates it to a place where you cannot manage it. This is the pattern that distinguishes productive friction from friction that only creates blind spots. Productive friction develops people or protects something real. A blanket prohibition without a sanctioned alternative is friction that builds nothing and protects nothing it claims to protect, because the risk moves rather than disappears. If you want to understand the difference between friction that does something and friction that just relocates risk, The Friction Discernment Test is worth reading alongside this.

What We Hear From Leaders in Regulated Industries

In conversations across our executive network, we hear a version of the same story with some consistency. A leader describes their organization’s AI policy: robust browser blocks, no approved enterprise tools yet, a security review queue for every new request, no exceptions while the official guidance catches up to the market. They describe it as a thoughtful, cautious approach. This is the policy as designed. Then, almost in the same breath, they describe what they are personally doing. Finding a workaround for a corporate chat tool so restricted it was functionally unusable. Running a personal AI subscription against their work email because the approved options could not meet the actual demand on their time. Quietly advising colleagues in their network to do the same. These are not bad actors. They are experienced, senior leaders in regulated environments who understand what AI can do and who have assessed the cost of being locked out of it. They know their organization’s risk posture better than most. And they are routing around the restrictions anyway, because the policy created an unworkable situation and offered no legitimate alternative. What they are describing is the rational response to an inadequate governance model. Shadow AI governance fails when the governance conversation is only about restriction. The person who has determined that AI will materially improve their work, and who has found every legitimate path to using it blocked, will find an illegitimate one. You have not addressed the underlying behavior. You have only ensured that it is invisible to you.

Shadow AI Governance That Actually Works

The organizations managing AI risk well are not the ones with the strictest restrictions. They are the ones with the most deliberately scoped allowances. The difference is not permissive versus restrictive. The difference is between undefined and defined. Broad prohibition without a sanctioned alternative is not a governance stance. It is an abdication that presents itself as caution. A policy that says employees may not use unsanctioned AI tools tells people what they cannot do but gives them no legitimate path to what they actually need to do. The behavior that follows from that policy is predictable. Shadow AI governance that works specifies what is allowed, at a level of practical detail. Not a vague principle but a working policy: these tools, for these purposes, with these constraints on what data may be included. That sentence creates a perimeter. A perimeter is something that can actually be managed, because it is defined. Within that defined perimeter, effective organizations run pilots before they scale. They do not deploy AI organization-wide on day one. They pick one function, define one use case, instrument it to understand what happens, and study what results. The pilot is both the safeguard and the evidence base. Real risks materialize in a controlled pilot, where they can be managed. Real capability becomes visible in the pilot, which builds the case for expanding access responsibly. The third element is the one most organizations skip, and it is arguably the most important: share the AI’s synthesis back to the group before discussion begins. One of the dynamics that sustains shadow AI behavior is that employees getting value from unauthorized tools have no legitimate channel to demonstrate that value. The knowledge stays private. The tool stays underground. The organization never develops a shared practice, because all the learning is happening in invisible individual silos. When organizations make AI synthesis visible in a room, when the tool’s output gets shared with the group as a starting point for discussion rather than a finished answer, the behavior that was happening underground becomes observable. The organization begins to develop a collective AI practice. Employees who were routing around restrictions find that the legitimate channel can provide the value they needed. And the organization gains visibility into what AI is actually producing, which is the only foundation on which real governance can be built.

Starting From the Right Question

Most AI governance conversations start with “what are we afraid of?” That impulse is understandable. The exposure from unmanaged AI use is real: researchers have found that 93 percent of employees admit to inputting confidential data into unapproved AI tools, including source code, customer records, financial projections, and legal documents. The compliance implications under GDPR, HIPAA, and similar frameworks are not hypothetical. But a governance conversation anchored in fear produces lockdown governance. And lockdown governance, as the evidence makes clear, addresses the fear while relocating the actual risk. The more productive question is: what would it take for employees to have legitimate access to AI tools that work well enough that they do not need workarounds? That question leads somewhere useful. It leads to defined allowances, scoped pilots, and visible behavior that the organization can actually measure and manage. The accountability argument matters here too. As we explored in the context of the Air Canada chatbot case and the iTutorGroup EEOC settlement, AI does not absorb organizational accountability. When something goes wrong, a decision made on an incorrect AI output, a sensitive document processed by a consumer tool with no enterprise controls, the organization remains responsible. That logic runs in both directions. You cannot hold people accountable for AI outputs they were never permitted to produce legitimately. And you cannot manage risks you have driven underground.

How to Start Building Shadow AI Governance

The first step is an honest audit. Before your organization defines its shadow AI governance stance, find out what AI is actually being used. Not what has been officially approved. What is actually running, including personal accounts, browser extensions, and AI features in tools you have already licensed. This conversation produces uncomfortable findings in most organizations. Leaders are often surprised by the gap between their stated policy and what is actually happening. But it is the only foundation for a governance framework that will hold, because governance built on a fictional baseline produces fictional outcomes. From that honest accounting, the work is definitional: specify what is allowed, for what purpose, with what constraints on data handling. Run a pilot in one function. Bring AI synthesis into the room, into the actual meetings where decisions get made, before discussion begins. Watch what happens. Adjust. That sequence, audit then define then pilot then share back, is shadow AI governance that works. It is not permissive. It is precise. And precision is what makes governance governable.

The Illusion of Control

The organizations that handle AI risk well are not the ones that banned everything first and asked questions later. They are the ones that understood what employees actually needed and built a framework capable of providing it under real conditions. Lockdown feels like control. It creates a clear line, a firm policy, a documented stance. But if employees are routing around it on personal accounts, using personal subscriptions against their work email, outside any monitoring, you have neither prevented the risk nor gained any ability to manage it. That is not governance. That is the appearance of governance. And it is more dangerous than no policy at all, because it convinces the organization that a problem has been addressed when it has actually been made worse. Real shadow AI governance starts with honesty about what is already happening. From there, the path is specific allowances, observable pilots, and AI practice that is shared rather than hidden. Not broader prohibition, not unlimited access, but defined and visible use that your organization can actually see and manage. The difference between those two approaches is not how much risk you are willing to tolerate. It is whether you can see the risk you have. Want to explore what an AI governance model that works looks like for your organization? Voltage Control’s AI transformation programs help leadership teams design AI practices that are both usable and manageable. Learn more about our approach.

The post Governance by Lockdown Is Not Governance appeared first on Voltage Control.

Most organizations are deploying AI agents. Almost none are building an agentic organization.

The term “agentic organization” is moving fast through the consulting lexicon. McKinsey published a multi-part series on it in early 2026 (McKinsey, “The agentic organization: Contours of the next paradigm for the AI era”). Gartner added it to its first standalone Hype Cycle for Agentic AI (April 2026). BCG (Leading in the Age of AI Agents: Managing the Machines That Manage Themselves), Accenture (Pulse of Change), and IBM (Agentic AI’s strategic ascent) have all staked positions. Most of them are pointing at the same thing: an organization where AI agents perform autonomous tasks at scale. Agents handle the tickets. Agents write the first draft. Agents process the exceptions. The promise is that by deploying enough agents, organizations can reduce the marginal cost of routine work toward zero. That is a real thing. It is also not what makes an organization agentic. The definitions circulating right now describe what you can do with AI agents. They do not describe what your organization needs to become to do it well. And that gap is where most agentic AI initiatives are failing. Here is a more useful definition. An agentic organization is one where humans and AI agents collaborate through structured governance, facilitation, and shared decision-making frameworks. Not AI doing tasks for humans. Humans and AI deciding together, inside structures built to make that collaboration effective. The distinction matters because it changes what you build. And right now, most organizations are building the wrong thing.

What Most Organizations Get Wrong

The 2026 data on enterprise AI tells a consistent story. Gartner forecasts that 40 percent of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5 percent in 2025 (gartner.com, 2025-08-26). The adoption rate is high. The operationalization rate is not. Gartner is predicting that more than 40 percent of agentic AI projects will be canceled by 2027, citing weak governance, unclear ROI, and cost overruns as the primary causes (gartner.com, 2025-06-25). An EY survey cited in the AIUC-1 Consortium’s 2026 security briefing found that 64 percent of companies with revenue above one billion dollars reported losses exceeding one million dollars from AI system failures in 2025 (Help Net Security, 2026-03-03).

This is not a technology story. The technology is working. The failure pattern is organizational. Most agentic AI deployments treat agents as sophisticated automation: give the agent a task, define the output, measure completion. What they skip is the question of how humans and agents work together on decisions that matter. Who decides when the agent’s output is correct? Who owns the accountability when it is not? What happens when human judgment and AI output conflict? These questions are not answered by the software. They require organizational design. And most organizations have not done that design work. There is also a governance gap that shows up in the data. Only 38 percent of organizations monitor AI traffic end-to-end, and only 17 percent continuously monitor agent-to-agent interactions (Cloud Security Alliance, citing the EY/AIUC-1 Consortium survey, 2026-04-03). The spread between organizations planning to deploy more AI agents (81.7 percent) and those that say all their agents are fully secured and governed before going live (19.7 percent) is roughly 62 points (Gravitee, State of AI Agent Security Report 2026, 750 senior technology leaders, surveyed April 2026). That gap does not close by deploying more agents.

The Facilitation Gap No One Is Talking About

Governance frameworks and operating models are necessary. McKinsey’s five-pillar framework for the agentic organization, covering business model, operating model, governance, workforce and culture, and technology (McKinsey, “The agentic organization: Contours of the next paradigm for the AI era”), is a reasonable map of the terrain. But a map is not the territory. The thing most frameworks miss is the facilitation layer. The actual moment when a team has to decide whether the AI agent’s recommendation is correct, whether to override it, whether to escalate. The real-time process by which humans and AI collaborate on a decision that matters. This is where organizations that think they are building agentic systems are actually building fragile ones. They have designed the agent. They have not designed the collaboration. Facilitation in this context means something precise. It means the structures, practices, and skills that allow a team to make high-quality decisions when AI is part of the process. It means knowing when to delegate to the agent and when to convene the humans. It means building the psychological safety that lets people challenge AI outputs rather than defer to them. It means creating feedback loops so that both the agents and the teams using them get better over time. Consider what happens when an AI agent surfaces a recommendation in a team meeting. Without facilitation, one of two things tends to occur. Either the team accepts the AI’s output because the apparent authority of a data-backed recommendation suppresses dissent. Or the team ignores it because the social dynamics of the room do not create space for integrating AI input with human judgment. Neither outcome is what you want. Both are predictable without the facilitation layer.

A Working Definition

An agentic organization has three characteristics that separate it from an organization that has simply deployed agents. The first is defined decision rights. The organization has mapped which decisions are appropriate for AI agents, which require human judgment, and which require genuine collaboration between both. That mapping is explicit and maintained. It was made deliberately, not by default. The second is facilitation infrastructure at the team level. Not just at the IT or governance level. The people who run meetings, workshops, and collaborative sessions know how to run them when AI is a participant. They have meeting structures that incorporate AI input without suppressing human judgment. They have escalation frameworks that activate when agent recommendations conflict with human intuitions. They have retrospective practices that capture what the collaboration produced and what it missed. The third is organizational trust. Not trust in the technology alone, though that matters. Trust among the humans in the room. Teams that cannot disagree with each other productively cannot disagree with AI outputs productively either. The organizations doing this well have invested in psychological safety, in diversity of perspective, and in the kind of facilitation that makes it safe to say “I think the agent is wrong about this.” Most organizations have made partial progress on the first characteristic. Very few have built the second or third.

What an Agentic Organization Looks Like in Practice

Three examples from the current landscape show what separates genuine agentic organizations from what is more accurately described as agentic theater. JPMorgan has deployed AI agents across more than 450 use cases in investment banking and beyond (Tearsheet, 2025). What makes the successful deployments work is not the AI itself. It is the redesigned workflow with explicit handoff points: the agent generates, a senior reviewer evaluates, the client receives. That structure clarifies what each actor is accountable for. The agent earns trust within its domain. Humans retain judgment at the decision points that carry real risk. The governance is built into the process, not added as a layer on top. Klarna’s AI assistant handled two-thirds of customer service chats in its first month (Klarna, Feb 2024), and the common reading of that success, “AI agents handled everything autonomously,” misses what happened next. Customer satisfaction dropped, and in May 2025 Klarna reversed course and began rehiring human agents (Forbes, 2025-05-18). The steady state today is AI handling roughly 70 percent of support volume, with humans managing escalations, policy exceptions, and relationship decisions. The escalation framework is the organizational design. The technology is the enabler. Remove the human layer and the system breaks. Walmart’s agentic inventory tools detect, diagnose, and correct stock-level issues in real time without requiring manual intervention on routine restocking decisions (Supply Chain Dive, 2025-10-07). That works because the domain is well-bounded, the decision criteria are explicit, and monitoring systems flag anomalies. The same approach applied to financial compliance decisions or customer-facing exceptions would not work. The organization made a deliberate choice about where autonomous execution is appropriate and where human gating is necessary. That choice is the organizational work. The pattern is consistent. The organizations succeeding with agentic AI are not removing humans from decisions. They are restructuring decision-making to separate low-risk autonomous actions from high-stakes collaborative ones. Everyone in the system, the agents, the humans, and the organization’s governance structures, knows the difference.

Three Capabilities That Separate Agentic Organizations from Agentic Theater

Three capabilities determine whether an organization is genuinely building agentic capability or investing heavily in sophisticated automation. The first is decision architecture. An agentic organization has mapped its decision landscape and assigned appropriate ownership to agents, to humans, and to human-agent collaboration. The mapping is documented, accessible, and updated when agents’ capabilities change or when the organization learns something new. This is not a one-time exercise. It is an ongoing organizational practice. The second is facilitation infrastructure. The team practices that make human-AI collaboration effective are designed and maintained intentionally. This means meeting structures that create space for human judgment even when AI input is present. It means escalation protocols that activate cleanly when the team needs to override an agent. It means debriefing practices that capture what worked and what the collaboration missed. These practices do not emerge spontaneously. They are built deliberately, the same way any high-performing team builds its working norms. The third is the organizational trust that makes productive disagreement possible. High-performing human teams have built norms around challenging each other’s assumptions. High-performing human-AI teams need those same norms, plus additional practices specific to AI collaboration: how to interpret agent confidence without deferring to it, how to recognize and interrupt over-reliance, how to maintain meaningful human oversight without creating friction that defeats the purpose. These three capabilities are not innate. They are built. And the organizations that will look meaningfully different in three years are the ones building them now, not waiting until the technology matures further.

How to Build an Agentic Organization

The path to an agentic organization runs through the human layer before the technology layer. That is a different starting point than most transformation programs assume, and it is the reason most transformation programs stall. Start with one decision domain. Find a decision your team makes frequently, where AI has clear informational input, and where the stakes of getting it wrong are real but recoverable. Design the collaboration explicitly: what does the agent produce? Who reviews it? What are the criteria for accepting versus overriding the agent’s output? When does a conflict between human judgment and AI output trigger escalation, and to whom? Run that collaboration in practice. Not as a pilot with a special team in a controlled environment. As the actual way the team works, starting now. Watch what emerges. Where does the agent earn trust? Where does it lose it? Where does the team fall into AI over-reliance? Where does it underuse the agent because the collaboration practices have not been established yet? From that lived experience, build the governance layer outward. Extend what worked. Redesign what did not. Add decision domains incrementally, carrying the practices that have proven themselves into each new area. The agentic organization is built from the inside out, from the teams doing the actual work. Top-down design and wholesale implementation produces the brittle outcomes the current data reflects. The facilitation skills are not optional in this process. They are the scaffold the whole structure rests on. Organizations that invest in the technology and skip the facilitation layer end up with capable automation and fragile outcomes. Organizations that develop both end up with teams that are genuinely better at deciding together because AI has become part of how they think.

The Organizations That Will Look Different

81.7 percent of organizations plan to deploy more AI agents in the next year. Only 19.7 percent say all their agents are fully secured and governed before going live (Gravitee, State of AI Agent Security Report 2026, 750 senior technology leaders, surveyed April 2026). That roughly 62-point spread is going to produce predictable results: more capability in the system, less accountability for its outputs, and more failures that a different organizational design would have prevented. The organizations that look different in three years are not the ones with the most agents. They are the ones that learned how to work with agents. How to govern them without strangling them. How to use them without deferring to them blindly. How to build the facilitation infrastructure that converts a technology deployment into a genuine organizational capability. That is what an agentic organization is. Not AI doing tasks autonomously. Humans and AI deciding together, inside structures built to make the collaboration effective. If your organization is at the beginning of that work, start with one decision domain. Design the collaboration deliberately. Build the facilitation practices alongside the technology. That is where the real transformation begins. Want to explore what this looks like for your organization? Voltage Control’s AI Transformation Program is built around exactly this work.

The post What Is an Agentic Organization? Definition, Examples, and How to Build One appeared first on Voltage Control.

Make AI agents discoverable, addressable, and accountable to clear lines of authority, without treating them as coworkers

Your AI agents need a place on the org chart. They do not need a seat at the table. Most of the conversation about enterprise AI agents and the org chart has collapsed into two bad options. One camp drops agents onto the chart as digital employees, complete with titles, reporting lines, and the occasional welcome announcement. The other camp keeps them off entirely, filed away as software that lives somewhere in IT. Both camps are reacting to something real. Both get it wrong. The org chart is a system of record. It answers practical questions: what exists here, what does it do, who owns it, and who is allowed to ask it for something. Agents increasingly need to answer all four. Leaving them off the chart doesn’t make them tools. It makes them invisible. But listing an agent is not the same as treating it as a peer. The moment an agent sits beside your people as an equal, accountability blurs and the humans next to it get diminished. The work is to do the first without the second.

Why Leaving Agents Off the Chart Fails

The case for keeping agents off is mostly a governance case. Agents are software, so they should live in the systems that already govern software: the ticketing system, the CRM, the identity provider. That is right about governance. It is wrong about visibility. An agent buried inside a single system is visible to that system’s administrators and almost no one else. Now multiply it. Sales ops builds an agent that enriches leads. Finance builds one that reconciles invoices. Someone in marketing connects one to the CMS. Each lives in a different tool, configured by a different person, with whatever permissions were easiest to grant. Ask the basic questions and nobody can answer them. How many agents do we run? What can each one touch? If the reconciliation agent does something strange, who do I call? If my team needs something from it, does it even exist, and who am I allowed to ask? This is shadow IT in a new form, and it is already here. In an August 2026 survey of 202 IT and security leaders at large enterprises, 94 percent said they were confident their AI agents did not have more access than they needed. Only 33 percent actually provisioned agents with least-privilege access, and 65 percent had already seen an agent take an action outside its intended scope (Cequence Security and Enterprise Management Associates, “Agents Without Guardrails: The Agentic AI Governance Gap in the Enterprise,” August 31, 2026). Confidence without inventory is not governance. You cannot govern what you cannot find. The identity layer is already moving in this direction. At its Build conference in May 2025, Microsoft introduced Entra Agent ID, which gives AI agents their own identities so administrators can inventory them and apply the same access controls, audit trails, and lifecycle policies they use for human accounts (Redmond Magazine, “Microsoft Unveils Future for AI Agents at Build 2025,” May 19, 2025). The directory is where your organization records what exists and who is responsible for it. Agents belong there.

Why Treating Agents as Coworkers Fails

The opposite mistake costs just as much, and the “agents as employees” crowd keeps making it. When an agent shows up on the chart as a colleague, people stop evaluating it as a system. A BCG Henderson Institute study of more than 1,200 managers found that framing shapes how people calibrate trust in AI: when AI was framed as an employee rather than a tool, managers caught 18% fewer errors and individual accountability for mistakes dropped 9 percentage points (Harvard Business Review, “Research: Why You Shouldn’t Treat AI Agents Like Employees,” May 6, 2026). That is the trust problem. Frame an agent as infrastructure and it invites useful skepticism: does it work, when does it fail, what do I do with a bad output? Frame it as a colleague and the social dynamics take over. Peers trigger comparison and competition. Supervisors trigger compliance and quiet resentment, especially when the agent controls routing, prioritization, or approvals. There is also a deeper cost, and it is easy to miss. When an agent appears on the chart as an equal, with a title like “Digital Analyst” and a box the same size as the person beside it, the message to that person is unmistakable. Your role is a bundle of tasks, and something else can hold it too. That is dehumanizing. It reduces people to throughput. People are on the org chart because they hold judgment, relationships, and responsibility for outcomes. They can be asked why. They answer for what happens. An agent holds none of that. Placing the two side by side as equivalents flattens what it means to be a person in your organization, and your people will notice long before your leadership team does. Accountability suffers too. Org charts exist to make accountability legible. If an agent is officially a member of the team, the question “who owns this outcome?” gets a slippery answer. Everyone assumes someone else is responsible for what the agent does. The answer can never be “the agent decided.” Someone designed, configured, and deployed it.

Listed, Not Equal

So what does a good org chart entry for an agent look like? It makes the agent discoverable, addressable, and governed, while making its difference from people obvious at a glance. Start with discoverability. Every agent gets an entry: what it is for, what systems it can touch, and what it produces. When someone wonders whether the organization already has an agent that handles a task, they can look it up instead of building a second one. Then make it addressable. Every agent needs a known way to receive work. Not a hallway ask or a direct message to whoever built it, but a defined channel: a request queue, a ticket type, a written brief. An agent you can find but cannot reach is decoration. Next, draw the lines of authority. This is where the chart earns its keep. For each agent, the record should name who can assign it work, who can change its scope or configuration, and who can shut it off. These are rarely the same people. A sales team might be allowed to task the lead-enrichment agent. Only the operations owner can widen the data it reads. Nobody should be able to task an agent simply because they found its endpoint. Every agent also hangs beneath a named human owner. The agent does not have a manager the way an employee does. It has an owner, the way a critical system does. When it errs, “who owns this?” has a one-name answer, and that person answers for the outcome. Finally, make agents look different. Use a different shape, a different color, or a separate layer that can be toggled on and off. Describe them by function, “invoice reconciliation agent,” not with titles borrowed from people, like “AP Specialist.” The chart should make it impossible to mistake an agent for a colleague. That is the whole distinction. Listed, owned, addressable, and governed. Never a peer.

What This Looks Like in Practice

We run Voltage Control’s own operations with a team of AI agents, and we built it this way because we hit the problems above early. Our agents live in a single roster that acts as their system of record. Each one has a defined scope and a human owner. Work reaches an agent through a written brief that records who asked, what was asked, and what came back. Agents can hand work to one another, but every brief traces back to a person, and the authority to change what an agent is allowed to do sits with a person, not with another agent. Nothing an agent produces reaches a client until a person has reviewed it. The payoff is mundane in the best way. When something goes wrong, we can trace it: which brief, which agent, which person asked. When someone wonders whether we already have an agent for something, they check the roster. And the accountability conversation never stalls on the question of whose job the agent’s output was. It was always a person’s.

Tighten Authority as Autonomy Grows

Not every agent needs the same lines of authority. The right structure depends on how much the agent decides on its own. Task-scoped agents do one bounded thing: summarize a document, route a ticket by rule, draft a first pass. Authority to task them can be broad. Governance is light: define the scope, set quality standards, and audit periodically for drift. Process agents orchestrate a chain of steps across systems. A procurement agent might check inventory, verify budget authority, route for approval, and update the ERP. Each step is routine, but failure modes multiply at every junction. Narrow who can task them, and document escalation paths before deployment. What triggers human review? What happens when a step returns something unexpected? Those are design requirements, not retrospective questions. Judgment agents make consequential calls where no rule determines the answer. These need the tightest lines of all. Bound explicitly what the agent can decide without review. Log its decisions with enough context to reconstruct the reasoning. Run structured human review on a sample large enough to catch systematic errors before they compound. Most organizations are not ready to run judgment agents responsibly, and that is a sequencing point, not a criticism. Build the muscle on task-scoped agents. Develop escalation discipline on process agents. Earn your way to judgment when the infrastructure for auditing it is in place, not when the business pressure is loudest.

What Leaders Need to Do Now

If you are a VP, CIO, or Chief Transformation Officer, start with two diagnostic questions. First, can anyone find every agent your organization runs? If the honest answer is no, you have an inventory problem before you have a framing problem. Get every agent onto the chart or into the directory your organization treats as its source of truth, with an owner, a scope, and a channel for requesting work. Second, how are those agents positioned relative to your people? Look for agents with human job titles, agents placed in peer reporting lines, and teams that refer to an agent as a colleague. Change the framing before it hardens into performance reviews, escalation policies, and governance documents. Then draw the lines of authority for each agent, and tighten them as autonomy grows. Who can task it, who can change it, who can stop it, and who owns what it does. The organizations that work through this see consistent results. Adoption improves because people have an accurate mental model of what they are working with. Accountability stays with humans, so leadership can actually manage outcomes. Security and compliance teams work within governance they already understand.

The Chart Is for Clarity

The question isn’t whether agents belong on the org chart. They do. The question is how they belong there. Put them there the way you record critical systems: listed, owned, reachable, and governed. Not the way you record people. The org chart exists to make an organization legible, and it is at its best when it makes two things obvious at once: everything that does work here, and the people who answer for it. Get that distinction right and your agents become easier to find, easier to use, and easier to trust. Your people stay what they have always been: the ones with judgment, the ones who own the outcome. If you’re working through where AI agents fit in your organization’s operating model, Voltage Control’s AI transformation consulting practice helps leadership teams design the governance structures, accountability frameworks, and change management approaches that make agentic AI work for people.

The post Put Agents on the Org Chart appeared first on Voltage Control.

What to Expect and How to Choose the Right Partner

The consulting industry has a name problem. If you search “AI transformation consulting,” you will find firms promising end-to-end transformation: strategy, implementation, change management, results. What most of them deliver is something narrower. AI implementation with transformation language attached. The distinction matters more than the marketing suggests. Technology implementation consulting and organizational transformation consulting are different disciplines with different success metrics and different failure modes. Getting that distinction wrong before you sign an engagement is how companies end up with working AI tools and an organization that has not actually changed. Here is the actual problem most AI transformation initiatives are trying to solve: not how to deploy AI, but how to get people to work differently after the deployment. That is an organizational problem, not a technology problem. And the organizations that hire for technology expertise when they need organizational change capability are building on the wrong foundation.

The Most Common Failure Pattern

The evidence here is consistent. Across dozens of executive conversations with leaders across enterprise technology, financial services, and healthcare organizations, the same pattern surfaces. Companies start with the technology. They pick tools, negotiate licenses, stand up infrastructure, and begin rolling it out to the workforce. Training programs spike tool adoption on day one, then drop to near zero within weeks. Workflow automations get built on top of broken processes, making those processes faster and harder to fix. The AI tools produce output, but the organization’s decision-making velocity does not change, because the bottleneck was never execution. It was alignment. The practitioner formulation that captures this most precisely came from a cross-industry conversation among enterprise operations leaders: do not automate a bad process. Workflow automation speeds up whatever process you put into it. If the process has coordination problems, unclear ownership, or misaligned incentives, the AI version will surface those problems faster and at greater scale than the human version ever could. This is what a genuine AI transformation consultant should be diagnosing before anything else. Not which tools to use or whether your data is ready. What decisions your organization needs to make differently, and what is currently slowing them down.

What the Research Shows About Where This Goes Wrong

There’s a name worth giving to what happens when organizations skip this step: a growing gap between apparent efficiency and adaptive capacity. Agentic AI removes operational friction without replacing the sensing and learning loops that friction carried. Organizations that automate aggressively without maintaining judgment capacity end up more efficient and more fragile at the same time. Recent research on enterprise agentic AI governance reinforces this pattern: implementations that start with governance frameworks tend to achieve markedly higher production success rates than those that retrofit governance after the fact. The framing most technology-first consultants use treats governance as a constraint on speed. The data says governance is what enables sustainable speed. If your AI transformation consulting engagement is not spending substantive time on governance, accountability structures, and decision-rights before touching the technology stack, it is probably not a transformation engagement.

Technology Implementation vs. Organizational Transformation

Technology implementation consulting and organizational transformation consulting have different questions at their center. Technology consulting asks: which AI tools should we deploy, to which workflows, on what timeline? Organizational transformation consulting asks: what decisions is this organization trying to make faster? What is currently slowing them down? And how does AI change the constraint? The second set of questions is harder to answer and takes longer to work through. It requires understanding how work actually flows through the organization, not just how it is supposed to flow. It requires naming the frictions that no one has formally acknowledged. It requires building the facilitation capacity to surface those conversations in rooms where people have historically avoided them. This is what Voltage Control calls the New Friction. When AI collapses execution time, the organizational constraint shifts. The hard work is no longer getting things done. It is getting people to decide what to do, agree on why, and align fast enough to act. That shift is happening in every organization right now, and most AI transformation programs are optimizing for the wrong bottleneck.

What to Look For in a Partner

The clearest signal that a consulting firm understands this distinction is whether they start by auditing your organization’s decision-making before they touch your technology. Ask your prospective consultants: how do you identify where our AI investment will actually get stuck? If the answer is primarily technical, covering model selection, data readiness, integration complexity, that tells you something about their orientation. If the answer involves mapping real workflows, surfacing unspoken friction, and building the facilitation capability to have the hard organizational conversations, that is a different kind of practice. Other useful questions worth asking: What do they do when they find a bad process? A technology-first firm will often optimize around it. An organizational transformation firm will stop and redesign the process before building the AI layer on top of it. Ask specifically how they have handled this situation with a past client. What does success look like in the first three months? If the metrics are primarily about tool adoption rates and deployment breadth, the engagement is optimizing for implementation activity. If the metrics include alignment speed, decision quality, and whether freed capacity is being deliberately redirected to higher-value work, you are looking at a different kind of outcome orientation. As one executive put it: if this initiative does not map to top line, bottom line, earnings, or customer growth, nobody in the C-suite wants to hear about it. Those are the metrics that matter. Can they tell you when you are not ready? This is one of the more reliable tests of whether a consulting firm is operating in your interest or in their own. More on this below.

What an Engagement with Voltage Control Looks Like

VC’s work starts with a diagnostic, not a deployment plan. The diagnostic phase identifies where the real organizational friction lives. This is not a survey or a stakeholder interview series. It is a structured facilitation process that surfaces the decisions organizations are avoiding, the alignment gaps they have learned to work around, and the places where AI is most likely to expose existing weakness rather than create new capability. From that foundation, the work moves to building AI capability at the team level. Not through one-time training events, which the evidence consistently shows decay within weeks, but through live practice in real workflows with human facilitation to process what is working and what is not. The Spark framework, one of VC’s core operating approaches, builds capability through leadership modeling, guided practice, and reflection loops rather than through curriculum delivery. The engagement shape that most consistently produces durable results has four phases: diagnostic and alignment in the first month, foundation building in months two and three, practice and expansion from months three through six, and institutionalization after that. The timeline varies by organization size and complexity. The sequence is not optional. Organizations that compress or skip phases tend to end up back in implementation mode. VC’s facilitation-first methodology also addresses what happens at the team level when AI is deployed. Individual productivity gains from AI tools do not automatically aggregate into organizational capability. Getting teams to use AI together, with shared prompts, shared outputs, and shared correction, produces different and more durable outcomes than getting individuals to use AI separately. Multiplayer AI capability building is not a feature of most AI transformation programs. It should be.

When You Need It vs. When You Don’t

This is the section most consulting firms leave out. You probably do not need an AI transformation consulting engagement if you have not yet defined what organizational problem you are trying to solve. If the driver is “we need to be doing AI,” that is a competitive anxiety statement, not a transformation objective. It will produce an implementation project optimized for visible activity rather than organizational change. You probably do not need an AI transformation partner if your leadership team is not personally using AI tools in their actual work. The most reliable predictor of a failed AI transformation program is a senior leadership team mandating AI adoption while exempting themselves from the learning curve. If leaders are coaching a sport they have never played, the coaching will be abstract and the workforce will know it. You probably do not need outside help if your primary bottleneck is technical, not organizational. If you have clear alignment on what you are trying to accomplish, a competent internal team, and a governance framework already in place, a technology implementation partner is the right resource. Bringing in organizational transformation consulting when you have an implementation problem is the wrong tool for the job. You probably do need an organizational transformation partner if your AI tools are working but your organizational behavior is not changing. If adoption is strong but decision velocity is the same, if you have freed capacity that is evaporating rather than being redirected to higher-value work, or if your AI rollout is surfacing coordination problems that no one wants to name, you are dealing with an organizational problem that technology cannot solve.

The Right Evaluation

Most organizations that are underserved by their AI transformation engagements had the same problem at the start. They evaluated their consulting partner primarily on technical capability: tool experience, implementation credentials, reference clients in adjacent industries. The more useful evaluation asks a different question: does this firm understand the organizational constraints that are going to make our AI investment fail, and do they have a method for working through those constraints? That question tends to surface a different kind of partner. If you want to explore what this looks like for your organization, the right starting point is a diagnostic conversation with our team, not a proposal. Understanding where your real friction lives before you build anything is what separates organizations that get durable AI transformation from organizations that get expensive AI implementations. Voltage Control’s corporate AI programs are built around this diagnostic-first model. The goal is not to deploy AI faster. The goal is to make your organization capable of working differently.

The post AI Transformation Consulting appeared first on Voltage Control.

The Governance System You Already Trust Is the One You Use for People

Every organization already runs a governance system for powerful, capable, unproven newcomers. It is called hiring. When a talented person joins your company, nobody hands them admin rights to the finance system on day one. Nobody tells them to figure out their own job. Nobody waives the review process because they interviewed well. They get the access the role needs, a clear description of what they own, and a manager who checks the work until trust is earned. Then their scope grows. We have refined this system for a century. It mostly works. And when AI arrived, most organizations forgot all of it. Instead, they reached for one of two responses. Some locked AI out entirely and waited for policy to catch up. Others let it in with no structure at all and hoped for the best. Both feel like decisions. Neither is governance. The better move is hiding in plain sight. Govern AI like you hire. That is the whole AI governance framework: give AI tools and agents the same least-privilege access, the same defined roles, and the same review rigor you give a new hire. Done this way, governance stops being the brake on AI adoption and becomes the thing that lets you go faster.

The Two Ways Organizations Get This Wrong

The first failure is the lockdown. Block the tools, route every request through a security queue, and treat AI use as a violation until proven otherwise. The intent is responsible. The result is not. People who have seen what AI can do for their work do not stop using it because a policy says so. They take it home. Microsoft and LinkedIn’s 2024 Work Trend Index found that 78 percent of AI users were bringing their own AI tools to work, while only 39 percent of people using AI at work had received any AI training from their company. We see this pattern directly. At one regulated services firm we have spoken with, fear-driven rules did not reduce AI use. They pushed it underground, into personal accounts nobody could see. The risk did not disappear. It became invisible, which is worse. The second failure is the open door. Tools get adopted team by team, agents get connected to systems with whatever permissions were easiest to grant, and nobody can say with confidence what has access to what. A leader we spoke with recently described the fear to us in two words: the Wild West. That fear is well founded. In an August 2026 survey of 202 IT and security leaders at large enterprises, 94 percent said they were confident their AI agents did not have more access than they needed. Only 33 percent actually provisioned agents with least-privilege access. And 65 percent had already seen an agent take an action outside its intended scope. Ninety-four percent confident. Thirty-three percent actually doing it. That gap is not a technology problem. It is a governance problem, and it is the same one you would have if you onboarded people without ever defining their access.

Three Pillars of an AI Governance Framework, Borrowed From Hiring

Here’s what makes the hiring frame so useful. It is not a new policy language. Every manager, every IT lead, and every compliance officer already understands how it works. You do not need to train anyone on the concept. You only need to point at it. The system has three parts, and each one translates directly into a pillar of AI governance: least-privilege access, defined roles, and the same review rigor.

Least-Privilege Access

A new hire gets access to what the job requires, and nothing more. A new accounts payable analyst can see invoices. They cannot change vendor bank details. As they prove themselves, access expands. AI deserves the same treatment. The security community already agrees on this. The OWASP guidance on LLM risk names “excessive agency” as a core vulnerability and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. Its first-line mitigation is plain: “Limit the permissions that LLM extensions are granted to other systems to the minimum necessary.” If an agent only needs to read a ticket queue, it should not be able to close tickets. If an assistant only needs to summarize contracts, it should not be able to send them. This is not exotic security engineering. It is the same principle your identity team applies to every human account, and it is the foundation of AI agent governance.

Defined Roles

Nobody hires without a job description. The description tells the new person what they own, what they do not own, who they answer to, and what good looks like. Most AI deployments skip this step. A tool gets licensed, or an agent gets built, and its purpose lives in the head of whoever set it up. When something goes wrong, nobody can say whether the agent did what it was supposed to do, because nobody wrote down what it was supposed to do. Give every agent a job description. One page is enough. What outcome is it responsible for? What systems can it touch? Which human owns its work? When does it escalate instead of acting? To be clear about the limits of the metaphor: this is not an argument for treating agents as employees. An agent can be listed on the org chart so people can find it and know who directs it, but it does not get a seat at the table or a performance review. Accountability for its work stays with a named person. The role description lives where your access controls and service records already live, so the agent is governed like a role without being treated like a colleague.

The Same Review Rigor

New hires do not ship unreviewed work in their first month. Code gets reviewed. Client deliverables get a second set of eyes. The rigor matches the stakes, and it relaxes as trust builds. AI output deserves exactly that, no more and no less. Two failure modes show up here. Some teams give AI output a pass because a machine produced it and it looks polished. Others hold AI to a standard of perfection they would never apply to a talented junior employee, so nothing ever ships. OWASP’s guidance points to the middle path: use human approval for high-impact actions before they are taken. Review proportionate to stakes is how you already treat people. It is the right way to treat AI.

Why This Speeds You Up Instead of Slowing You Down

Most leaders hear “governance” and brace for delay. That reaction makes sense when governance means a committee that says no. It does not hold when governance means clear rules that people trust. Charles Hoskinson, co-founder of Cardano, put the mechanism better than any framework document I have read. On the Facilitation Lab podcast, he described the historical pattern this way: “high trust things tend to have low bureaucracy and low trust things tend to have high bureaucracy.” His explanation of why: “The bureaucracy’s purpose is to de-risk.” That is the whole case for governing AI like you hire. When nobody knows what an agent can touch, every new use case needs a meeting, a review, and a sign-off, because every new use case is an unknown risk. When access, role, and review are defined up front, the risk is already bounded. Teams can move without asking permission for every step, because the permission is built into the structure. Clear governance is what lets you say yes quickly. Unclear governance forces you to say maybe, slowly, forever. This is why we describe the current moment as the New Friction. AI has collapsed the cost of execution. The friction did not vanish. It moved to trust, alignment, and governance. Organizations that treat governance as paperwork will feel that friction as drag. Organizations that design it well will turn it into speed.

Let People Earn Access: The AI Driver’s License

Hiring has one more lesson worth borrowing. Access is earned, not assumed and not denied. We do not ban cars because some people drive badly. We also do not hand the keys to anyone who asks. We license drivers. You show you can operate the vehicle under the rules of the road, and you get the right to drive. Higher-stakes vehicles require a higher-stakes license. Apply the same logic to AI inside your organization. Instead of a blanket yes or a blanket no, create a path where people earn tool access by showing they can use AI well under your rules. A learner’s permit might cover sanctioned tools on non-sensitive work. A full license might open access to customer data or internal systems. Building agents that take actions on their own might require something closer to a commercial license. The test should be practical, not a compliance quiz. Can this person get a useful result? Can they spot a weak or fabricated answer? Do they know what data never goes into a prompt? Those are the skills that actually reduce risk. A driver’s license does two things a lockdown cannot. It brings shadow AI above ground, because the legitimate path is now faster than the workaround. And it gives you visibility into who is using what, at what level of skill, which is exactly what a lockdown destroys.

Governance People Help Write Is Governance People Follow

There is a final piece of the hiring system that often gets missed. The best onboarding is not imposed. It is shaped by the people who do the work. We learned this at a scale few organizations ever attempt. Voltage Control facilitators designed and led the workshops through which the Cardano blockchain community wrote its constitution, with community members in 50 countries drafting, debating, and revising the document that now governs their ecosystem. Hoskinson called the investment in that facilitation process “an incredibly powerful move for our organization,” and described what it produced: “It built genuine trust across a diverse global community, laid a stronger foundation for collaboration, and set the stage for the next wave of innovation in our ecosystem.” Skeptics expected it to fail. Hoskinson recalled what people told him at the first workshop: “You’re just not going to pull this off.” It did not. And his explanation of why it held is the most important governance insight in this post: when people build things together, “it connects them, it draws them closer, it becomes their artifact. They’ve had some say in some participation in it, so they own it.” Your AI governance policy works the same way. Rules written in a back room by legal and IT get routed around. Rules shaped with the people who will live under them get followed, because they are theirs. This is the same move we argued for in Involve Before You Mandate. It applies doubly to governance. It also explains a shift we are seeing in how organizations structure AI ownership. One new CTO we spoke with did not want a Center of Excellence that controls AI from the center. The CTO wanted an AI Enablement board that helps the whole organization use it well. That is the difference between a gatekeeper and a hiring manager. One decides who gets in. The other makes sure the people who get in can succeed.

How This Connects to the Work Ahead

Governing AI like you hire is not a standalone policy idea. It builds directly on the three competencies we see separating organizations that make AI stick from those that stall. Orient to outcomes. A role description starts with the outcome the role exists to deliver. The same is true for an agent. If you cannot name the outcome, you cannot scope the access. Rebuild rituals. Review rigor only works if your review rituals can keep pace with machine-speed output. Most cannot yet. That is a ritual design problem, not a reason to skip review. Delegate deliberately. Least privilege is delegation discipline. As we wrote in From Maker to Manager, using AI well is a management skill. Deciding what an agent may and may not do is the core of that skill.

What to Do This Week

Start small and concrete. Pick one AI tool or agent already in use on your team. Write its job description on a single page: the outcome it owns, the systems it can touch, the person accountable for its work, and the point where it must hand off to a human. Then compare that page to reality. What can it actually access today? If the answer is broader than the job description, you have found your first governance fix, and it took an afternoon, not a committee. Next, name the review ritual. Who checks its output, how often, and what happens when the work is wrong? If nobody can answer, that is your second fix. Finally, ask your team where they are using AI that you have not sanctioned. Ask it with curiosity, not as an audit. Every answer tells you where your legitimate path is too slow, and where a driver’s license would bring work back into the light. The organizations that govern AI like they hire will move faster than the ones still debating whether to let it in, because their people will know exactly how far they can go and how to go further. The rest will keep choosing between a lockdown nobody follows and an open door nobody can see through. If you are wrestling with how to set up an AI governance framework your people will actually follow, talk with us. Helping organizations design governance together, with the people who will live under it, is exactly the work we do.

The post Govern AI Like You Hire appeared first on Voltage Control.

In this episode of the New Friction podcast, host Douglas Ferguson interviews Bryon Jacob, a technology advisor and AI strategist who previously co-founded data.world as CTO and spent a decade at HomeAway. Jacob argues that the teams succeeding with AI-assisted software development share one thing in common: rigorous governance — including near-100% automated test coverage, strictly enforced architectural standards, and code bases deliberately organized for agentic development. He explains why zero tech debt has shifted from aspirational to economically necessary, since AI amplifies good patterns and railroads bad ones, making clean, well-documented, thoroughly tested code the prerequisite for real productivity gains. The conversation examines how leaders are rethinking code review, prototyping, and the entire software development lifecycle, including why a CEO drafting a pull request in Claude Code is a fundamentally better spec than any design brief. Jacob closes by drawing the arc from assembly language to compilers to natural language programming, framing today’s moment as the natural next step in a decades-long evolution — and a preview of the governance-driven transformation already coming for legal and every other structured profession.

Show Highlights

[00:00:00] Introduction and the New Friction Premise
[00:02:15] How AI Is Already Reshaping Engineering
[00:07:30] Governance as the True Differentiator
[00:14:00] Scaling Code Review Beyond Human Limits
[00:21:00] CEO Pull Requests and Prototyping Culture
[00:28:00] Code Base Shape and the AI Readiness Gap
[00:35:00] Zero Tech Debt as New Engineering Mandate
[00:43:00] Greenfield First to Win Over Skeptics
[00:56:00] Software Engineering as Canary in the Coal Mine

Links | Resources

Bryon Jacob on LinkedIn
Voltage Control

About the Guest

Bryon Jacob is an independent technology advisor and AI strategist based in Austin, Texas, working with early-stage startups on technology strategy, AI implementation, and fundraising. He previously served as Chief Technology Officer at data.world, a collaborative data platform he co-founded in 2016 and led through its acquisition by ServiceNow, and before that spent a decade at HomeAway (now VRBO), joining shortly after founding and staying through the company’s IPO and its acquisition by Expedia. His interest in AI dates to graduate school at Case Western Reserve University, where he studied symbolic AI and machine learning, and he has authored widely cited research on how knowledge graphs can improve large language models’ accuracy over structured data. He is a founding board member of the Texas AI Alliance.

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free, so why are organizations still stuck? Because the friction didn’t disappear, it moved and it multiplied. It’s no longer in the building, it’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore. The conversation before the work is. That’s the work this show is about. Today, I’m with Bryon Jacob, a technology advisor and AI strategist based in Austin, Texas. He previously co-founded data.world as its CTO, leading the company through a successful acquisition and has over two decades of experience in tech, including leadership roles at Amazon and HomeAway, now Vrbo. Welcome to the show, Bryon.

Bryon Jacob: Thanks, Doug. Great to be here.

Douglas Ferguson: Looking forward to chatting. And as you know, we’re here to talk about how AI is reshaping roles, especially in the engineering and product. And I think that’s a great place to dive into. I know you have a lot of thoughts there and you’ve been helping a lot of organizations think about what that means. And what have you been noticing as far as the biggest shifts that have happened so far?

Bryon Jacob: Yeah, I mean, I think software engineering is one of the first things to massively transform. And I think a lot of it has to do with the fact that obviously technologists are probably paying more attention to AI, maybe want to be on the earlier edge. But I think a lot of it too comes down to really using AI responsibly to do any job, using it effectively and responsibly to do any job ultimately comes down to what kind of governance do you put on it? And software engineering and the software development lifecycle is essentially a governance regime for how we do software. And it’s one that’s pretty well understood. It’s got a million different flavors and permutations, and technology leaders could talk forever about their preferred variance of SDLC, but everyone doing software for real is executing some kind of governed SDLC. And SDLC is something that usually in software engineering, we have a ton of tooling. Engineers are great at automating everything that can be automated. Forget automating with AI, deterministic automation of things like your CI/CD pipelines, things like that. I think that’s one of the things that’s basically enabled this to be one of the first jobs that can really meaningfully be transformed with AI, because the things it takes to actually govern it, which is what you have to do to get good utility out of it and do it in a safe and responsible way, they already exist. And so most of what we’re doing is really just automating things we already knew how to automate, and then just automating them at a much bigger scale.

Douglas Ferguson: Yeah, I mean that’s a valid point. The other thing is after years and years of automating things, we understand the boundaries where our existing automations were limited.

Bryon Jacob: Yep.

Douglas Ferguson: And so we see these tools and we immediately go, “Oh, I can now add some inference here and get past something where it was difficult to do before.”

Bryon Jacob: Yeah, absolutely. I mean, I think people are trying to use AI to build software. You can find people who are saying, “This doesn’t work at all. All it does is create more tech debt. This is just creating more problems.” Senior engineers are complaining, because all they do is get PRs from junior engineers that they vibe coded with no understanding and shipped without even reading them. Those stories are real, that’s definitely happening. But then you also hear the stories of teams who are getting 5X, 10X of throughput. They’re running 95, 99% of their code with AI and shipping better than ever, that’s also real. Both things are really happening in the real world. And the delta is… And it’s not tools and models, I mean, I mean tools and models are great, Fable is amazing and now everyone loves the latest codex models and it’s all fine, but you’ve been able to do almost fully automated software development where AI is writing 98 plus percent of your code on most problems since at least call it Sonnet 3.5 or wherever you want to draw the bar. The models keep getting incrementally better, but that’s not the fundamental shift. The fundamental shift is how you use them. And is your code base organized in a way that AI can make sense of it? AI is just going to go in there and start copying patterns. If you have good patterns, it copies good patterns. If you have bad patterns, it railbends tech debt into your app. And the ROI has flipped. The return on having clean, perfect or well architected code that’s really well documented and has amazing testing and super high quality bar, is if you have code like that, AI can write that code, AI can work in that code base, AI can add features to it. And the investment side has gone way down, because who’s really great at going and writing a thousand unit tests to characterize your code? That same AI. So it’s like if you get into this cycle of reinvesting the dividends, basically take some of this newfound engineering capacity and use it to basically say, “We’re going to operate in a world where we don’t have tech debt,” low tech debt and high efficiency with AI are two sides of the same coin.

Douglas Ferguson: Yeah.

Bryon Jacob: You have to have one to get the other and you can’t do either one without the other. Yeah.

Douglas Ferguson: The other thing that came to mind too is your point around the junior engineer vibe coding stuff that they don’t understand, I would argue comes back to, if that’s one of the things that delineates the organizations where it’s not working, that also comes back to the fact that they don’t have good governance. Because I would argue that part of your software development governance should be that anyone committing code or any of PR getting approved, that whoever’s submitting it needs to be able to understand and explain the code that they’re submitting. If they can’t, kick it back until they can explain it, because it’s okay “to vibe code something,” but you need to study it, understand it, critique it and decide what needs to be changed.

Bryon Jacob: Yeah, I agree with that. Although, I agree with a caveat, and I wonder how much we agree on this, because this is another interesting scene that always is like… Definitely, I mean 100%, if you’re submitting code for a pull request, you’re responsible for it. The only thing that can take responsibility for a code change is a human, period. Maybe that changes in the future too, but at this point there has to be a governance system and you have to say there’s a person who’s accountable for that change. So I would agree with everything you said that the nuance is, I think we’re evolving quickly to a world where the bar can’t be a human thoroughly reviews every line of code. So not only do I not write almost any of the code that I’m responsible for anymore, I also don’t read every line of the code. Again, it’s automating more and more of this governance structure. So I’m directing AI on what needs to be written. I’m making sure that it’s writing it into a system where it’s going to make good choices and it almost can’t help but to make good choices, and then I’m reviewing it with more AI agents who I know embody the ideals that I would want to see and have an attention to detail and an inability to get bored and miss something that is actually an improvement over me. Mostly, what I’m doing, is I’m reviewing the review.

Douglas Ferguson: Yeah.

Bryon Jacob: Mostly, I’m putting everything through a system of automated review, reviewing that review, and again, still thoroughly and diligently, but with much higher efficiency and much higher bandwidth. And I would say, the majority of the pull requests I review, I approve, go through with me having looked at only a small amount of the actual code. That’s controversial. A lot of people hate that idea.

Douglas Ferguson: Yeah, well, I would argue that the folks that scoff at that, I also kick back to them and say, if you’re being truly honest out of all the code, especially if you’re in a leadership position where there’s a lot of stuff flowing past your desk, do you scrutinize every character on every line when you’re doing these code reads? And the answer’s probably no. And it almost feels safer when I’ve got something written by Sonnet that then Astra’s doing a pass on, Opus is doing a pass on. I’ve got multiple perspectives with different instruction sets. One might be looking for security vulnerabilities, one might be looking for something else. I just see it as a sophisticated instrumentation to help me find issues.

Bryon Jacob: Yeah, I mean 100%. I mean it’s both the only thing that’s going to scale, because I mean at the end of the day, you put a pretty hard ceiling on how much throughput. If you’re saying, “I’m going to allow AI to produce code, but I must thoroughly review every character, every line,” there’s a hard ceiling on how much throughput can go through. And that frankly, leaves human engineers with a job most of them don’t want, which is all they’ve become is peer review machines. But then exactly what you said, you can actually get a much higher degree of trust. And there is a mental leap that people have to make here, which is there’s a notion in there that, well, okay, but what if that reviewer is adversarial? What if the reviewer intentionally is trying to sneak one by you? I’m like, yep. I mean that is a thing that could theoretically happen. However, I think we have enough understanding of the models that we’re using and how you can build blind adversarial reviewer bots, and particularly if you’re going across multiple models, multiple techniques, you can engineer a lot of that out. And then there’s a notion of, well, what if the AI misses something? It’s like, well, the notion of what if the reviewer misses something was always ever present, right?

Douglas Ferguson: Yeah.

Bryon Jacob: Has it never occurred in your entire career that a human reviewer missed something? Well, no, of course it has. You’ve had work done by a great engineer, reviewed by a great engineer, and they still made a mistake. The bar isn’t zero mistakes ever. The bar for can we use AI to write software isn’t does it never write bugs? Bugs are an inherent part of software and they will continue to be forever. The bar is, are we doing as well or better than we would’ve with all human work? And are we putting the right levels of… And again, all these things are matters of degree. Are there portions of your code base that should only pass with a specific review by a specific named human who is directed to only pass it if they’ve actually looked at every line of code? Yeah. There’s probably a 2% of your code base that’s managing how do we manage our encryption keys and make sure that our network perimeter is secure? Yeah, there’s definitely some things that you can’t trust anything but the most senior person whose actual accountability’s on the line to own that decision, but that’s not 98% of your code base.

Douglas Ferguson: Yeah, I think that’s an important thing. It’s like, let’s not have blanket rules that apply across the board. And I would argue that’s true of governance writ large. We don’t necessarily need to write guidelines that apply to legal and every other part of the organization, and we don’t need all the guidelines to apply to every piece of code, because different things are going to have different business impacts. And also I would argue, how reversible is this damage? Because if something ships with an issue, what’s the cost of that issue? And then how easily can we reverse it if something goes bad?

Bryon Jacob: Yeah, 100%. And the reality is, this is another place where your SDLC can protect you. And you start down this path of how do we streamline and improve these processes? And I think the first order thing that I see a lot of organizations do, is how do we just get more efficient at the kind of things we already know how to do? And that’s the right place to start. How do we take those things and turn them up? But then you start to develop whole new ways of working that are really just different ways of applying the same tools. Related to when you talk about the stakes, it used to be that it was pretty expensive, took a lot of time, took a lot of human effort, dollars to pay salaries to go really build out a feature to the point where you could actually really kick the tires on it and try it. It’s no longer the case. And a couple of companies that I’m pretty close with who I’ve seen who are really trying to be on the cutting edge of this have moved to a model where everyone in the company is encouraged to contribute their ideas, their features to the code base in the form of pull requests. Now, that’s not to say that we don’t need software engineers and that organization is not one… The company that I’m thinking of here would not… They have actually a lot of guardrails in place around this. The idea is when the CEO has an idea that he wants to implement, he is totally empowered to open up Claude Code, have a conversation with Claude, work through to the point of having something that works and works well enough in the actual company’s code base where you can start it up, click on it, actually execute the feature, even deploy it off to a shared environment if you want. And by the way, there were cultural bumps here, there was definitely some. “This person has no business and this PR is going to…” the same kind of complaints we had earlier about the PR. But if you reframe your thinking to the idea isn’t this is a pull request ready to be accepted, merged and go to production. The idea is this is fundamentally better in every way than a vague idea that then has to go through a design sprint and a designer designing an interaction and an engineer thinking about how it might get built before we can even talk about does this thing work? You’ve short circuited from the idea that’s in the senior leader’s brain that he wants to get into the world, to something that provably works and sits inside of the application. And now we can take that and do anything we want with it. Now we can go put it through those other steps, like, “Okay, now let’s have a proper UX person think through a better interaction pattern. Let’s go actually make it look the way that fits in our design system. Let’s go actually re-engineer the bits.” But there’s no better spec than a PR that literally works inside of our piece of software and can work. And you can throw the whole thing away and retain none of the code, it’s still a valuable mode of thinking and working.

Douglas Ferguson: Yeah, it’s essentially taking the prototyping culture way further than we’ve ever gone in the past. I’ve also seen organizations creating test harnesses and prototyping harnesses that are idiosyncratic to their environment.

Bryon Jacob: Yeah.

Douglas Ferguson: I’m thinking of one organization right now that is building out a fairly complex new feature that allows you to, I would say, customize and extend the capabilities of their product. And so it’s one of those things that sometimes you really need those use cases for that sort of thing to come alive and to imagine how much capability should they build into that sandbox, because they don’t want to just build an entire dev kit to build anything, right?

Bryon Jacob: Yeah.

Douglas Ferguson: They’ve got to have really good primitives and they got to think about how is it connected to other data sources and that sort of thing.

Bryon Jacob: Yeah.

Douglas Ferguson: And so being able to dream up use cases and see how that actually functions in the real world is really important. So they actually built a prototyping harness that allows you to simulate very, very quickly the environment. So you’re not actually building a PR necessarily, but it’s super close to that, because all of the Chrome and all the pieces where this thing would live, that environment’s supported and really easy to dream up your ideas. And I think we’re going to see more and more of these kind of custom tools that would’ve been cost prohibitive to build, but now we can generate them quickly, and maybe even throw them away after that season’s over.

Bryon Jacob: Yeah, no, totally. And that’s exactly that. It’s like however you do this, I mean, I think that’s a perfectly great pattern, and I think it’s honestly essentially the exact same thing as the company I was talking about. The only difference is that company’s invested so much in their test environment for their developers that it was like, “We already have a perfectly good prototyping.”

Douglas Ferguson: Yeah.

Bryon Jacob: It’s the product itself, but same exact idea. You had to get over this stigma of, “It’s a PR. We can either keep it, we can completely rewrite it, or we can throw the whole thing away and say that was an abandoned idea. And at the end of the day, what did we spend? A few tokens.” Right?

Douglas Ferguson: Yeah.

Bryon Jacob: It’s faster to throw stuff at the wall and try than it ever has been before. It just changes the economics of certain equations. It’s like, “Should we do this way A, B, or C?” Honestly, it’s faster to build A, B, and C and actually click on it than it is to pontificate about which one would be better, right? Yeah.

Douglas Ferguson: Yeah. And I want to talk a little bit more about governance, and one of the things that you said as we were leading into some of that was how important it is to consider the shape of your code base. You mentioned if you’ve got a lot of good patterns in there, there’s a lot for it to rely on or copy, and if there’s a lot of bad patterns or lack of consistency, it’s going to maybe go do things however it might feel it wants to in the moment. And I think also there’s other implications to the shape. It’s almost like Conway’s Law rearing its head again in new ways, right?

Bryon Jacob: Yeah.

Douglas Ferguson: And one of the examples I think about is legacy software that might be monolithic, it might be sprawling and complex, unnecessarily complex, because they never decomposed it properly and it just got built on and built on and built on, and now the surface area is just way too wide for it to do justice by the context window. And so I’m curious, are there other things or does anything come to mind as you think about the implications of the shape of the code base or how we even prepare it to be more agentic friendly?

Bryon Jacob: Well, yeah, you basically set out my soapbox here, because this is the thing that I think I am the most opinionated about of anything right now and the thing I care the most about right now, is I think this is the unlock. Ultimately, I think this is how you do it. Every version of every team I see effectively working AI into their software process ends up leaning to some version of this. So you talk about the legacy, monolithic applications, the things, there’s a couple of dimensions to that, but the key thing is, like we were saying earlier, I think zero tech debt has to be the new mantra. We can’t afford tech debt. Tech debt was a very useful tool for decades. We all built software with lots of tech debt. Why do you take out debt? Same reason you take out a mortgage to buy a… I can go buy a house that I can’t afford today and pay it off later. And that’s essential if you’re operating a financed software startup, because you’ve got to go chase that next top line feature. And so you’re like, “Well, it’s the quickest way to build this, get a feature out, turn it into revenue so I can go chase the next hill. We’ll pay tech debt down in the future when we have lots of money and we can slow down,” which translates to never. And we all did that, we did it for years and you manage the tech debt. Well, now it’s that ROI equation I talked about earlier. You can afford to pay down your tech debt because you have machines that can help you with it and you can’t afford not to. And so then it becomes how do you actually do it? Because that doesn’t magically solve the problem. You cannot go into a messy monolithic code base and just say, “Claude, solve all my problems, make this a perfect pristine code base.” What perfect to pristine means is it’s absolutely dependent on the application to some degree. There’s great patterns, but there’s not one great true pattern that rules everything, it’s just like, here’s the magic. This is why the job of software engineering isn’t going away, but it’s going to change substantially. The job isn’t turning somebody else’s ideas into code. The job is understand how software is architected and apply that thinking and bring that to the table. So you mentioned legacy code. My favorite book for the AI coding era, and it was written I think 25 years ago, so way before any of this was happening, but it’s the most relevant thinking. This is the most practically applicable book I think most software leaders should read if you’re trying to figure out, “How do I take this code base that’s been around before AI and make AI work with it?” It’s called Working Effectively with Legacy Code by Michael Feathers. And the first thing he does, which I love in this book, is he defines legacy code as code without text. He’s like, “We can all talk forever about what good code and bad code look like, and so you could say it’s legacy because it’s bad, but that’s somewhat a matter of taste. We could talk about monolithic versus broke, but there’s pros and cons to every angle of that. It’s always about taste. We could talk about whether it was old, but honestly, code could be reasonably well done and produced last week, and I would still call it legacy, because it’s legacy if you don’t have test cases that force it to hold its shape because you don’t understand what it actually does in a formal way that you can check, and you therefore aren’t able to change it safely.” And we all know that general principle. So the principles in this book, the high-level principles are things we all know. The details are actually pretty great. And he goes into something that he calls characterization testing. And it’s like a lot of teams look at a large untested code base and they say, “Well, I don’t want to go add a bunch of tests to it. What if I just write tests that codify the wrong things? What if I just go enshrine a bunch of defects in my test cases?” And Feathers addresses this. He’s like, “Actually, that’s fine.” He’s like, “The purpose of going and writing a thousand unit tests on a legacy code base isn’t to weed out all the bugs. You’ll probably find some bugs and fix them on the way.” But the point is you don’t actually know what the code is supposed to do, because there’s probably not a written spec and there’s certainly not enough tests. So you go characterize the code with a bunch of tests and say, “Well, this is what it does.” You formally write down, “I have a formal check of what it does.” And the whole point is now as you go forward and change, you don’t know whether everything you’ve written down is correct behavior or not, because you have no formal definition of correct. What you do know is whether it changed or not. So now you can go start to rip it up and replace it. And so that’s where you get into then you break down the monoliths, you clean up the legacy architecture. I think the playbook for teams, I mean, this is the thing, every company I’m advising and coaching, the high-level playbook is easy, the details are what is hard to actually figure out on a project-by-project basis. But I mean the playbook is one, the new bar for automated test coverage is 98%, right?

Douglas Ferguson: Mm-hmm.

Bryon Jacob: It used to be the gold standard is you get to 70, 80 and you’re like, it’s diminishing returns. No, because there’s no reason not to go for as close to 100% as you can get. And yeah, there’s 2% of config code that’s hard to measure, that’s fine. But I want fast unit tests at the lowest level possible mocking everything outside of a dependency chain that give me 98% test codes. Why? Because that tells me I can change anything and didn’t break it. And then I go through like, okay, now what is the architecture of this system? And if it doesn’t have a clean, consistent architecture, it needs to have one. You need to write one down. You need to say, “Well, this is my target architecture that I want the app to have. Where am I violating that?” That’s a refactoring opportunity. And so then what are the chess moves I can make that go one step closer to, I have everything in a clean, modular, decoupled architecture? Sorry, I’m rambling for a long time. You hit a nerve here. Just to say, I think those are the key things you do. You have to put that scaffolding up in terms of tests to be able to make these changes. You have to go ahead and invest in these. And then the last thing I’ll say, is the culture on teams is I think a very common culture, and I saw it on essentially every team I’ve led. I don’t think this was some unusual toxic culture, I think it was the normal culture that we actually have to change, was we got a bunch of smart people and so we’re going to agree on a few basic principles of things and our basic rules of the road. And then mostly it’s going to be, “Well, we’re all smart. We’re going to trust each other in there and write good code.” And what that means, is when you go in and look at a module, you’re like, “Well, Bob wrote this code, so it kind of looks like Bob code. And then Dave came along and wrote this code, it kind of looks like B code. It’s all pretty good. It all basically works and it follows our high-level contracts.” I think that era is dead. I think you have to get much more opinionated as a team. I think the code base, each code base has to know what is your architecture and it has to be consistent. The whole team needs to put their head together and decide what we’re going to do, and everyone gets a voice. But once that’s been decided, it’s decided and it’s not you’re allowed to check in. There is no more opinion on a PR-by-PR basis about how we’re going to write our code. It is, “We’re going to write it in this architecture. It’s going to be clean. It’s going to follow all these rules, and the code base is going to enforce it. If we don’t like these rules in the future, we can change them, but we can’t ever break them.”

Douglas Ferguson: I think part of that was driven by the fact that it was so onerous to sit down and try to document it and come to a consensus on what it should be. And then also, it’s onerous and laborious to enforce it.

Bryon Jacob: Yeah.

Douglas Ferguson: And those two things have changed dramatically.

Bryon Jacob: Yeah, exactly.

Douglas Ferguson: The ability to feed in some general… The vague contracts that we already agreed upon, let’s feed it in and have it generate a document of high specificity that we’re going to follow, and then have everyone review that and decide if there’s anything we want to change or tweak.

Bryon Jacob: Yeah.

Douglas Ferguson: I mean, the fact that we can draft that specification document on how we’re going to shape our code is also accelerated and so fast, it allows us to get into critique mode versus generation mode, and that really opens up… We’re so much better critiquers than we are generators.

Bryon Jacob: Exactly.

Douglas Ferguson: And so if the team can critique and get to some consensus there, then the onerous part of enforcing it we can hand off to the agents too, because now we’ve got this really well specified process and shape that it’s just looking for and measuring for.

Bryon Jacob: Totally. One other cheat code I love, is just pick your favorite named architecture that matches your ideology as closely as possible. And again, if you’d asked me two years ago, I would have said I’m not that opinionated, there’s a lot of great patterns to follow, and the one that I use the most now is, if you’re familiar with the concept of hexagonal architecture, which is domain-driven design. And again, I think the two things that I think are great about hexagonal architecture in this area, one, it’s extremely prescriptive. Not a lot of teams adopted it, because it forces you to overly anal retentively put interfaces and separation of concerns around everything. And the common complaint was, “Yeah, I got to go write 30 lines of boilerplate code to add a method to this adapter to this third party system, whereas I could just go add a method, and I’m probably never going to switch courses, so being coupled to this one external integration is fine.” But because it’s so prescriptive, it actually forces you down this path on everything. And then the second thing about it is it’s really widely written about. The people who write about it have written a lot about it, which means every foundation model has read 30 different angles on hexagonal architecture and understands what it means really well. And so it’s like a token compression on a really, really aggressive opinionated architecture. You can go into almost any project and basically say, “This is kind of a mess with stuff that seems overly coupled. I’d really like to reorganize this into a strict hexagonal architecture with all the domains clearly delineated. Could you help me do that?” And I almost just gave you the prompt you need to go into a project to basically send an AI off to go do the whole research project for you. It doesn’t take a whole lot more than that to then go come up with a catalog of here’s the 10 bounded contexts that should probably exist and how we might architect it. You probably need to… That’s not enough for it to go do the work, but that’s certainly enough for you to send Claude off to go do your librarian and archeology work to tell you where the bodies are buried, and it helps kick off that session.

Douglas Ferguson: Yeah. And I think that’s the thing that so many folks miss, because they see all of these single shot builder tools like Lovable, et cetera.

Bryon Jacob: Yeah.

Douglas Ferguson: But spending a good chunk of time, to your point, writing test cases for existing code, doing archeology on it, coming up with a plan for how we might shift things over. And if we don’t attend to that stuff, then it’s going to be a lot more difficult to add onto new things to it, because if we’ve got a shaky foundation and we’re adding more stuff, it’s hard to blame the AI for that. We were going to have a hard time as well.

Bryon Jacob: And that’s it. I mean, honestly, it’s like almost universally, the things that you do to make your code better able to be worked with AI are the exact same things that make it easier to work with for humans. I mean, at least I haven’t hit diminishing returns yet. This has been mostly the only thing I think about professionally for two and a half years, and I haven’t hit diminishing returns yet on… Almost always the way I improve something about how using AI for software development is more rigorous application of something I’ve known about for 30 years that we could just never afford to do, and now you can afford to do it. That’s an almost bottomless well at this point. There’s very few things that I would say that I’ve done that are AI… Even some things that felt AI specific, ultimately that’s just how humans read too. Really, this is a little bit in the weeds detail, but it’s an interesting note. Even as some of the other models have started to outperform it as a model, one reason I still love working with Claude, is that its harness makes a really smart decision of the way it handles its Claude MD context, where it’s strictly hierarchical. As you read a file anywhere in the tree, it reads all the Claude MD files down. That gives you an architecture, where you can load a lot of context into those Claude MD files. You can have hundreds of those files in a large repo. Each one is relatively small, a hundred lines of text at most. And then when I’m reading down a deep path, I can see the rules of the overall repo from the top, and then the rules of the sub-project and this monorepo there, the rules of this sub-module, the rules of this specific package. I’m reading four or five Claude MDs which add up to a really great system prompt that’s going to give me super fantastic context, but I’m reading a few thousand words as opposed to the hundred thousand words that exist in the whole repo. And that was one of the things I’m like, “Oh, well, this is one of those things that’s kind of unique to the AI era,” but not really, you could easily imagine that organizing your ReadMes that way for human developers five years ago was just as important. And again, you couldn’t afford to do it, now you can afford to take all that context, spread it out like that, and then you could put an automated librarian task that just runs on CI/CD continuously. And is like, “Hey, every once in a while, let me just go audit all these pieces of documentation and make sure that they’re accurate with the code.” Don’t let the docs drift from the code too much without scooping up and fixing it.

Douglas Ferguson: That’s a good point. I’m a big fan of creating routines that are basically drift alerts for all sorts of things, right?

Bryon Jacob: Yeah.

Douglas Ferguson: I have tons of monitors running just to detect if a routine has gone sideways or maybe my RAG system embeddings have gotten a little bit degraded in some way.

Bryon Jacob: Yeah.

Douglas Ferguson: And that’s another thing I don’t see enough folks doing. I see folks putting evals in place if it’s a feature inside your product that’s leveraging AI, to make sure that we’re getting the accuracy we want so that we don’t impact our customers in a negative way.

Bryon Jacob: Yeah.

Douglas Ferguson: I think that there’s a lot of room for more eval when it comes to our process and how we’re operating and the results we’re getting from building with AI. And then if we have eval suites and we set up things like that, we can run those in an automated way to make sure those things aren’t drifting or getting out of sync. And you talking about scanning the Claude MD files is a great example of that.

Bryon Jacob: Yeah, no, I totally agree. I mean, anything that’s there to basically improve the performance of an activity that has a heavy inference is something that’s subject to an eval, I mean 100%. I mean that’s just application of governance going back to the theme of this, that’s just how do you govern the things that are basically steering inference heavy tasks and make sure that they’re continuing to perform within bounds?

Douglas Ferguson: You did mention this idea of a good place to start, and I want to revisit that a little bit maybe in a broader context. So say you’ve got an organization and they’ve been a little bit reticent to dive in. I see people using it, maybe different developers are using different tools and there’s not consistency there. They might be using an auto-complete insight cursor, but not any heavy agentic work. They might be using it as an augmentation of themselves to help with code review or help read through some production logs or whatever, but there’s really no systemic use and there’s certainly no solid governance. And that may be the limiting factor because no one’s set the governance, so people are afraid to just really lean in because they don’t know how and when and what’s safe. And so I’m curious, what are the killer first use cases that really can get people convinced that, “Oh, this is safe and this is something that’s going to have a meaningful impact on our development process?”

Bryon Jacob: Yeah, I mean it’s extremely hard for all the reasons we’ve talked about here, because you brought up the way it starts getting rolled out at a lot of organizations. A lot of organizations are like, “All right, well, let’s get our team the tools,” and you can buy them all the best tools and buy them tokens and do the thing. But the problem is that if you and I are working in the same code base and you have a dedication to a certain practice and a discipline and a way you’re going to govern it and the way you’re going to write code and I don’t, there’s a hard ceiling to how well you’re going to be able to work inside of a code base that isn’t actually governed to basically be something that AI can work into. And so you have to get to the point where it’s a top-down commitment from the leadership, from the people who own the quality architecture of the code to say, “We are going to operate this code base as an agentically developable code base,” which I think flash forward 24 months is just code base, because the notion that we’re going to go back to people writing most of the code is, to me, completely off the table and that future’s here, it’s just not evenly distributed yet. But then to really answer your question, I think the way you jumpstart a team, the best way I can see to jumpstart a team is do something greenfield, because all the things that make it really, really hard to get this up and running are basically dealing with legacy code. And so if you start by taking that off the table and if you have one small problem that you can just go in and greenfield, either a completely green repo or even just a green module inside of one place where you’re like, “This little garden is going to be… We’re going to commit to making this garden perfect. We’re going to architect this from day one, we’re never going to let it steer off the rails. 100% test coverage is the rule from day one,” you can win people… I’ve seen this happen plenty of times. You can take the biggest skeptics in the world and turn them into your advocates when you show them, “No, look, I can really go build something in a week that you would acknowledge would’ve taken six months, and the quality of the code is provably higher, better, easier to read, understand, work with than the code it would’ve taken you six months to handcraft.” That flips the skeptic. You can no longer argue this can’t be done once you’ve gotten that proof point inside your organization. Then the harder nut to crack is for sure, how do you go apply that same reasoning to an existing code base with millions of lines of code that was built by multiple generations of humans over a period of time? And that is a harder problem. It is now at least a tractable problem in a way that it wouldn’t have been without AI assistance.

Douglas Ferguson: Yeah. Well, I think what’s compelling about that and also makes that leap easier is that instead of just picking one component in the SDLC, you’re saying, “Let’s pick a project that has some nice boundaries to it and let’s do the whole thing soup to nuts.” And that way we’re not just saying, “All right, we’re going to get everyone writing a regression test or a unit test with AI.” You’re only focusing on one part of the SDLC and then trying to make that leap into the other areas of the SDLC is much more difficult. So I like this end-to-end approach on a more bounded project.

Bryon Jacob: Yeah. I think you almost have to do that. I mean, again, you want to keep the scope small enough that you can actually go in and prove your point in a week or so, but you have to go end-to-end with something because it really is all holistic. There’s no magic bullet. People are waiting for, “Just tell me how to AI-ify my thing.” It’s like, well, I mean, you can do that, but it involves a rethinking of… And it’s an uncomfortable thing too. I mean a lot of people are just uncomfortable with the idea that, “I’m not going to sit in front of my IDE and type Python or JavaScript into a text editor anymore.” I mean, one analogy that has helped a few people, there’s a couple of people who are on my teams who are… I guess you have to be at least my age. I’m about the youngest you can be for this analogy to work. One of the engineers on our team who’s a couple years older than me was like, “Guys, I’m just really uncomfortable with the idea that I’m not going to actually write the code anymore, that this code’s going to be… And well, isn’t it a bad thing that we’re going to lose that skill and isn’t that important?” I’m like, “Well, I don’t know. How’s your assembly?” He’s like, “What do you mean? I haven’t thought about writing assembly code for 25 years.” I was like, “Exactly.” But there was a time, if you were a self-respecting engineer in the late ’90s you wouldn’t have trusted a C compiler to write performance enough code for the most memory sensitive stuff. You would have to be able to drop down and write a little bit of assembly to do anything that was real if performance mattered. And what happened was for a while, people kept trying to make assembly a little bit better and make it easier to write. And eventually we just realized humans don’t think like that. We would be much better by having higher order structured languages and just invest more in making the compilers really, really good to the point where a C compiler is going to take well-written C and produce better machine code than the best human writing assembly on 99.9% of the problems. Do people still write assembly today? Yes, but it’s a very, very niche thing. You’ve got to be right down at the mettle doing the most device specific stuff. But all that same machine code is still there. Already, I mean, people write JavaScript, but really mostly people write other programming languages that we’ve invented on top of JavaScript that compiles down to the kind of JavaScript that actually runs in our browsers. This is just that same evolution. We’re mostly not going to write the actual compilable code, but that was never your value as a software engineer. If your value was just, “I could take someone else’s perfectly written spec and convert it to JavaScript that compiles,” I’m sorry, that job doesn’t exist for people anymore. It’s not economically feasible for that job to exist. But that was never your value as a software engineer. Your value was being able to understand this architecture and the systems side.

Douglas Ferguson: Yeah. When you said you’re the youngest to maybe understand that, I thought you might be going to the story I like to tell, which goes back even further, which is if you’re writing code using punch cards and you are super married to the punch card and didn’t believe keyboards were the way to go, that’s a similar situation, right? Are you really that married to the keyboard?

Bryon Jacob: Right.

Douglas Ferguson: Because at the end of the day, we’re still architecturing, we’re still designing the systems, it’s just how are we inputting the information?

Bryon Jacob: Yep, totally.

Douglas Ferguson: So before we wrap up, I’m just curious, we talked a lot about governance. There’s a few things you mentioned, including near 100% code coverage, being opinionated and consistent so that the patterns are clear for the AI to replicate, or at least being clear and consistent in what we expect so it follows those rules. And then also this idea of the hexagonal domain-driven approaches. Curious what other governance or approaches, like a lightning round on what are the things that folks should be thinking about when they’re putting governance in place, the requirements? I mean, I’m sure it’s a lot of the same stuff we’ve been doing for years, but some of it’s shifting even slightly.

Bryon Jacob: Yeah, I mean again, that’s really the spine of it. I mean, your testing needs to be ludicrously more thorough than it ever was before. Your architecture needs to be opinionated, written down, strictly enforced. You need to have alignment on your team that you’re going to do that. You really need to beef up the CI/CD, the pipeline rules of what’s allowed to come in and out into your code base. You mentioned evals, and I think there’s evals and a slightly broader view of just continuous improvement on these agentic flows of which evals is a big part of it. I think that’s a huge thing. I think this isn’t exactly the answer to your question, but it’s related. One of the things that I started seeing with people who I know who are really on the cutting edge of this, really pushing the how much can we actually get AI to produce all the code? How much leverage can we really get on a per engineer basis? One thing that I’ve started noticing is we’re now getting to the point where I think this is a good thing, we’re starting to have to solve some new problems. And some of this is definitely my fault on companies I’ve given advice to and I’m helping them unwind it. Sometimes you have to cross the line to find the line, and we’ve definitely crossed the line to find the line in a few places where this very rigorous like, “okay, we’re going to have automated tests for everything, 100% coverage. We’re going to have this rigorous end-to-end test suite. We’re going to really…” As that has been very successful, we built all these automated checks in. And then because of that, we’ve increased velocity to the point where it’s like, well, now you’re getting 10 times the PR volume through. It’s like, well, actually, what was actually a reasonable set of CI/CD rules to run every PR when you had the kind of volume that unaided units can produce? That was totally normal. Now, if you have that same volume of PRs, the first thing that starts manifesting is like, “oh no, my GitHub Actions bill is now out of control and I’m literally spending as much money on GitHub Actions to run very expensive CI/CD checks continuously as I am on my tokens.” Or you get into a log jam where it’s like, “Okay, I can now produce more PRs in a day than my automated deterministic checks can run.” These are all super solvable problems. This is the sort of thing where these are easily solved problems. Okay, obviously I can’t run 30 minutes of tests on every single PR when I’m pushing four PRs an hour. The math just doesn’t math when you’re doing that. So you have to figure out how to pipeline things better and better optimize your tests, run them in different phases, collect up six PRs before you go run your full test suite, because you just don’t need to run the full test suite on every one. These are the class of problems I’m starting to see now. These are high class first world problems, all right? If you’re getting to the point where we’re producing so much code and it’s of generally such high quality that we want to accept all of these PRs and we’re moving features this fast, but we’re now pushing ourselves to all the automated checks we need to keep it safe or taking too much time, these are the fun problems that I’m seeing people trying to solve now.

Douglas Ferguson: Yeah, that makes me think of two things that I wanted to highlight for the listener. One, is this thing you’re describing is also applicable org-wide when you start applying AI to processes and systems.

Bryon Jacob: Yeah.

Douglas Ferguson: So basically, what you’re describing is there’s a human shaped process or a human scoped process that now we’re shoving agents through. And your other point around it’s easily solvable, the performance and throttling can be easily solved, and often the right approach is fairly easy. But sometimes the obvious solution, i.e. let’s fix the throughput in some way, like maybe running them in batches or whatever, might not be the right solution because stepping back and going, “Hey, wait a second, the agents sending stuff through this at a volume that we never expected because this was designed for humans, is causing issues. Let’s step back and rethink this. Now that the friction has exposed itself, let’s think about what this means for the future, not just fixing this problem that we’re noticing right in this moment.”

Bryon Jacob: Yeah, no, I totally agree. And I mean I think as a general class, not every solution to these problems is easy or straightforward. I think that specific one around your build bottlenecking, that’s one that happens at human teams at certain scale.

Douglas Ferguson: Yeah, yeah, fair enough.

Bryon Jacob: And so that’s one that has some patterns. But you’re totally right, I mean, the phenomenon is sometimes, and this goes back to one of the things I was saying earlier too, you’re hitting it on another front, which is that sometimes it seems like these things are just qualitative differences like, “Well, we’re doing the same thing, but we’re doing it faster and at more scale.” But when the scale gets magnified to a certain point, it’s like, well, that quantitative difference is really actually a qualitative difference at some point. It’s like this is the same thing a hundred times faster, which becomes actually a qualitatively different thing. A friend I’ve worked with, he was saying this phrase about a year and a half ago, people were asking him, “Well, how much faster are you at engineering tasks with AI?” And he’s like, “That’s not the metric.” He’s like, “The metric is the number of things I now do that would’ve never seen the light of day, because doing them would’ve cost too much before.” He’s like, “Yeah, on the things I was going to do anyways, I don’t know, five times as fast, 10 times as fast.” But he’s like, “My thing is now I have the giant backlog of the last 30 years of every fun project I ever wanted to do, and all the ideas I had where I’m like, well, I’d love to go build that, but it would take me a month of weekends and I only have so much time to give. Now I can take one of those ideas, put it in front of Claude and have the result in an hour to play with. I’m doing all of them. So it’s infinite. The speed up is infinite. A million things that I would’ve never even started, I finish five of them every weekend.” And that’s where you change this quantitative speed up just becomes a qualitatively different thread.

Douglas Ferguson: Yeah, there’s two things that come to mind there. One, is the opportunity cost equation, where it’s like, “Oh, where do I invest my time because it’s a limited resource?” So that’s a qualitative change, because now that equation shifts in a big way where it’s like, “Wait a second, I can pursue all these opportunities.” And then there’s also this aspect of, “What am I getting exposed to? What am I learning by doing these things that I would not have known before?” So it’s not about just pumping more volume through, it’s about connecting the dots in a way that really allows us to level up in a brand new way. And in fact, if you look at everyone sees technology gains as a way to… They look and like, “Oh, well, if we can speed things up, we only need five engineers instead of 50.” Humans never work that way, right?

Bryon Jacob: Yeah.

Douglas Ferguson: Once we speed things up and make new discoveries and the possibilities have now shifted, we level up in some whole new way. There’s so many examples of that. In fact, a friend was just telling me the story about Snow White when they originally animated that, how many animators it took. It was like, I don’t know, it was in the hundreds or whatever. And then you look at the latest X-Men or whatever with all of these sophisticated digital animation tools, and I don’t know, 95% of it’s completely animated. And you think, well, the computers can now do all that stuff, but it was 3,500 animators. So it’s actually requiring more people, because we just push the boundaries of what we expect and what we want to do. To your point, it’s not just a quantitative game.

Bryon Jacob: Yeah, no, I agree. A lot of people talk about Jevons Paradox now, which is the phenomenon you’re talking about, where we create new capabilities, and therefore you’ve dramatically reduced the cost of certain activities and increase the throughput, so now you can do more things. Yes, it would take fewer people to produce an animation that looked just like Snow White, but we don’t produce animation like that. We spend the overage on making better, better things. I don’t think there’s any reason to think that we’re at the ceiling of human capability on almost any axis where we couldn’t do more things better. I mean, I do think one thing we’ve talked a little bit about here, a theme is I think that software engineering is in some degrees the canary in the coal mine. It is one of the first things to fall and change dramatically with AI. I think superficially people think, “Well, of course software engineering can be automated more, because software engineering is computers, AI is computers.” That’s a superficial connection. The real connection to me, I think, is more about the automation tools around governance. That’s why this job in particular gets tackled first. I think that is the bigger driver than just it happens to be computer programmers are the kind of people who would care about AI. I do think that’s mostly a superficial connection. And why that’s important is, I think that over time, the same patterns we’re seeing here end up, basically, this ends up being the pattern by which almost any job that people do can become more and more automated by AI and start to become subject to these phenomenon of the exact question you’re asking is like, “Well, do I do the same amount of work with fewer people or are there fundamentally new ways of working when I can do that work a thousand times faster?” And we’ve already hinted in this conversation, software engineering is, I think, by far the most changed profession. Legal’s not far behind for a lot of the same reasons. It’s a very regimented information processing kind of thing. So it’s going to be a spectrum, but I think a lot of the things that we learn as we go through this change in the software engineering practice are going to trickle down and imply ways that a lot of the other work gets transformed.

Douglas Ferguson: Yeah, that’s interesting that you mentioned legal, because I was going to say there’s evidence for this hypothesis or this observation you have, because I’m noticing it in legal where they’re moving quite quickly on this stuff. And honestly, in some organizations where there’s resistance on the engineering side, I see legal adopting it more than engineering.

Bryon Jacob: Yeah.

Douglas Ferguson: And to your point, it’s structured, there’s governance in place, they have very explicit ways of doing things and guardrails around stuff. And also there’s a lot of documented process, right?

Bryon Jacob: Right.

Douglas Ferguson: They are upholding laws that are well documented and the language is very specific. It’s just a matter of time before more jobs are impacted. I don’t think anyone’s going to sit this out.

Bryon Jacob: Yeah, I agree.

Douglas Ferguson: So I want to invite you to leave our listeners with a final thought.

Bryon Jacob: Yeah. I mean, we’ve already talked about it a lot, so it’s a little bit of rehashing, but I mean, for me, I’m focusing so much, have been for the last couple years, on how do software engineering teams make this shift? We talked a little bit about this. This is an economic force. Actually, you can like it or not like it, this is definitely happening. I think the proof is clearly out there that we are going to produce most software code, if not all software code, with AI authoring. I think that is just a natural evolution. I don’t see it as a fundamental change, certainly not as an end to software engineering as a human pursuit, and I don’t see it really as much of a fundamental shift. As impactful as it is, I think it’s a natural curve. We talked about assembly language and compilers, and in a certain sense, this is really just moving up that stack. I mean, we’ve always talked about how the best programming language would be just natural language. Why do I as a human have to come down and talk at the level of a computer in order to get my thoughts across? Why can’t the computer come up and talk at my level? And it’s a little scary and intimidating, but also really fun and extremely exciting to be at the point in history where that’s actually possible to a much, much larger degree than it ever was. In fact, I would say, we are there. The computer is not as good as me or as good as any solid engineer at deciding the best architecture, making all the best judgment calls. It’s not a logical reasoning machine, at least not yet. It simulates one really well, close enough to fool people on a lot of dimensions, but there’s still a role, at least for now, for a smart engineer to be involved and help and make those decisions and steer. So I really think of it more as, I still program all the time. In fact, I program more than I have in my entire life, I just do it conversationally. I do it with English. I do it by typing instructions out. I do it when I go on a walk and turn on voice mode and have a 30-minute conversation where I fully spec out a feature and then I get back to my computer and copy it. Sometimes it’s more sophisticated than this, but often it’s still as unsophisticated as copy paste the output of that chat from one chatbot into the input of another and say, “Here’s a thing I spec’d out while I was on a chat with another chatbot. Please go build it according to the architectural principles in this project and work through that spec.” I think the thought that I want people to understand, is that future is already here. The teams who are saying, “This doesn’t really work for us and it’s making things worse,” they’re right, but I would argue they’re doing it wrong and they haven’t figured out what to do. The teams who are getting high effectiveness, that is real. I’ve seen it with my own eyes, it definitely works. And it really comes down to just rigorous application of the engineering practices we’ve always known we would do if we had infinite time and resources, and now we almost do.

Douglas Ferguson: All great points. Bryon, it’s been a pleasure chatting. I’m looking forward to chatting with you again sometime soon.

Bryon Jacob: That was a lot of fun. Thanks for having me on, Doug. I appreciate it.

Douglas Ferguson: Thanks for listening to New Friction. If you enjoyed this episode, share it with a leader who’s in the middle of this right now, they’ll thank you for it. And if you want to go deeper, we bring leaders together through executive dinners and virtual masterminds. To learn more about our work or to inquire about exclusive executive events, visit voltagecontrol.com. I’m Douglas Ferguson, see you next time.

The post Why Zero Tech Debt Is the Real AI Engineering Unlock appeared first on Voltage Control.

In regulated enterprises, legal teams are outpacing engineering on AI adoption. The driver is not confidence. It’s fear, and understanding why reshapes how transformation should be led.

The largest cohort of ChatGPT Enterprise adopters at Endava was not engineering. It was legal. Joe Dunleavy, Regional CTO Europe, Endava, mentioned this at Canvas, Miro’s annual conference, in May, almost in passing, as if he had already stopped being surprised by it. The legal team had outpaced engineering in adoption rate. The CLO had publicly championed it. His explanation was direct: they felt most threatened, so they leaned in hardest. When you hear that for the first time, it sounds wrong. Engineering is supposed to lead on technology adoption. Legal is supposed to slow things down. That is the mental model behind most corporate AI strategies, and it is producing the wrong transformation results.

The Strategy Built on the Wrong Assumption

The standard AI governance posture says: move carefully in regulated functions, accelerate in technical ones. Legal carries risk. Compliance is a constraint. Engineering is where things happen. That assumption produces a transformation program with a predictable shape. Engineering gets the tools, the sandboxes, the early access programs. Legal gets guardrails, review queues, and the final word on what is permissible. The architecture of AI adoption mirrors the architecture of AI caution. The assumption feels sensible. Most transformation leaders have built their programs on it. And across the practitioner circuit, the same pattern keeps appearing: legal, compliance, and regulatory functions are outpacing engineering in adoption rate, not trailing it. Not because they were told to. Because they had more reason to.

Why Fear Moves Faster Than Curiosity

Tomer Cohen runs product at LinkedIn. He has been rolling out AI inside one of the world’s largest professional networks while simultaneously watching how AI is reshaping the labor market it tracks. At a working session in May, he described how he approaches organizational change. “I started treating the organization as an emotional beast,” he said. “It’s afraid. I had to find a different way to get to people.” He drew on his experience rolling out LinkedIn mobile in 2012 as the template. The pattern was the same: people do not respond to transformation through information about the upside. They respond through their relationship with what feels at stake for them personally. Getting to people means getting to the stakes, not the facts. The emotional beast frame matters here because legal is not slow to adopt AI for lack of curiosity. Legal is fast to adopt AI because it is afraid. And fear turns out to be a more reliable adoption driver than enthusiasm, when it is channeled rather than suppressed. Most AI transformation programs are designed to build curiosity. Find the early adopters, show visible wins, create the positive pull. That is the right strategy for a technology that looks like a productivity upgrade. It is the wrong strategy for a technology that looks like an existential threat. For engineering, AI mostly looks like an upgrade. More capable tools for the same job. The core identity, building things, remains intact. Individual productivity goes up and the job title stays the same. For legal, AI does something different. It does not upgrade the job. It redraws it. Contract review, document analysis, legal research, discovery review: the knowledge-acquisition work that defines the first decade of a legal career is collapsing in time and cost. A first-year associate who spent three years learning to do contract review is watching a model do it in seconds. That is not a productivity gain narrative. That is an existential one.

What Existential Stakes Do to Behavior

The Perception Gap research from Gartner captures a related dynamic from a different angle. Executives who authorize AI investments are four times more likely to report high productivity gains. Individual contributors are five times more likely to say AI made no difference at all. Executives have cognitive skin in the game in one direction: the investment has to be working, because they staked credibility and budget on the claim that it would. Individual contributors have skin in the game in the opposite direction: if AI really does work as well as leadership claims, the implications for their own role are uncomfortable. Legal professionals are living inside a specific version of that second dynamic. They read the same news their executives do, but they parse it differently. When a major firm announces it has automated contract review, the partner sees efficiency gains. The associate sees the on-ramp to the partnership track disappearing. Here is what the pattern across the dinner and practitioner network tells us: that fear, when it is acknowledged rather than suppressed, produces faster adoption, not slower. Legal professionals at organizations that are leaning in are not waiting to be trained. They are self-deploying, experimenting, building fluency, often ahead of the functions that the transformation program designated as the leaders. They are doing this because not learning feels more dangerous than learning. The calculus of the emotional beast is simple: if this technology is coming for my work, then not knowing how to use it is riskier than the awkwardness of learning it under pressure.

The Governance Inversion

Most organizations have built their AI governance posture around the assumption that legal needs to be protected from AI. The standard risk framing holds that legal AI deployment carries higher stakes and therefore needs more oversight, more review gates, more safeguards. This framing is not wrong about risk. Legal work does carry high-stakes consequences, and governance matters. Moffatt v. Air Canada, 2024 BCCRT 149, and the EEOC’s 2023 settlement with iTutorGroup establish real precedent for what happens when AI governance fails in regulated contexts. But the governance-as-protection posture has a side effect that most transformation leaders miss. When you position legal as the brake and engineering as the accelerator, you systematically apply the most friction to the function with the most adoption motivation. The people most willing to change are the ones working against the most resistance. The people with the least existential urgency are the ones getting the most runway. The move Joe Dunleavy described at Endava cuts the other way. The legal team’s outpacing of engineering was not the result of a lighter governance touch. It was the result of a CLO who decided to publicly champion AI adoption rather than treat it as a risk to manage. The signal from the top of the function changed the emotional calculus for everyone in it. Fear of obsolescence became permission to act rather than reason to wait. That is a different governance posture than most AI leaders are running. It is not removing guardrails. It is removing stigma. It is the function’s own leadership standing in front of its people and saying: we see what is coming, and we are going to lead through it.

What This Means for Running Transformation

Most AI transformation programs are designed around the willing. Find the early adopters, give them tools, make the wins visible, use those wins to pull the skeptics. This is a reasonable strategy for functions where the dominant emotional posture is curiosity or mild interest. It is the wrong strategy for functions running on existential stakes. When the dominant emotional posture is fear, early adoption is not about enthusiasm. It is about self-preservation. You do not need to find the willing in legal. You need to create the conditions where the fear becomes productive action rather than paralysis or quiet non-compliance. Three patterns show up consistently in organizations where this is working. The first is naming the stakes publicly. When the CLO at Endava championed AI adoption, they were not pretending the displacement risk was not real. They were acknowledging it and choosing to lead through it. The acknowledgment is what made it safe for the team to engage rather than protect territory. The second is giving the function genuine design authority over the deployment. Most transformation programs make legal a reviewer rather than a designer. The function approves or objects; it does not build. This is both a governance failure and a motivation failure. The legal professionals with the most at stake in how AI gets deployed in their function should be co-designing the deployment, not signing off on it after the fact. The third is connecting the individual adoption story to the function’s future. Training programs that lead with efficiency miss the emotional layer entirely. The frame that lands in regulated functions is not “here is a tool that will save you time.” It is “here is how you stay relevant in a function that is being redrawn.”

What Engineering Gets Wrong

This is not an argument that engineering is approaching AI transformation badly. Engineering is doing AI transformation the way you do it when the primary stakes are capability, not survival. What engineering gets wrong, in most organizations, is assuming that its own relationship to AI is the default relationship for everyone else. The enthusiasm that comes from seeing AI as a force multiplier for your core skill does not transfer automatically to functions that see AI as a force replacement for their learned work. Transformation leaders who come primarily from product and engineering backgrounds tend to design programs that assume curiosity as the starting point. Legal, compliance, and other regulated functions often arrive at the same transformation program with a fundamentally different starting point, and those programs do not serve them well. The smarter move is to design different entry points for different stakes. The emotional beast responds to different things in different functions. Acknowledging that is not a concession to fear. It is a recognition that transformation is a human problem before it is a technology problem.

The New Friction in Action

Tomer Cohen’s emotional beast frame is not a metaphor for organizational irrationality. It is a description of how people respond to change that carries personal stakes. You cannot get to the other side of that fear with information, training curricula, or pilot result dashboards. You have to work with the fear, not around it. Legal’s faster-than-expected adoption rate is not an anomaly. It is the emotional beast behaving exactly as it should: moving fast when the stakes are real, when the leadership of the function gives it direction, and when the alternative to moving feels clearly worse than the discomfort of moving. If you are running an AI transformation program and your legal function is in the slow lane, the question worth asking is not “how do we get legal moving faster?” It is “have we made it safe for legal to run toward what it is afraid of rather than away from it?” The answer to that question is not a training program. It is a facilitated conversation, with the right people in the room, about what the function wants to become in a world where its historical on-ramps are contracting. That conversation is the work. That is the entire work. If your organization is ready to have it, the New Friction framework is where we start. Read the primer or reach out if you want to talk through what this pattern looks like in your specific context.

The post Why Legal Is Adopting AI Faster Than Engineering appeared first on Voltage Control.