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.

Why $500M Won’t Fix the AI Transition (and What Actually Will)

In June 2026, a coalition of the world’s largest AI companies announced Raise Us, a $500M nonprofit initiative to fund state-level retraining programs for workers displaced by artificial intelligence. The names behind it read like a who’s who of the AI industry: OpenAI, Anthropic, Microsoft, Amazon, Bank of America, Workday, IBM, among others. Former Commerce Secretary Gina Raimondo is co-leading it, alongside former Indiana governor Eric Holcomb. This is a good sign. The companies building AI are acknowledging that the transition creates real costs for real people. That acknowledgment has been a long time coming. The scale of the commitment signals they understand those costs are serious. But acknowledgment and correct diagnosis are different things. The instinct driving Raise Us is that the right response to AI workforce displacement is to retrain workers in new skills. That instinct is almost certainly wrong. Not because the workers don’t need support. Because skills aren’t the bottleneck.

The Ceiling We Keep Building

State-level workforce retraining programs have a documented history of underperformance. The evidence on their effectiveness is not encouraging. Gina Raimondo knows this. During her tenure as governor of Rhode Island, she ran one of the more ambitious state retraining initiatives in the country. In launching Raise Us, she has said past federal retraining efforts were largely “ineffective.” That assessment wasn’t unfair. The research on workforce retraining consistently finds the same pattern. Evaluations of federal programs including JTPA and Trade Adjustment Assistance found no statistically significant employment or earnings gains for participants, and TAA participants remained underemployed relative to non-TAA workers even four years after displacement (Brookings: Jacobs, “AI Labor Displacement and the Limits of Worker Retraining,” May 2025). A 2026 analysis of 23 million WIOA training records found the program rarely shifted participants into less automation-exposed work (arXiv 2605.03767). None of this is a knock on the people who design or deliver these programs. The problem is structural. Retraining programs operate on a model: there is a skill deficit, here is a curriculum, here is a credential. Complete the program, earn the credential, get the job. It’s a clean model. It just doesn’t reflect how people actually develop competency in new work. Skills are learned in context. They stick when practiced on real problems, in real teams, under real conditions. The classroom gets you started. The room is where you actually learn. The other problem is more fundamental than program design. For the AI transition specifically, the premise is wrong. Individual skills are not the primary obstacle to a successful transition. They are not where the work stalls.

The Bottleneck Nobody Is Naming

Earlier this year, I spoke with the head of AI enablement at a major North American bank. He had rolled out AI tools to over 4,000 employees. Training completions were high. His team had built a solid onboarding curriculum. Adoption numbers looked reasonable on paper. But the work wasn’t changing. Teams were using AI to produce the same deliverables faster. Nobody was questioning whether the deliverables still needed to exist. Nobody was renegotiating who reviewed what. Senior analysts were reviewing AI-generated work at the same rate they had reviewed junior analyst work, which defeated the efficiency argument entirely. The tools were in the hands of the individuals. The operating model of the teams hadn’t moved. He didn’t have a skills problem. His employees could use the tools. What they couldn’t do was change how they worked together around those tools. This is the transition that nobody is naming. It isn’t a skills transition. It is a delegation transition. When AI can handle tasks that used to require human time and judgment, every team has to renegotiate who decides what, who checks what, and who is accountable for what. An individual contributor who used to produce the first draft now manages the agent that produces the first draft. The work changes. The role changes. The team’s accountability structure has to change with it, or you end up with a faster version of the same old process. That renegotiation happens at the team level. It can’t be solved at the individual level. You can train a person to manage an AI agent. You can’t train a person to lead a team that has learned to work with AI agents together, because the team has to do that learning together. The bank’s head of AI enablement eventually figured this out. The intervention that moved the needle wasn’t another training program. It was a six-week sprint where teams worked on real deliverables, debriefed weekly on what they had tried and what had failed, and rebuilt their working agreements around AI as an actual participant in the workflow. Individual capability wasn’t the issue. Team operating model was. The sprint addressed the right unit.

Spark, Don’t Train

The distinction worth holding here is between training and sparking. Training is one-time, classroom-based, information-transfer. It works well for things that can be reduced to a curriculum: how to use a tool, how to follow a process, how to answer the questions on a certification exam. It does not work well for developing judgment, because judgment can’t be transferred from a teacher to a student. It has to be built through practice, feedback, and reflection on real conditions. Retraining programs are, by design, training programs. They are well-suited to the problem they are designed for. The AI transition is not that problem. The pattern that actually builds AI capability looks different. You model the behavior visibly. You practice it on real work. You reflect on what happened. Then you do it again. Not once. Repeatedly, over time, embedded in the actual work of the team. This is not a novel insight about how humans learn. It is how judgment develops in every high-stakes domain. Lawyers build judgment through cases. Surgeons build it in the operating room. Managers build it by managing under real conditions with real feedback. AI fluency follows the same pattern. The only way to build judgment about when to trust an AI output, when to override it, and how to calibrate your confidence in it is to use AI on real stakes, with real feedback, in real teams. There is a specific dimension of this that retraining programs are structurally unable to address. The judgment questions in AI adoption are not primarily individual. They are social. Who owns the output when an AI writes the first draft? How does a team validate an AI recommendation before acting on it? When a junior employee produces AI-assisted analysis faster than a senior employee can review it, whose judgment carries? These are not questions a certification exam can answer. They are questions a team has to work out together in real time. The organizations getting this right are designing for exactly this kind of learning. They are running team-level sprints on active projects where AI is embedded into the actual work. They are creating structured reflection time so that teams can process what’s working and what isn’t. They are building internal communities where practitioners share not just what the tools can do but when and how to use them well. They are putting leaders in the room as practitioners, not sponsors, because a leader who uses AI visibly gives a team permission to experiment with it openly. None of this shows up in a training completion report. All of it shows up in whether the organization can actually work differently twelve months from now.

The Move Is Organizational, Not Individual

This reframe has a direct implication for how the Raise Us funding should be deployed, and for how every organization should be thinking about their own AI transition work. The unit of change is not the individual worker. It is the team. Retraining programs that target workers one at a time, equip them with new credentials, and then return them to unchanged teams will produce unchanged outcomes. The ceiling is not the individual’s capability. It is the team’s operating model. This does not mean individual development is irrelevant. It means individual development cannot do the work alone. A newly credentialed worker returning to a team that has not redesigned how it makes decisions with AI is like a newly trained pilot returning to an airline that hasn’t updated its cockpit protocols. The individual is ready. The system isn’t. The system is what fails. The organizations navigating the transition well have understood something the retraining model misses: you redesign how teams work, and capability follows. You do not upgrade individuals and hope the team reconfigures around them. Redesigning how teams work means starting with the actual decisions a team makes and the actual workflows it runs, mapping where AI can and should participate, renegotiating the human roles around that participation, and then practicing the new model with real work. It is slower than training. It is harder to fund through traditional channels. It is what actually works. The Raise Us coalition has the resources to fund team-level capability building at scale. They could fund organizations to run AI adoption at the team level rather than the individual level. They could invest in practitioner communities where teams share what they’re learning in real time. They could fund the kind of embedded, real-work learning that the classroom model can’t reach. The money is not the problem. The model is.

The Transition Deserves Better

The workers displaced by AI deserve a serious response. The Raise Us commitment, whatever its design flaws, is a signal that the AI industry is taking the workforce question seriously. That signal matters. The conversation about AI and work has too often been led by people whose economic exposure to the transition is low. The fact that major AI companies are putting significant resources toward this is not nothing. But the workers affected by this transition don’t just need new skills. They need to work in organizations that have figured out how to work differently with AI. Individual retraining that deposits newly credentialed workers into unreconstructed teams is not a transition strategy. It is a deferral. Raimondo herself called the old model ineffective. The question is whether the new money is going toward a different model or the same one at larger scale. The right question to ask of Raise Us, and of every AI adoption initiative, is not how many workers are we retraining. It is how many teams are we rebuilding. That is a harder question to fund. It is also the right one. If you are designing an AI adoption program and wondering what team-level capability building actually looks like in practice, the Collaborative AI Lab is one place to explore it. The design principles are the same ones described here: model the behavior, practice on real work, reflect and rebuild. The transition deserves that kind of rigor. So do the people going through it.

The post The Retraining Trap appeared first on Voltage Control.

In this episode of the Facilitation Lab podcast, host Douglas Ferguson interviews Yvette Cronje, Head of UX Design for HP’s unified consumer app experience, about how design leadership is shifting as AI compresses production time. Cronje argues that AI hasn’t removed the hard part of design so much as relocated it: craft is shifting from executing pixels to judgment, taste, and critique, and teams need shared principles and decision frameworks in place before they diverge into AI-generated options, or misalignment simply accelerates alongside execution. She and Ferguson trace how this plays out in practice, from workshops that align teams on principles before production, to using AI as a critique partner and coaching tool rather than a production shortcut, to the delegation and communication skills leaders increasingly need as ICs manage AI collaborators. They also discuss trust, both customers’ trust in AI-driven product features and organizational trust in people through constant change, as a central design and leadership problem. The conversation closes on reframing AI anxiety as an opportunity for curiosity and growth rather than a threat to craft or job security.

Show Highlights

[00:02:14] Designers Fearing Job Loss To AI
[00:05:10] Learning While Doing, Not Separately
[00:08:40] Craft As Judgment, Not Pixel Pushing
[00:12:05] Aligning On Principles Before Production
[00:18:30] AI Can Make Weak Thinking Look Polished
[00:24:50] Friction And Conflict As The Pearl
[00:31:15] Customer Trust In Automated AI Features
[00:35:40] Delegation Skills For Former Individual Contributors
[00:42:20] Building A Personal AI Coach

Links | Resources

Yvette Cronje on LinkedIn

About the Guest

Yvette Cronje is a product design leader who currently leads UX Design for HP’s unified consumer app experience, bringing previously separate products and services together into an ecosystem used by more than 23 million people each month. She describes herself as a designer at heart and a leader by practice, someone who is happiest moving between big-picture product strategy and the smallest details of craft. On the show she speaks about cultivating team autonomy, running workshops that align teams around shared principles and decision frameworks before diving into AI-assisted ideation, and building psychological safety so designers can grow through difficult, conflict-filled moments rather than avoid them. She is especially focused on the intersection of design, technology, AI, and human behavior, including how design teams stay relevant as AI changes the nature of craft.

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 joined by Yvette Cronje, head of UX design for HP’s unified customer app experience, where she leads the work of bringing a complex ecosystem of products and services together into one experience used by millions of people. Yvette is a designer at heart and a leader by practice, someone who loves the messy space between product, technology, and human behavior, and believes the best design work happens when you’re willing to get close to both the problem and the people experiencing it. Welcome to the show, Yvette.

Yvette Cronje: Hi. Thank you, Douglas. So, good to be here.

Douglas Ferguson: Yeah, I’m looking forward to chatting. It’s such a fun moment to be in right now with all this change. And especially as a designer, I’m sure if you’re looking at that intersection between the problem and the people, it’s such a great moment to be thinking and designing.

Yvette Cronje: Yeah, absolutely. There’s always problems and there’s always people. We’re never going to be about a job here.

Douglas Ferguson: Right. What have you been noticing lately? I mean, there’s so much change in there. I’m curious, what are some of the things that have been popping up for you lately?

Yvette Cronje: Yeah, there’s a couple of things actually, but I would say the main ones is, I mean, I think this is a very natural response, is designers specifically thinking my job is going to be taken over by AI and the fear that is coming with that. And I think as a leader, what I’m trying to facilitate is rather than fear, how can you get excited about it? What does this change about how you do your job and the value that you specifically bring as a designer? So, that the only thing that I always say is the only constant in life is change. And the people who are able to work through that change and live with that change are the people who thrive. You want your people to thrive and design to thrive. And so, with that comes the ability to adapt with change and how I always think about be like water, go around the rocks, don’t be a rock. You’re not the rock, you’re the water that flows and brings all of it together. And that’s the real power of design and the value that they bring. So, I think to sum that up, just managing a lot of the emotional and mental thought around how AI is changing their world. And then once I get over that, it is, “Well, okay, well, how do we use this? The tool keeps changing under our feet every, I don’t know, couple of days.” It’s this constant change now. It’s not just about, okay, let me learn it and I’m once and done. It’s constant learning and how do you keep that going on your team while you’re delivering product? So, you want to be doing learning and curiosity and teaching, but also, and we have deadlines and deliveries, let’s keep going on that.

Douglas Ferguson: Yeah. How have you struck that balance between skating in front of the puck, but also keeping the trains running and the deliverables flowing?

Yvette Cronje: That’s hard. It’s not easy. Many years ago, I did Seth Godin’s altMBA workshop course, and the one thing that I found really valuable in that course was the work is in the doing. You don’t go and do a course and come back and you spend 12 hours on doing the course and then you spend another 12 hours on doing your actual work. “Hey, let’s compress that and let’s figure out how we can learn while we are doing.” And sometimes you have a bit of ebb and flow. Sometimes you need to just get in and get something done, and sometimes you have a bit more time. And I think it’s helping the team notice when you can explore a bit more, use the tools to help you get to your end deliverable. But basically it’s like learn while you’re doing, and maybe you’re taking a bit of extra time for a little bit, but that’s okay because you’ve learned something that’s going to help you accelerate in your next delivery. And making space for that I think is important.

Douglas Ferguson: I think also too, sometimes it’s not about efficiency, but finding a better approach or finding a novel new solution. It could be a whole new revenue stream that we unlock because we took the time to explore a different path.

Yvette Cronje: Yeah, that’s actually a really good point. Yeah, because I mean, in many ways we are reshaping how we do design and within that space comes, like you said, discovering new ways and new things. And if you think about generative AI, that actually made me think of something now is the paths and the use cases and the outcomes could be very different from what we traditionally would’ve thought because AI makes us diverge a lot quicker. And in that divergence, you’re like, “Oh, well, I never thought of that. Thank you so much.” But also what are our constraints that we’re working in and how do we keep the goal that we’re trying to keep? But I think it’s awesome. It’s great.

Douglas Ferguson: Coming back to the emotional piece, I feel that so many folks are in this moment of they’re feeling a sense of loss, like the craft is slipping away from them. But I would argue, and I see this in design and product and engineering, I think maybe engineering and design more so than product just because I feel like engineers and designers have a deeper sense of love of craft, right? And not that it’s not there on product, but it’s just super, super deep and almost like sometimes it’s like they’re zealots, right?

Yvette Cronje: Yeah.

Douglas Ferguson: And I think the issue is when the practices start to take a hole more deeply than the principles. That’s something I’ve found as helpful is helping root people back in the principles, because if we apply the principles in this new era and how these new tools are influencing how the principles show up, then we can throw away the practices and say goodbye to them and be okay with that.

Yvette Cronje: That’s actually, yeah, really good point. It’s interesting because actually we just had a really fun workshop on a new feature that we want to launch. And one of the big things in the workshop was discussing our principles, was creating that initial alignment because I mean, I’ll get to your point about craft in a minute, but it just made me think of how important that beginning part of the alignment is and experience principles very much falls in that initial bucket of, “Hey, do we all agree on these things?” And then it makes the craft and the production that much easier. But I’ve also thought that, I don’t know, the output of AI, I’m a bit of a zealot. The output of AI for me is not always super amazing. It’s not always around what I would call beautiful, innovative craft. And that’s where I think I want to help my designers and the team to not have that fear that their job’s going to be taken away because your craft is super important still. You have the eye, you have the taste, you’ve honed your judgment and your taste over years of being in challenging situations and living next to the customer and hearing from the customer and understanding businesses. And sure, AI can arguably understand all of that as well, but it’s only going to be as good as the input that you give it. And that’s where our design systems come in and the attention to detail and AI can definitely make our production faster. I mean I haven’t personally seen how it necessarily up levels craft as much as humans still can in many ways.

Douglas Ferguson: Yeah, I agree. And I think of it less as upleveling craft and more that it’s transitioning or evolving craft. Because to your point, judgment, critique, attention to detail, these are what I would classify in the principles bucket. We have to hold onto those because you’re not doing design if you’re not doing those things. Whereas moving the pixels around inside of Figma, maybe that’s not really the craft after all. What are the principles that we need to hold dear to and what do we need to let go of, I think is an interesting conversation. And it’s awesome that y’all are having the conversation around principles in your workshop because rerouting, grounding in them is really helpful in this moment because to your point, if everything’s changing around us, what do we need to hold tightly and what is that footing that we can stand on?

Yvette Cronje: Yeah, because ultimately in those moments, everyone’s a designer, a product manager’s a designer, an engineer is a designer. We’re all going to be making little prototypes. I mean, our product managers, which has been pretty awesome actually, make little prototypes early on to illustrate their requirements. It’s not the final product by any means, but they’re using that. And engineers make proof of concepts. And so, the whole process is fraught with a lot of visual stimulation and input coming from AI. But if we align on our principles early on, when that engineer is sitting doing his prototype and the product manager is doing their version, whatever, it can cause problems if we don’t have those principles early on. But if you do have them, you’re like, okay, well, this is the approach that I’m going to take. I’m asking myself those five questions while I’m doing it, and therefore it creates more alignment actually earlier on, which is a really fun way of working because you’re making those thoughts tangible quicker into something that I can see and use quicker. And I think that’s really fun.

Douglas Ferguson: I love that. And it kind of gets a little bit into how there’s layers of principles, right? We can be principled about how we do our engineering. We can be principled about how we do our design. We can be principled about how we approach this project, how the organization operates, right? And in the examples you were just giving, it’s kind of in that category of being principled about how we work together as a team and how we make decisions, what happens when there’s conflict. And I think it’s really powerful for groups to have those conversations up front when you’re kicking off a new project or even just there’s a moment of reflection or review on a long-running project because so often, it’s easier for us to get in our little silos, whether that’s in our functional silo or our individual personal silo. And the more we can discuss these things and get clear about them, the more it’s easier for us to collaborate.

Yvette Cronje: Yeah. And it’s also easier to not over-index on our personal taste or our personal opinions. It up levels the whole team and we say, “Well, we agreed on, what can we come back that we agreed on? It doesn’t mean we can’t change those things, but let’s have a discussion around it.” And so, it becomes this constant bubble of a team, this organism that’s moving together through the process to get the work done. And one of the other really helpful things that we did in that workshop after the principles was thinking through our decision frameworks and decision matrices. And every org has its bias because it has to, it’s what it specializes in. But that’s another thing that helps us when we think about, “Okay, well now we’re all going to dive into AI and go create multiple hundreds of ideas and things.” But if we have that decision matrix, not only for our own brains, but also for AI to input that into the AI, AI becomes your teammate. It becomes another aligned teammate that can just superpower, make a hundred options very easy.

Douglas Ferguson: Yeah, that reminds me, we were just talking yesterday in the mastermind about how often the AI isn’t aware of the decisions we decided not to make because the context we give it is really kind of, I would say, idealistic or it’s clean. We filtered it down to here’s where we decided to go, here’s what we want to do, and here are the requirements, but we rarely come back to these things that we decided not to do and the rationale for why not to do them, right? And so, that’s a fascinating thing that the humans often have context on, but our AI companions don’t necessarily see that stuff.

Yvette Cronje: Yeah, exactly. The things that you didn’t think of or the things that you’re purposely leaving out, giving it that context. Yeah, really important point. And that’s one of the things that I’m also seeing is the ability to make sure that the AI is also asking you good questions so that it’s not just a workhorse, but you’re saying, “Well, go ahead and ask me these questions. Go ahead and tell me what gaps are you seeing, especially if you weren’t detailed enough upfront that it becomes a critical conversation before it becomes a solution.”

Douglas Ferguson: Yeah. I think often because AI is so powerful at generating pretty convincing stuff, I mean, you criticized it earlier saying that you still feel like there’s some gaps there and whatnot, but at the end of the day, it is pretty convincing and pretty finished, finite looking. And I think that’s another skill that, to your point earlier, this important skill of being comfortable with change and curious and constantly learning. But also I think we need to build the skill of planning and interrogating with the AI before just having it build stuff.

Yvette Cronje: Yeah. And then also to go hand in hand with that is the ability to critique it is like you said, AI can make, I don’t want to call it weak thinking, but for the lack of better words, let me just say that. It can make weak thinking look beautiful and look polished if you don’t have those clear boundaries and the principles and everything we spoke about earlier to be able to make good judgment of it and to say, “Well, this is not going to have the last say. How do we as a team come together and decide how did it think about it?” And that’s our value now is how are we thinking about the problem? Is it solving the right problem? Is it solving problems I didn’t even ask it to solve in the first place? Because it looks pretty potentially and it’s, “Oh, the pixels are aligned, therefore it’s great. No, no, what is the problem it’s actually solving?”

Douglas Ferguson: I think oftentimes that’s a real risk. I mean, we saw that before the arrival of AI where folks were starting with the solution and they hadn’t really articulated the problem yet. And I think the fact that you can build so many solutions so quickly now, people are at risk of continuing to skip that step. And it’s almost, I would say, amplifying that dysfunction around if we don’t have that alignment, we don’t have that visibility into the why. It’s funny, I’ve seen that show up a ton too around folks like, “How are we going to put AI into our product?” And I always say, “I can critique this architectural approach to using bedrock or whatever other tools that you’re considering, but we haven’t even begun to talk about the why yet. What’s the business need for this, right? And to your point, where’s the intersection of this problem and the people experiencing it, right? If we don’t understand that, then we probably need to stop and go.” And we might use AI to figure some of that out or help aid us in our exploration. We certainly don’t want to just spin up a bunch of AI agents to build that solution when we don’t understand it deep enough.

Yvette Cronje: Yeah, that’s a really good point. And it’s funny that you say that. Well, there’s two things that really stood out of what you said. The first one was how you jump to the solution too quickly. And that’s an interesting space for design because I feel like in many organizations for a long time, that’s kind of how organizations operated. They would come to design and say, “Hey, I need a screen with a blue button and a heading,” and the designer would do it or whatever. And I think the industry has worked so hard to get us to, well, are we solving the right problem? And the value, that upstream value of doing that, AI is just, like you said, amplifying the problem in a different way now because that designer that had to do that took a couple of days and now it’s instant. But it’s sort of the same problem that was before. And I think therein lies the opportunity for teams to be like, “Hey, no, no, this looks like a familiar pattern. Let’s go back to what we know we need to be doing, which is solving the right problem.”

Douglas Ferguson: So, let me bring us back to something you were saying earlier around how you were starting with the principles and purpose. And it got me to thinking about this idea of creating a symbiotic organization where currently a lot of what we see is engineers are experimenting with creating prototypes and they’re maybe moving a little bit more into the design space. You’ve got folks that are, to your point, designers can even create functional prototypes and whatnot. And if everyone’s just figuring that stuff out on their own, then they’re not necessarily operating in ways that are going to be most helpful to how the organization evolves together. And so, having these workshops that either start with principals or check-ins where we’re talking about this stuff means that we can influence each other’s thinking. So, then when we are experimenting outside of our classical wheelhouse, we’re doing it in a way that’s informed by what the others need and how the others are thinking. And then if we’re sharing our experiments and there’s touch points and moments where that stuff can get bubbled up, it allows us to be a little bit more symbiotic, even though we might be doing our own experiments. If we think of our own function as being an organ in the body, it’s like, yes, we’re optimizing for what the stomach needs to do, but we’re not doing it at the detriment of the blood system or whatever.

Yvette Cronje: Yeah, that’s probably the best analogy. It’s such a human analogy to this technical problem. I actually love it. I feel like you can write a book on it, Douglas. But no, it’s a really good point because it gets to that moment of look, AI can accelerate misalignment just as easily as it can accelerate execution, right? And so, for us to be able to get to this aligned space means getting those principles upfront, getting the decision matrices upfront, because everyone’s going to use a different tool. Engineering, product, design, everyone’s using different. It’s not about, “Hey, everyone needs to be using the same tool and in the same space.” And it’s not about the tool. It’s about how do we create shared context? How do we create shared evidence? How do we make sure that we are all sharing the same problem? What is the problem that we’re trying to solve? Shared criteria, shared outcome. It’s this shared, the body system has a shared holder, it has a shared constraint, your organs have constraints, and it’s the same for us. There’s a book called, it’s actually called A Beautiful Constraint, and it’s a beautiful book because it describes how it is the constraint that helps you make something beautiful and useful. And I think having those upfront before you unleash and go and diverge helps create a shared understanding of teams.

Douglas Ferguson: Yeah, it’s interesting that you’re talking about the constraint. It made me think about the pearl, right? It’s like the pearl doesn’t form under ideal circumstances. It’s like this impurity or this thing got in there that made it start to form. And it’s similar to this concept we talk about, which is conflict or friction can often point to the fact that the good stuff is happening. Or if we really attend to it, that might point us toward where we need to go. And quite often, people ignore it or they try to optimize around it, right? And if instead, if we open that up as a conversation and it’s an opportunity for the team to heal or to explore some new territory that was unclear to them, but that opacity was what was causing that friction. And until we confront it, we can’t really expose it, understand it, and move through it.

Yvette Cronje: Yeah. And if we want to call it conflict or misunderstanding or challenges or difficulty, I think it’s in line with what you’re saying, it’s reminding me of this notion of it almost can feel like because AI is so easy, I’m wondering, does it feel to people like, “Oh, it’s removing the conflict or it’s making my life so easy. I don’t need to think about conflict or difficult moments.” And especially if I think about junior designers and people, new people coming into the team and how we grow people, it’s like the fundamental things that you need to be good at needs to be learned in those difficult moments. We need to understand the conflict and how to navigate that and, yeah, how to stay curious. And what’s one of my biggest principles I think is, and it’s maybe a bit cliche, but it’s true, right? If you stay curious around the problem, it can lead to really, really amazing outcomes at the end of the day. Embrace your challenges, all those. And those are the skills that we’re having to learn up front, because if you think about it, when you’re in these workshops, and that’s where a lot of that stuff bubbles up, and then it makes production just fun and exploratory and getting to the deadline, and you can have those friction moments, which are growth moments upfront. But that’s the magic really, really. It’s the pearl.

Douglas Ferguson: Yeah. Yeah. We always talk about creating almost these temporary moments that feel very special or different. We’re asking people to step into behaviors that they don’t embody every day. And then I feel that gives them the freedom to maybe be more curious than they normally would be or to let go of some of the guards a bit. And so, I do think these imaginary worlds that we ask people to step into can be quite powerful. I think teams ought to do it more.

Yvette Cronje: Yeah. It makes me think of when we are using AI in our production and our ideation, all of that, you can almost think of it’s not going to be perfect out the gate. And how do we become comfortable with that? Because if you can become comfortable with “failure” or you tried something and it didn’t work, but what did you learn? And AI does a bit of that because it’s going to spit out, it’s going to create a hundred options for you. Not all of them are going to be great and that’s okay. So, then, okay, let’s work through this. Let’s decide, let’s hone our judgment, let’s work on our taste. Let’s be comfortable with that discomfort moment.

Douglas Ferguson: Yeah, I’ve been hearing a lot of folks shifting from, or maybe not shifting from, but adding to their typical metrics more of almost innovation accounting type of techniques where they’re measuring lessons learned. So, they’re using this moment to not only measure business outcomes and value direct bottom line revenue type goals, but also what are we learning? Especially in this moment right now, it’s like, are we leveling up in a way, not only as far as what the tools can do and how we might function in this new AI world, but also what are we learning about the customer? What are we learning about the market? What are we learning about where the business could go? Those are all very valuable things because those are things we can build on top of.

Yvette Cronje: Yeah. And I think arguably because AI is making some of our production easier and taking away some of the slog work, it allows us to focus on those aspects a lot more potentially and to highlight them to the organization and once again, share it with each other. It’s so easy to sit in a silo and have this understanding, but you’re having to come together more with people and share that understanding. And if I think about research and getting to know the customer, this is that moment that that can be highlighted way upfront in the process strategically and we can stop changing even how we make strategic decisions. What is this product that we’re creating? Why are we doing this? Are we solving the right problem for the customer? Who is our customer? Our customers are changing as well. As much as what we are changing, our customers are also changing. And that’s kind of a full circle moment for us to realize.

Douglas Ferguson: And I think we’re only in the beginning there. You think about AI LLM adoption, it’s somewhat gated by… Well, I’ll just say this. Once it’s pervasive across mobile devices and embedded in really significant ways, I think we’re going to start to see expectations from consumers in ways that are unprecedented, right? So, that to your point, the customer changing, we’re just in the beginning there.

Yvette Cronje: Yeah. That workshop that I was referring to earlier, some of the initial concepts, there was a lot of AI baked into our concepts of, let’s say, automated things that it’s doing for you upfront because it knows who you are. “Oh, Douglas, I know you’re on Zoom between 9:00 and 5:00. I’m just going to make your lighting and audio and everything perfect for you and pull that all together with your devices.” And it was very interesting, the mixed feedback that we got from customers, because I would say the majority of them had massive trust issues before they were excited about what it could do for them. And now we are having to learn, okay, it’s not just about, oh, this is a really cool feature. How do we get people to use it? Or getting excited about that. It’s also about how do we build trust and allow people to keep the control, help them feel like, okay, I’m still in control of this. This thing isn’t taking over my life. It’s going to become an interesting problem, I think, with the pervasiveness of AI and products.

Douglas Ferguson: Trust is such a fascinating one because there’s so many layers and so many attributes to think about, because you talked about folks having a sense of loss of control, so that’s an element. There’s also people under trusting it, and so then they don’t want to necessarily. In some cases, it’s not lacking control. It’s a fear of it’s going to blow up on them and cause them huge headaches. So, they’d be happy to let go of the control if they actually trusted it. And then the other side is over trust where people think it can solve all these problems and it can’t. So, it’s a fascinating one. And then also I’ve seen trust come up in these conversations too around trust in the organization. Is the org going to support you? Are they going to continue to invest in finding ways to keep the humans around? Trust is a huge complex issue as it relates to all this work.

Yvette Cronje: It is. It really is. Yeah, the org is a difficult one as well, I think, because there’s a lot of that that you’re not in control of as a team. You live at the edge of after the decision has been made, and then having to work within that constraint and figure out, “Well, okay, how are we going to work with that?” It’s often not as ideal as you would wish. I think employees are always like, “Well, I wish this if I had my ideal world.” But that’s rarely the case. And so, yeah, once again, being able to work and produce and be really proud of your work in environments that are constantly changing because the orgs are now changing about as quick as the technology in many spaces. It’s people coming and going and there’s a lot of change. So, a lot of our role I think as leaders is change management, not only of how the work’s being done, but what’s happening in the company and our organizations. But the other thing I was thinking about was also the value of designers. And if we think about these experiences in our customers and how they think about trust in AI, I wonder if it’s also just shifting a lot towards, “Okay, now we as UX people need to help the customer understand what is the AI doing? Why is it doing it? How do you correct it if it’s doing the wrong thing? How do you control it?” But it needs to not be a laborious extra thing that you now need to manage in your life. It needs to feel easy and light and delightful, and this is helpful in my life. It’s not another chore. Great, thank you company X, you’ve given me another chore with your product that I didn’t want.

Douglas Ferguson: It makes me think about how, especially the builders, so the engineers, designers, if you’ve gone down this route of being the IC, the principled engineer, the distinguished designer, you maybe made that choice intentionally down that path because you didn’t want to manage people. And so, you’re never trained on delegation skills. And now you have to delegate pretty effectively to get the best out of these tools. And so, I think as leaders, the more we can help people get comfortable with delegation, I’ve seen that be a big point of friction with some of the folks that are actively resisting. Once I peel back the layers, the delegation is a big piece of it. It’s like, I didn’t sign up to be a manager. And it’s like, okay, well the future of creating this stuff is going to demand some of these skills.

Yvette Cronje: Yeah. You hit the nail on the head because one thing that I’ve always tried to cultivate on my teams is the ability for team members to give input into each other’s work. I never want the leader to be the be and end all of decision making. And if it hasn’t passed through me, we’re not doing anything. The team needs to become autonomous enough. There’s this thing that I keep saying is I want a team that is so strong that no one knows who the leader is. And so, I try to hone that. I’ve always tried to hone that ability for people to, okay, well tell me what you guys think of it. Give each other critique. And now to your point, it’s becoming give the AI critique. It’s making you almost be a bit of a creative director and a manager to your point. And don’t just accept what it gives you because it looks good. It is such a good point actually. Yeah, you’re right. The strength of the craft is shifting.

Douglas Ferguson: Yeah. Absolutely. And I think it’s only going to grow over time as people get more comfortable using agents and sub-agents and there’s just a lot more things will happen in parallel. And so, how do we describe the work? How do we evaluate it? All these things that are going to be critical to managing a fleet of these coworkers, if you will.

Yvette Cronje: Yeah. But I also think it’s helping us be better communicators when we are in those initial alignment workshops, and especially in a world where many of us are still working virtually. Many of us, I mean, most of the people I work with are not in my location and communicating and creating connection over a virtual space is really hard. We all know when you meet a human in person, it becomes different, but you need to learn to communicate well so that one meeting doesn’t turn into 10 meetings. And arguably the skillset with AI is going to help us also. I think it could help us be better communicators.

Douglas Ferguson: Absolutely. Never have we been in a better position to tell good stories. I argue that a good story really hinges on our ability to understand the audience and to meet the audience with adapt the narrative to the audience, right? And so, gosh, if you built the prototype and you’re going to share it with engineering, heck, even three different engineering teams might care about different things, right? The security team might care about hearing about different stuff about that prototype. They might have different questions than the front end team or even leadership or the customer. I think these tools can help us adapt the narrative, the pitch, et cetera, to whoever we’re speaking to. And that’s something I really encourage folks to lean into is it doesn’t have to be one size fits all now because we can generate so many different versions.

Yvette Cronje: So true. And it also elevates us being able to explain our thinking because how you explain your thinking to an engineer is different to how you explain your thinking to a leader who’s trying to sign off on the project. It might be similar thinking, it might have a similar outcome, but that thought process and what matters to that person shapes very much how you describe your thought process about the solution. And I think that’s just awesome. That’s fun. It’s like iron sharpening iron is what it’s doing to us.

Douglas Ferguson: I love that. You’re making me think about metacognition, thinking about thinking and not a lot of people are comfortable with that. Some folks just, when it gets too introspective, maybe there’s a quarter turn of the crank and then they just jam up and stop. Whereas some people just take to it very naturally and they can describe how they do things and how they came to conclusions. But others might be a little more inherent or they can’t necessarily put words to it, but they can arrive at the answer, at the conclusion. They can maybe back it up with some evidence. But I’ve found AI, if you interrogate it well, can help you with some of that reflection, especially for folks that get a little stuck. It can be that thing, that coach that keeps nudging you and asking questions to get you to find those deeper answers. And I just encourage folks to find those novel ways to use it versus just say, “Build a thing for me,” because there’s so much more you can get out of it if you keep nudging at it and finding novel ways to explore maybe almost even personal weaknesses.

Yvette Cronje: Yeah, that’s a good one. That’s a really good one. You’re making me think of something that I now want to go do immediately after this.

Douglas Ferguson: Love it.

Yvette Cronje: Is what if you had every person on your team create a personal coach for themselves, like a business coach or a, “Hey, I’m a junior designer. I want to become a senior designer. I want you to be a coach to me.” And have that constantly running for themselves. Because one of the things that I want to start doing as my team, and we’ve been working on a structure for this, is this sort of couch to 5K program is looking at each person on the team and thinking, “Okay, what does this team need?” Every designer is different and you have a visual designer and a UX designer and a creative technologist and a researcher, and they all have different needs and purposes within the process. How do we say we’re going to use AI to our advantage as a team? And a lot of that came down to the craft was really the very last step. All of the beginning stuff was, how do you think? How do you get it to be a partner for you while you’re thinking? How do you get it to ask critical questions to you while you’re going through your thought process? The base of that took a lot more of that sort of program than the actual production of it. And it made the production a lot more fun and less frustrating because also you’re getting to this place were you’re like, “Oh no, that’s not right, make this green. Oh no, that’s not right.” And you’re getting super frustrated versus all of the fun of the thinking process. And it also makes me think of psychological safety, how you mentioned some people might not be comfortable with thinking and talking through that thought process. It’s like, okay, so how do we as leaders really hone in on creating safety within our teams to be able to just say what you want to say? That’s how you learn. Let’s not shame it. Let’s not critique it. Let’s correct and ask good questions to the person to help them really grow.

Douglas Ferguson: Yeah. And to that point, you were making me think how valuable it is as a one-on-one tool. A lot of people record meetings and then use the meeting summaries, but I highly recommend leaders before, don’t just send out the summary, have a conversation with the agent about the transcript and shape it as a leader. Include things you know about that individual and push back on things that they’ve determined. Don’t let it just pick the next steps. Work with it as a companion, as almost like your coach to then give better coaching to the individual. And then if they also have their coach set up, they could take the transcript from the one-on-one plus your additional thoughts and bring that in. It’s like your one-on-one turns into a much deeper interaction because it’s not just the 15 or 30 minutes that you can spend with each employee. It’s like that plus the three to five minutes you spent with the agent refining it and then plus the time they spend with their agent refining it. And I don’t know, it can go much deeper and folks can maybe find better footing.

Yvette Cronje: That’s so true. That is such a good point. I did something, I myself also record meetings and have AI tools summarize them for me. And the other day, I was reading through one of them and I was like, “I feel like the summary is missing some things here.” So, I fed it into another AI that knows a bunch of stuff about the project and the people and whatever, and it was like, “Yeah, it’s missing a couple of things.” So, that summary came back quite different. And then I was like, “Ah, yeah.” I think there’s a couple of other things also. There’s nuance that it doesn’t pick tone of voice and skill sets of who the people are. And that’s where you as a people manager, you know these things, use them to grow your people and to move the project forward. And that’s your superpower now.

Douglas Ferguson: Yep. It’s funny because the same person that says, “This thing’s coming from my job,” is the same person I hear saying, “It’s not getting everything right.” And it’s like, do you realize how profoundly disconnected that is? You should realize that, “Oh, it’s not coming from my job because I’m noticing it’s leaving things out, but yet I can use this as a way for me to refine my thinking.” It might’ve pointed out something I had forgot because unless you have a photographic memory, you’re probably going to miss some things. And honestly, it’s a great stimulus for being reminded of the things that it left out because it mentioned X, Y, and Z. You’re like, “Oh, but we talked about A between B and C,” or whatever. And so, I feel like rather than being over judgmental on it or overly worried about it, why not lean into it and think about, “Well, what can this do for me?”

Yvette Cronje: Yeah. And this reminds me of that principle, since we were talking about principles of, maybe this is because one of my core skills is being a learning, I enjoy learning. I could have been a student the rest of my life and been happy if I could get paid for it, but it’s that notion of nothing is ever wasted. If you have the perspective of always, literally always trying to take something out of something, there’s nothing that you can say, “Nothing gets wasted in my life.” Sure, I might not have used the 10 rules and or the 10 steps exactly like that, but what did I use and how did this shape me as a person and how did this impact or influence another person or a project or whatever? And sometimes, it’s things that you’re not going to see right now. You’re going to see them come to fruition months or years from now in a person or probably whatever that might be. And it’s like that sort of skillset to be able to say, “Well, I believe that I’ve learned something anyway.”

Douglas Ferguson: I love that. It comes back to that growth mindset and curiosity, and it also reminds me of the adage, “All models are wrong, but some are useful.” And if you can be the kind of person that finds as many models as possible useful, how can I apply this versus the kind of person that’s like, “Well, this is garbage, it doesn’t work,” right? It’s like being overly critical and dismissive of too many things doesn’t really leave us much ability to wonder and repurpose and reapply.

Yvette Cronje: Wonder.

Douglas Ferguson: And that’s where most innovation comes from, is when we’re able to take something and reuse it for a new purpose. The microwave oven is one of the prime examples of that, right?

Yvette Cronje: Yeah. Yeah. Yeah, notability, I love what you said about wonder. One of our leaders constantly says that, they say, “Always keep your sense of wonder.” And even was it Leonardo da Vinci that said, “I’m not really a good artist at all. I’m just extremely curious.” And it made him do amazing things, and that’s a pretty amazing space to be in, I think.

Douglas Ferguson: Absolutely. Just hang around with kids more if you want to tap into your wonder. They have endless amounts of it. Somehow we lose it over time or it gets beaten out of us or something. I’m not sure. Well, we’re kind of coming up on our end here, so I want to give you an opportunity to leave our listeners with a final thought.

Yvette Cronje: Yeah. I hope that designers and folks in our industry can get really excited about this versus fearful that they can move into a space where let the AI do all of the production and the slog work for me, but really get excited about how this changes the value that you bring towards the world, not just your product or whatever, really the world, because we’re applying all of these things in the rest of our lives as well. And it’s a very exciting moment. I think, like you said, if we can lean into the excitement and the opportunity of it, I think it’s going to open up a lot more doorways and innovation, thinking about new products or new ways of doing things. I just think there’s a lot of space for that and I’m hoping people can get excited.

Douglas Ferguson: Totally agree. Well, it’s been a pleasure chatting with you and hopefully, we’ll chat more again sometime soon.

Yvette Cronje: Yeah, absolutely. It’s always good to chat with you, Douglas. Thanks for the lively conversation. I really enjoyed 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 AI Doesn’t Remove Friction, It Moves the Bottleneck to Judgment appeared first on Voltage Control.

Four in five organizations deploying autonomous capability cut headcount. The cuts did not produce the returns. Here is the AI investment strategy that does.

Roughly four out of five organizations that have piloted or deployed autonomous business capability have reduced their workforce. That number is not the surprising part. The surprising part is what sits next to it: the rate of workforce reduction is nearly the same at organizations reporting strong returns and at organizations reporting modest or negative ones. Read that twice, because it dismantles the most common AI business case in the market. The cuts are not what separates the organizations getting returns from the ones that are not. Both groups cut at about the same rate. Something else is doing the work. Helen Poitevin, a Distinguished VP Analyst at Gartner, put it about as plainly as an analyst firm puts anything: “Workforce reductions may create budget room, but they do not create return.”

The Contradiction Is Not Hiding in the Research

It would be satisfying to claim we spotted something the analysts missed. We did not. They named it, out loud, in a press release, and they named the alternative too. Poitevin again: “Organizations that improve ROI are not those that eliminate the need for people, but those that amplify them by aggressively investing more in skills, roles and operating models that allow humans to guide and scale autonomous systems.” The same research program had already flagged the tension from the other direction. In the 2026 CEO survey, 80% of CEOs said they expect AI to force a high or medium degree of change to their operational capabilities, and 39% already count AI agents as employees. Those same CEOs rank people as a top capability for organizational resilience, and the survey results simultaneously show a reluctance to hire alongside an expectation that AI agents will serve as a lower-cost workforce. So the contradiction is documented, published, and available to anyone who reads the press release. The research rates people as the top resilience capability and records a reluctance to hire them. Which makes the interesting question a different one. Not “why has nobody said this,” but “why does knowing it change so little?” The advice has been public since May. The spending pattern has not moved.

Cost Is Legible. Capability Is Not.

Here is the honest mechanism, and it is not stupidity. A headcount reduction produces a number you can put in a board deck this quarter. It has a date, a dollar figure, and a name attached to the decision. Investment in skills, role design, and operating models produces a number nobody can isolate. If it works, the organization simply keeps functioning well, which looks like nothing happening. One side of the ledger is instrumented and the other is not. That asymmetry, not a failure of insight, is what keeps the pattern running after the research says it does not work. Leaders are optimizing for the thing they can prove they did. We see this in the rooms we facilitate constantly. The AI investment gets a business case, a steering committee, and a dashboard. The capability investment gets a training budget line and a hope that people will figure it out. Then, six months later, the tools are deployed, the work has not actually changed, and everyone is puzzled about why.

The Capability You Cut Is the One That Governs the System

Gartner’s framing for what autonomous business actually requires is a useful piece of vocabulary: humans to guide, govern, expand, and transition autonomous capability. Sit with those four verbs, because every one of them is a judgment activity. To guide a system you have to know what good output looks like. To govern it you have to recognize a bad answer that is confidently phrased. To expand it you have to see which adjacent work is genuinely similar and which only looks similar. To transition to it you have to run a change with people who trust you. None of that is knowledge you can hire in a quarter, and none of it lives in documentation. It is accumulated judgment, and judgment gets built by doing consequential work and being wrong in front of someone more experienced. This is where the cut and the capability collide. The work being automated first is precisely the work that used to build the judgment. The junior analysis, the first-pass draft, the routine review: developmentally rich, individually unremarkable, and the easiest thing in the organization to hand to a model.

Where the Pipeline Narrows, and Where It Does Not

Some of this compression is already measurable. Researchers at the Stanford Digital Economy Lab found that early-career workers aged 22 to 25 in the most AI-exposed occupations have seen a 16% relative decline in employment since generative AI came into wide use, while employment held steady or grew for less exposed workers and for more experienced workers in those same occupations. Be careful with that finding, though, because the evidence is genuinely mixed and the firm-level studies cut the other way. Research pairing corporate AI vendor spending with workforce data found that the heaviest adopters ran employment about 10.2% higher than companies that had not yet adopted, and that their entry-level share rose by 1.15 percentage points relative to non-adopters. Those two findings are not actually in conflict, and holding both is what makes this useful. Exposure and adoption are different things. Whether an occupation is the kind of work a model can do is a different question from whether a given company bought the tools, and the companies investing most aggressively in AI appear to be growing rather than shrinking. Which puts the question back inside your own organization, where it belongs. The aggregate does not tell you whether the work you automated this year was draining or developmental. Only you can know that, and most organizations have never asked. When it does happen, nobody decides to break the apprenticeship pipeline. Nobody holds a meeting about it. Each individual choice is locally correct, and the compounded effect is an organization that will be short of senior judgment in three to five years, precisely when its autonomous systems most need governing. The timing is the cruel part, and it is why this failure mode survives. The consequence arrives on a horizon longer than the tenure of the executive who set the pattern in motion. It looks like a talent shortage in 2029 and gets explained as a market condition.

What the Organizations Getting Returns Do Differently

The pattern among organizations that treat capability as infrastructure rather than overhead is consistent, and it is more specific than “invest in people.” They redesign roles before they automate tasks, not after. The sequence is the whole thing. Automating first and then asking what the remaining humans should do produces a job description assembled from leftovers. They decide deliberately which friction to remove and which to keep. Some friction drains people and should be engineered out without ceremony. Some friction develops them, and removing it is how you end up with a fast organization full of people who cannot make a call. Telling those two apart is the actual executive skill of this decade, and it cannot be delegated to a tools decision. They keep consequential work in human hands on purpose, and they say why out loud. A junior person who understands they are being handed hard work in order to develop experiences it completely differently from one who suspects the organization simply has not gotten around to automating it yet. And they instrument the capability side, even crudely. Any measurement of whether judgment is developing beats the current default, which is to measure the cost side precisely and the capability side not at all.

The Number Worth Watching

Gartner’s own longer-range read is that autonomous business becomes a net-positive job creator by 2028 to 2029, on the argument that demographic decline and high-stakes, trust-dependent customer moments keep human talent central to running and scaling these systems. If that holds, the organizations cutting hardest right now are not getting ahead of a permanent shift. They are taking a temporary cost credit and paying for it with a capability gap that arrives exactly when demand for that capability returns. The correction does not require slowing AI investment. Nobody needs to be talked out of buying the tools. It requires treating the capability to guide, govern, expand, and transition those systems as the thing that makes the tools worth anything, and funding it like infrastructure rather than like a training line item. The analysts have said it. The next survey will show who was listening. Want to explore what closing this gap looks like inside your organization? Learn more about Voltage Control’s AI transformation work.

The post You Cannot Cut Your Way to an Autonomous Business appeared first on Voltage Control.

In this episode of the Facilitation Lab podcast, host Douglas Ferguson interviews Alyssa Coughlin, Director and Chief of Staff for Autodesk’s Data, AI, and ML Platform organization, about what it actually takes to move a large engineering company from AI-enabled to AI-native. Coughlin describes how bottlenecks have shifted away from writing code toward code review, deployment permissions, and design decisions now that AI has made execution fast and cheap. She walks through concrete changes her org has made, including abandoning two-week Scrum sprints for Kanban flow, moving from PRDs to spec-driven development consumable by both humans and AI, and building shared “knowledge graph” brains to catch duplicated work before it ships. Throughout, she frames change management as a balance of carrot and stick, arguing that engineers aren’t losing their jobs so much as shifting from author to orchestrator, and that managers themselves must stay hands-on with the tools to coach effectively. She closes by describing AI as an amplifier that exposes organizational seams rather than a fix, so the real work is continuously finding and addressing the friction it reveals.

Show Highlights

[00:00:00] Framing The New Friction Series
[00:02:15] Shifting From AI Enabled To AI Native
[00:04:00] Bottlenecks Move Upstream To Reviews And Design
[00:06:45] Balancing Change Management With Carrot And Stick
[00:09:15] Mourning The Coder Identity As Orchestrator
[00:11:30] Ditching Scrum Sprints For Kanban Flow
[00:16:00] Building An Autodesk Brain To Avoid Duplication
[00:19:45] Spec Driven Development As A Living Document
[00:22:15] Roles Blurring Across PM, Engineering, And Design
[00:25:30] Closing Thought: AI As An Amplifier

Links | Resources

Alyssa Coughlin on LinkedIn
Voltage Control

About the Guest

Alyssa Coughlin is Director, Chief of Staff for the Data, AI, and ML Platform organization at Autodesk, a role she describes as spanning operating model design, change management, and helping the organization transition from using AI as a tool to treating it as a genuine working partner. Her background is in project management, holding a PMP credential and years of experience across Scrum, Agile, and Kanban practices before landing in this role. She speaks about leading her organization through practical shifts like moving from Scrum to Kanban, adopting spec-driven development, and building shared knowledge graphs to reduce duplicated work, all while managing the human side of a fast-moving AI transition. She frames her core philosophy as treating AI as an amplifier of both strengths and weaknesses in an organization, and as a partner rather than a replacement for human judgment.

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 Alyssa Coughlin at Autodesk, where she is the chief of staff for the organization that builds the data and ML platforms and agentic AI infrastructure. Welcome to the show, Alyssa.

Alyssa Coughlin: Thank you so much for having me. I’m excited to be here.

Douglas Ferguson: Yeah, it’s great to have you. It’s been a minute since we spoke. In fact, I think you embarked on a cross country trek, so lots of change, not only the AI, but you’re having change of environment as well.

Alyssa Coughlin: Yeah. Life wasn’t hectic enough, so why not throw in a cross country move?

Douglas Ferguson: There you go. Amazing. So yeah, I’d be curious just for starters, what are some of the things you’ve been noticing as AI has been more and more prevalent in the workforce?

Alyssa Coughlin: Yeah, the shift has been really interesting. What my teams have been primarily focused on recently is transitioning from AI enabled to AI native. And so what I mean from that is AI adoption is really just do people use the tools? That’s where you start looking at token maxing and are they vibe coding? Are they connecting MCPs? Are they doing all the things, versus AI native is making AI part of the process in the workforce holistically. So from beginning to end and kind of redesigning how we work to incorporate AI as a partner and not just as a tool. So that shift has been really interesting because there’s obviously a really big people and process component to that. And so trying to navigate what that looks like in all of its forms end to end is where we’re really focused right now. And it’s interesting. I mean, we call this podcast the New Friction and the friction’s definitely part of that process.

Douglas Ferguson: What friction have you noticed most prevalent or the most maybe difficult to get your hands around?

Alyssa Coughlin: I think an interesting shift we’ve seen twofold when it comes to friction. One is embracing friction. In an AI native environment, friction becomes another metric. It shows you where there might be seams in your processes or your workflows that weren’t really surfaced before. So looking at that friction and figuring out why it exists, how does being AI native play into that and what does this new way of working that we’re learning based on this friction become? And then related to the friction is, as we shift to AI native, one of the really big things we’re seeing is the bottlenecks shift. So not all that long ago manually coding was fairly time intensive. And so now with AI assisted coding, that’s not the bottleneck anymore. It’s shifted further upstream. So we’re seeing it in reviews, we are seeing it in deployments, things as mundane as permissions. All of a sudden, there’s this backlog of PRs that need to be reviewed before they can be pushed to prod. We’re also seeing it on the other end of the spectrum from an XD perspective. So it used to be that XD and coding were moving at similar speeds, but while XD is leveraging an AI native mentality, there’s still a lot of human intervention in that practice right now. And so that’s another new bottleneck that we’re seeing, is that determining what that true user experience should look like takes longer than actually coding that experience. So we’re seeing the bottlenecks and we’re seeing the friction move to different parts of the workflow than where they’ve historically existed.

Douglas Ferguson: I like to say that these frictions were already there, now they’re becoming the breaking point. Or because we’re sending more stuff through a process that was maybe broken to begin with or something we hadn’t spent a lot of time rehearsing or getting good at.

Alyssa Coughlin: Yeah. And I think a really interesting way to look at it is, AI is an amplifier in all aspects. It amplifies the positive, but it also really amplifies the things that maybe aren’t working as well in your workflows. And so it’s really hard to hide anything in the era of AI. You’re moving faster, you’re doing more. And so these seams and these bottlenecks and these frictions just become more apparent.

Douglas Ferguson: And the role as chief of staff, how is it impacting you personally? Are you being asked to help identify some of these problems, address them or facilitate the conversations where it’s getting addressed? How are you showing up to meet this moment?

Alyssa Coughlin: Yeah, it’s all of the above. Part of becoming AI native is helping to identify what processes need to shift and where. But it’s also really rethinking the operating model and our strategies. We need an operating model that is based on spec driven development and working with AI, not as a tool, but as a partner. We affectionately refer to AI as the intern because it’s quite capable of doing many things, but it doesn’t quite have the expertise to make the hard decisions. And so figuring out what does that look like? How do we shift our ways of working? One of the things we’re doing right now is we are transitioning away from Scrum to Kanban because that’s more conducive to an AI native working speed, especially when you can have multiple agents working on multiple repos simultaneously. So a lot of my job has been trying to figure out what this new way of working looks like in an AI native environment. And obviously there’s a huge people component there. So figuring out how to balance the change management, because obviously everything in this AI revolution, evolution, whatever you want to call it, is moving at a breakneck speed. But if you aren’t thoughtful with how you’re pairing that with change management, the human cost of that can be massive. So in my job, I’m trying to balance how we work from a day-to-day basis, what needs to change, what can we keep, and what do we honestly just need to reinvent?

Douglas Ferguson: So you talk about balance and change management, and it sounded like a big piece of that was just trying to prevent overwhelm or maybe even revolt from folks. And so I’m kind of curious, what are some of the principles or tactics that you’re thinking about when you’re looking at balancing that change management?

Alyssa Coughlin: Yeah, I think the core principle of successful change management is buy-in. It’s getting people to move along with you. And in order to do that, it’s been a little bit of a balance between a carrot and a stick. And so by carrot, I mean making people really excited to meet this moment. I mean, this is one of our biggest technological shifts since the invention of the internet. This is going to completely change the entire world, hopefully for the better, but we’re still sorting that part out too. It makes so much more room for innovation and experimentation and creativity. So really trying to get people to hone in on that excitement and that opportunity, but balancing that with the tough love. AI’s here to stay. We work in tech. It’s not going anywhere. If you don’t like it, I’m going to be honest, this might not be the job for you anymore. So trying to make sure people have an honest understanding of the reality of the situation. But that does not necessarily translate to doom and gloom, it translates to opportunity.

Douglas Ferguson: Yeah. And when you think about the cross section of the org, the team, what would you say… Is this resistance prominent or is it a small subset? And follow-up question would be, I’ve seen a wide array through these conversations and dinners and things I’ve been having, a wide array of causes for the resistance. So I’m kind of curious what you’ve been noticing? How prevalent is the resistance and then what are some of the causes that you’ve been seeing?

Alyssa Coughlin: Yeah, I think the prevalence continues to decline. I think at first, I mean, you had tech CEOs who were like, “Oh no, this is going to be apocalyptic. This is going to take everybody’s jobs.” Even this week, Bill Gates is like, “Ah, I don’t know about this.” But I think the more we have understood what working with AI truly means, the more we’re able to realize that it’s not getting rid of jobs, it’s not getting rid of work, it’s changing what that work looks like. And so helping people understand that shift, I think has led to a continual decline of people who aren’t really bought in on the whole AI native transition. So I think that’s one side of it, the people who are like, “AI is going to take my job.” And one of my favorite sayings is, “AI will not take your job, an engineer who’s better at using it will.” So it’s really a matter of do you change? Do you transition? Do you meet this moment? And so that’s the second category of resistance that we do sometimes encounter. And I would say it’s not very frequent, but you do have some people who are just like, “This isn’t what I signed up for. I am an engineer. I’m a coder. I want to put my headphones on and be heads down all day just cranking out lines of code.” And that’s not the job anymore. And so you do have some people who I think are still mourning what being an engineer used to mean, and they’re struggling a little bit to adapt that you’re not a coder anymore, you’re a systems thinker. You’ve moved from the author to the orchestrator. Not everyone wants to be the orchestrator.

Douglas Ferguson: Yep. And a lot of that has to do with the skills they developed over time because to be an orchestrator is a lot more akin to a manager. You got to delegate, you got to evaluate, you got to organize, and you’re not necessarily the one doing the direct work, you’re reviewing the work. And it’s just different skill sets. And engineers have the transferable skills to be able to evaluate good engineering work. In fact, they have to do pull requests quite often, and that’s a key part of the job. That’s just becoming more and more a part of the job. And so I do think there is something to this idea of having this identity loss and even acknowledging the fact that people need to go through that mourning process.

Alyssa Coughlin: They do. And you see that with any change. I’ve heard a lot of people compare this AI revolution to the industrial revolution, and honestly, that scared a lot of people and it made a lot of people think that they were no longer going to be relevant, their jobs weren’t going to matter. We still need just as many, if not more people. It’s what they’re doing that is different. So we have replaced some of that more trivial work with machinery, but that just elevated what the human needs to do. And so this is really similar and it’s not a direct correlation of the progression isn’t human to AI, it’s human with AI, human doing, human directing, human orchestrating, human judging. So the human’s more important than ever because until we have AGI, there’s no reasoning coming from AI. It’s an order taker. And so you still need that human judgment in the

Douglas Ferguson: Loop. Yeah, it’s so true. One example would be your shift to Kanban. So talk about that for a moment. Was Kanban something that you were familiar with prior or is it something new that you had to learn as the team were starting to adopt it?

Alyssa Coughlin: Yeah, my background is in project management and I’m a PMP, so Waterfall, Agile, Kanban, they were all kind of already in my repertoire, but working in tech for the last decade, everything’s obviously been very Scrum heavy. And even though a sprint is traditionally two weeks, in the era of AI native, that’s a long time and that sort of time boxing doesn’t work. And even when you think about the Scrum ceremonies and how you do sprint planning and you have two weeks of work that you’re committing to, and that does not leave a ton of time for experimentation. So it’s not that when we switch to Kanban, Agile’s dead, it’s more the actual practice is shifting. So we’re moving away from a more regimented Scrum ceremony, Scrum timeline, Scrum metrics into we have a prioritized backlog and you pull things out, you work on them. If you get stuck, you put it into a blocked row and it gives us a chance to honestly be more agile and more nimble than we could with Scrum. And with Scrum, you’re committing to story points and these blocks of work where honestly, it might make more sense to just prototype a really small piece of that, learn from it, either keep building or try something new. And so I just don’t feel like Scrum leaves enough room for experimentation. And that’s one of the really big unlocks with being AI native, is you’re able to transition more so away from a very regimented way of working to a way of working that’s a little bit more flexible. So I think in the spirit of Agile, like hypothesize, build, test, learn, adjust, constantly inspect and adapt, this is actually more conducive to that than traditional Scrum.

Douglas Ferguson: I’ve used Kanban for years as a CTO. I was a big fan of it just because it’s nimble. And one of the things I’ve noticed when organizations move from a rigid adoption of Scrum, because some folks have a loose adoption, but especially the ones that have a rigid adoption when they transfer to Kanban, they tend to step more intentionally or more purposely into the Agile principles. Because it’s funny that often the Scrum rituals are preventing people from truly adopting the principles.

Alyssa Coughlin: Right. It’s meant to be a framework, but it really in practice becomes more of a gospel, and people get so stuck in, “This is my job today, these are my story points.” And honestly, it worked in the old way of coding, but in the new way, it’s just better to be nimble. And the more you experiment, the more you learn, the more you correct, the more you’re gaining context. And if you’re doing it correctly, if you are learning with your AI tools, then they’re learning context as well. So it’s really a way to expand the knowledge graphs of both the humans and the AI. It’s a better way of working in this environment.

Douglas Ferguson: Yeah, that’s really interesting. And I’m curious how meta that gets for you. Do you have the AI observing your Kanban board and giving you feedback on how you’re thinking about the roadmap and sequencing of tickets? Is it involved in those steps currently?

Alyssa Coughlin: A little bit. We’re just starting to build some of that out. Because that’s been honestly the most challenging part of shifting to Kanban is losing the traditional Scrum metrics. So how are we measuring the productivity and the efficiency of our organizations without those? Because the thing is, not every experiment’s going to be a winner. And so we’re not necessarily looking for how many things got pushed to prod, token maximizing, it’s so easy to fudge. It doesn’t necessarily translate to business outcomes. So we have been struggling to try to figure out how do we measure success in this new way of working? And one of the things we are doing is, we have created a formula within Jira to help us gauge how well our individual teams are transitioning over to Kanban. And it’s been really interesting because we’ve got the whole gamut. We’ve got some that still really have one foot in the Scrum lane and they’re struggling with this change. They like the predictability, they like the standardization. And then on the other end of the spectrum, we have teams that are fully embracing Kanban and they’re enjoying the kind of Wild West of just pick a story out of the backlog, grab your agent and have at it. And then of course, everything in between. So I think it really comes back to the change management. It’s everywhere, because we are completely changing operating models, we’re completely changing operating rhythms. Every person who would wake up and be like, “I know exactly what my day’s going to look like,” now has to grapple with, “Well, let’s see where it takes me.” Which as a chief of staff, it’s every single day for me. When somebody asked me to describe my job, I’m like, “I don’t know. What day is it?”

Douglas Ferguson: “What day of the week is it?” So one of the things that I find liberating with Kanban was the fact that the measurement was about the cumulative flow diagram. And so we were basically estimating our average lead time. So it’s not necessarily what are we going to get done or planning this two-week chunk, but just on average, it’s taking X days to get something to production right now, and we can easily see that because the system is designed just for the flow of work. The release train is the work, right? And so we can just say, “Hey, it looks like these things are running at about this speed.” And so if we look at the backlog, we would guesstimate this is how long it would take to get through. And even though it feels less predictable because it’s less like we’re putting this chunk of thing on this thing and planning it in a super structured way, it’s almost more predictable in the sense that we have a sense of what the system is doing. Even though it’s a bit more emergent, we have a handle on its throughput. And so even if we rearrange the deck chairs a bit, we know it’s going to flow through.

Alyssa Coughlin: Yeah. And I think in addition to that, the value proposition changes. With Scrum, you don’t really review whether or not something worked until your full two-week sprint is up and you’re in your sprint review. And then that’s where you review it, you get customer feedback, you take a look at whether or not something worked. And so the emphasis within Scrum is really on completion of work versus I think a huge opportunity with Kanban is the emphasis switches to learning. It’s not, “Did I complete X amount of story points in this sprint?” It’s, “Did I learn? Did my agent learn? Was I able to share that learning?” That’s a really big part of it. And that’s another organizational challenge I’m struggling with a little bit, is when you start moving at such a fast speed, identifying and catching silos and duplications becomes a lot harder. And so that’s kind of coming back to where an AI native environment really does expose the seams in your organization. Where are things connected versus where might there be a little bit of a gap? And so that is another consideration with Kanban, is people are just kind of grabbing things and running with them and I love it. Let’s move fast, let’s learn, let’s break things. But at the same time, let’s not build the same thing in three different places.

Douglas Ferguson: Yeah, absolutely. Yeah. I wonder how much of that are you anticipating that agents might help with? For instance, scanning for duplicate work, or de-duplicate even some of the things in the backlog to even get ahead of it or even just finding issues with stuff that, because we talked about the review cycle getting so heavy and that creating such a burden on the team. So I’m just wondering about some of these kind of adjacencies even though it’s not necessarily a step in the product development lifecycle, but it’s the tooling that helps make things keeps things from falling apart, if you will.

Alyssa Coughlin: Yeah. And that’s really where context and knowledge graphs are so important. And it’s not just the technical documentation, it’s also the organizational knowledge, so much of which lives in either disparate disconnected locations or it just lives in people’s heads. And so the more we can pour that knowledge into context and knowledge graphs that AI can read, AI can turn into semantic search, the more we can help mitigate some of these circumstances. So one of the things we are doing in my organization is each group is creating their own brain as we call it. And so every organization is expected to develop some form of a knowledge graph, which can then be connected to all of the other organizations’ knowledge graphs and really create an Autodesk brain for us. And so obviously it’s down the line, we’re still working on just even gathering that knowledge and connecting the right MCPs and figuring out what that looks like. But eventually, ideally the AI can help us catch some of these things before we go too far down the road. And then we realize in some sort of review or QBR that we built the same thing twice.

Douglas Ferguson: Yeah, I’m super curious about these kind of. It’s almost like AI DevOps or developer experience kind of stuff. How are we investing in the infrastructure surrounding the experience of building the software? And because it’s not just about site reliability and how we deploy and get stuff live, but it’s also to your point, how are we identifying that there’s not duplicate tickets in the backlog or that one developer built a feature, but the AI decided to be super thorough, so it superseded three other things in the backlog because hey, it was there, it did it, it figured it out, and how do we discover that stuff and patch it? And it’s like I’m even experiencing that to some degree on my own. I built a harness and I have some agentic employees that are helping augment the team and support them on a lot of laborious, tedious kind of things or even stitch together stuff that was just really difficult to do because there was multiple systems involved. So one of the things it does is, as we’re building stuff, the agents will identify things that maybe we decided to set aside for later or that an idea that we came up with that we said, “Let’s just not focus on that now.” And so my backlog just grows and grows. And so every now and then I’m looking at, I’m chatting with the agents about what we might pull from the backlog. And so much of it’s been superseded because we just fixed it along the way while addressing some other thing. And sometimes the agent didn’t even call it out. I’m noticing in a pull request or we’re even noticing it when I go into planning cycle. So I think there’s a million ways to solve it, whether you have some sort of Damon that’s scanning the system constantly for these things or even a rule set in your planning phase that’s saying, “Hey, let’s double check that nothing’s been released to production or to the dev environment that actually addresses this issue.”

Alyssa Coughlin: Totally. And I think the most important thing about that entire point is the significance of the human in the loop. AI is just a worker bee, it’s going to keep going forward. It’s not necessarily stopping to think about is this the right thing? And so that’s really where the human expertise shines. And when you’re working with AI, telling it what to do is just as important as telling it what not to do. These are your processes, these are your checks, these are your guardrails, here’s your harness. All of that requires a human making the call. There’s human judgment and that is really what powers all AI development. Another thing that we’ve been doing is we’ve been requiring everyone to move towards spec driven development. So instead of just writing a PRD for a human, we’ve transitioned to writing specifications so that it is consumable by both humans and AI. And it’s more about bringing AI into the loop, treating AI as a partner and a member of the team and learning how to work with it versus just treating it as a tool. But yeah, completely to your point, the AI is just going to run a muck if there’s not a person in there to give it some coaching and some guidelines.

Douglas Ferguson: Absolutely. And not necessarily in a bad way, you just might not get efficient business outcomes. Because you hear all these horror stories around, “Oh, AI broke into hugging phase.” Or AI went and did this thing that was unasked for. And even in the most innocuous ways, it might be, to your point, spinning up duplicate work or doing things that are redundant. So I think it behooves us. And this is where people mourn the loss of the craft. I think the craft is just shifting. How are we being thoughtful and intentional about how we deploy these tools in ways that don’t consume tokens egregiously and our efficient use of them? And it’s not super simple. It’s not always like sometimes reaching for the cheaper model is a more expensive route to go.

Alyssa Coughlin: Yeah. And I think that’s been a really interesting industry trend, is everybody is really moving towards those open weight models because faster’s not always better right now. Just because you’re working with AI and it can build five things in the amount of time it used to take you to build one, well, if all five of them are wrong, have you still accomplished any business outcomes?

Douglas Ferguson: Right.

Alyssa Coughlin: Faster isn’t always better. And so again, that’s where that human expertise comes from. And so I think when people have this existential mindset, I think they’re really missing that component. And I think they’re missing a really exciting opportunity in that the scope boundaries of positions are really shifting and melding during this era of becoming AI native. For example, I’ve got product managers who are coding prototypes now as requirements. So they’re kind of teetering into that engineering section a little bit, and engineering is teetering a little bit more into kind of a people and operations perspective because they are that orchestrator now. And then you have XD is now kind of a little bit of everybody’s job because everybody needs to be thinking about that end user experience and that customer value. And so what it means to be an engineer, what it means to be a product manager, what it means to be a designer, I think all of that’s going to shift. And I think having a mindset of this is opportunistic versus existential, it’s going to be really critical in people succeeding in this environment.

Douglas Ferguson: Have you gotten to the point where role definitions have started to officially change or it’s still in this kind of liminal space where behaviors are shifting, but we haven’t necessarily documented it in a role or title shift or a responsibility, maybe not documented yet? I’m kind of curious where things are on the journey so far.

Alyssa Coughlin: Yeah. Well, we’re a large enterprise, so actually changing people’s job descriptions in the formal HR way has absolutely not taken place. However, the ways of working, everybody uses AI, everybody is a creator. That is very much in place. As far as what is the scope boundary for product management versus engineering, we haven’t necessarily formally defined that. Because I think we’re still figuring it out. Right now we’re still trying to learn what does our business model look like with AI? And then I think from there we can back into, okay, what roles are needed to support this model? So there’s definitely a spirit of experimentation. There’s definitely product management getting in there and kind of vibe coding something versus trying to explain it in a PRD. But we haven’t gotten to the point yet where we are formally shifting those roles. We joke that these big companies are big ships and they don’t turn quickly.

Douglas Ferguson: Well, also it kind of gets back to this idea of experimentation versus exploitation. And if you want to be innovative, you got to stay in this experimental mindset. And titles and definition and specificity is more about optimization. That’s when you’re in the exploitation phase. We’re starting to exploit the knowledge and the innovation that we learned and landed on. And so I think prematurely defining those things would be a hindrance, because it’s harder to adapt once we’ve locked in new titles or new definitions.

Alyssa Coughlin: Yeah. I think the biggest shift we’re seeing right now is actually with managers. Our expectations for them are shifting quite a bit in that all managers, nobody is just a people manager anymore. Our managers are expected to also be part of the team, to be technical experts as well, and to be able to lead the team, but to also be able to contribute. Because down the line when we eventually have these teams of people and agents, a manager’s going to have to be able to manage both. And so having them jump into the work and jump into the technology is really important. It’s also requiring a shift in their mindset and how they manage and that it’s not just about outputs anymore, it’s about outcomes. So again, coming back to token maxing is a really easy way to fake productivity. It’s not just how many things did you put out there? You’re really coaching your team and rating your team based on what business outcomes did they unlock? And to make that a reality, you do have to leave room for experimentation and you have to leave room for failure. I think freedom to fail, honestly, reducing the fear of failure. It’s something that really thrives in the startup world and it’s not as readily embraced in large companies. But I think that’s a really big transition we’re seeing as well, is it’s okay to try something, that’s kind of the whole point of this rapid fire Kanban way of working, is it’s not a failure because you still learned something even if it didn’t work. And learning is how we really want to measure success going forward.

Douglas Ferguson: Yeah, I hear that and I think of two things that I’ve seen across clients and just listening and paying attention to where folks are at these days. And one is, this managers have to get comfortable with these tools if they’re going to coach through the use of them, because if you think back to the days of coding with punch cards, if that’s all you know, then using modern abstracted languages through a keyboard, it’s going to be very difficult to manage a team doing that work if all you know is punch cards. And so I think managers need to upskill and be comfortable. And it’s not just upskilling, it’s really a behavioral paradigm shift. So learning the new ways of leaning into these tools and working in the ways that these tools can open up for you is really important for folks to experience firsthand. And then second, I think that it’s really critical that managers understand the new competencies that are critical for people to survive in this era, in this moment. For instance, we already talked about you’re shifting to the orchestrator. And so if engineers need to learn how to delegate because now they’re orchestrating, or if they need to get better at eval, the manager cluing in on those things and knowing where the got yous are and knowing what’s uncomfortable and use the word friction again, understand and diagnose the friction, they’re going to be a lot better at coaching their team through those moments too.

Alyssa Coughlin: Yeah, absolutely. I mean, I know a lot of companies are starting to creep up on Q4. And so when we think about giving feedback to your teams, how can you accurately do that if you no longer understand their work? And that aspect of being able to be an efficient manager and mentor, being hands-on is really important. And the other benefit is not only are they learning the tools, but they’re working with their team’s technology firsthand, which again allows everyone to think through that end user perspective. Call it eat your own dog food, drink your own champagne, whichever trope you prefer. But it gives them a chance to really experience what it’s like to be a member of their team and what it’s like to consume the technology they’re creating.

Douglas Ferguson: Absolutely. A few things I wanted to come back to, you mentioned the shift towards spec driven development, and you also mentioned that product managers are creating basically vibe coded prototypes. Are you seeing that the prototypes become part of the spec that is given to the LLM or what’s that kind of ritual or the shape that these specs are taking?

Alyssa Coughlin: Sometimes yes. We’re still very early in the journey and there’s definitely a change management aspect to it. I had one PM make a really great prototype that did end up going into production, but engineering originally kind of ruffled their feathers at how dare you. So coming into that, everybody has an opportunity to be more AI is an amplifier mentality. We’re still learning the best way to incorporate spec driven development into our existing development workflows. We don’t want to throw the baby out with the bath water. There’s a lot of good processes and tools already in place that we want to learn how to weave AI into. And I think what’s important as well when you’re going through these processes is slapping AI on everything is not being AI native. That doesn’t fix your problems. It’s really inspecting what does your workflow look like? What does your operating model look like? What are tasks or areas that you could leverage AI in and then free up your human bandwidth and capital to focus on more challenging topics that require that human judgment? So we’re still navigating best practices and we’re still learning, but it seems to be, it’s becoming pretty well embraced, and it’s becoming the operating norm across our organization. So yes and no. Some of it’s gone into prod, but we’re still learning and that’s kind of part of the fun of this adventure.

Douglas Ferguson: Yeah. I ask a question out of curiosity because I found that even if the prototype is throwaway, it tends to be really valuable during the spec process. I’ve always been a big fan of visual specifications. If we can show what we imagine the product looking like before we build it it’s a lot easier to build it because then we can start poking holes on edge cases or where are we going to need to put an error handling or what if someone’s name is really long? It might push out of the space. You can start asking a lot of these questions that are a lot harder to ask when you just read about something. And so I’ve found taking the visual spec or prototype or different mock-ups or even customer research plus some technical maybe architectural things and requirements and constraints, putting it all together and letting the AI have access to that, super powerful when we start putting together the plan for how we’re going to build.

Alyssa Coughlin: Yeah, definitely. And I come back to if you learned something, it wasn’t a failure. And that’s such an important mindset shift when it comes to AI and when it comes to experimentation and innovation, you don’t have to get it right for it to be valuable. You could have learned exactly what not to do or you could have learned where you had a gap that you want to fix in the next iteration. And that’s the really cool thing about specs too versus requirements, is they’re kind of living documents. They’re always evolving. You’re always adding to them as you learn more. And so they’re valuable not only because they are consumable by both humans and agents, but they learn.

Douglas Ferguson: Yeah, absolutely. I love this evolving living document concepts. It also comes back to the knowledge graph you were talking about where if teams have knowledge graphs, departments have them, orgs have them, it gives us a lot more power to use these tools in a more deeper fashion. I think a lot of organizations that are kind of handcuffed are ones where the agents don’t have access to the knowledge they need, to the tacit information that are in the heads of the humans. And if we don’t unlock that stuff, if people are hoarding that stuff because they’re afraid, it’s really going to be more limiting than anything. And it doesn’t bode well for the individuals that are doing that, because they’re only delaying the inevitable because the more that we can share and safely share and understand what’s safe to share, the more that we can understand how these things work, the better guardrails we have in place, all that stuff. So yeah, I totally agree. As we start to head toward wrapping up, you mentioned quite a few changes to the nature of the work, this adopting spec driven development, shifting to Kanban. Anything else shifting or changing as it relates to the product development life cycle and how folks are putting the software together?

Alyssa Coughlin: I think my biggest takeaway is lean into learning. So instead of going into a project or approaching a team with what’s the plan, rephrase that as what are we trying to learn or what did we deliver versus what did we unlock for our end users? It’s transitioning away from this very black and white, I deployed, I executed, it’s done, to how can I completely evolve and grow and transition as I learn? So it’s much less of a regimented stagnant process. It’s ever evolving. I mean, consider yourself to be one of the specs. You’re learning and you’re growing and you’re connecting new data and making new insights. And my favorite way of thinking of AI is, we have transitioned from a bicycle to a car. So a car can take us the same place as a bicycle can take us and it can get us there much faster. But what’s really fun about the car is it can go so much further to places that we’ve never been able to go before. And I think going in with that learning and that experimentation mindset is more important than any of the tools themselves.

Douglas Ferguson: Yeah. Maybe another way to think about that too is, once you get there, you’ll have a lot more energy to enjoy the place that you got to.

Alyssa Coughlin: Way less sweaty.

Douglas Ferguson: Yes, that’s right. Amazing. Well, as we come to a close here, I’d love to leave you with an opportunity to offer up a final thought to our audience.

Alyssa Coughlin: Yeah. Well, I think my biggest recommendation to everyone is, AI is an amplifier in every capacity and lean into that. Don’t be afraid of it. Don’t be afraid that it’s going to highlight the bad right along with the good. See all of it as an opportunity to figure out where that real friction is, where do you need to focus your energy, and then move on. Once you fix that one place, AI is going to amplify something else that needs to be fixed. And so it’s a really great partner for evolving your people, your technology, your processes. It’s going to show you everything and all you have to do is just respond.

Douglas Ferguson: Amazing. Well, it was a pleasure chatting with you. Thank you for spending some time with us and we’ll chat with you again sometime soon.

Alyssa Coughlin: Always a pleasure. Thanks for having me.

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 AI Doesn’t Remove Friction, It Just Moves Upstream appeared first on Voltage Control.

Why Your AI Deliverables Aren’t Creating Alignment

A year ago, a strategy deck took a week to build. A journey map took a workshop, a synthesis sprint, and a designer with strong opinions about Post-its. Today an AI tool can produce a passable version of either in minutes. That should be good news. It is, and it isn’t. When the artifact gets cheap, the artifact stops being the point. What was scarce, the deliverable, is now abundant. What was always scarce, the shared understanding that made the deliverable worth having, is exactly as scarce as it ever was. Jim Kalbach saw this coming from the customer experience side, not the AI side. In the third edition of Mapping Experiences, out this July, he writes that “AI-driven workflows and agents should give us more time to be more human.” He arrives at the same conclusion Voltage Control has been building toward all year: when execution time collapses toward zero, the constraint that matters is no longer producing the work. It’s aligning the people who have to act on it. Picture the scene that plays out in a hundred conference rooms this quarter. A transformation lead needs a customer journey map for a steering committee meeting. Two years ago that meant a week of interviews, a synthesis session, and a designer laying it out in Figma. Today it means a prompt and a coffee break. The map that comes back looks credible. It has swimlanes, pain points, emotional highs and lows, the works. It goes into the deck. The meeting happens. Everyone nods. Nothing changes, because nobody in that room actually built the thing together, and building it together was the part that mattered.

The gap AI just made worse

Long before AI touched a single Miro board, journey mapping had a credibility problem. Kalbach cites Gartner analyst Cassandra Nordlund’s finding that 82 percent of organizations had created a customer journey map, but only 47 percent were using it effectively (Gartner, cited in Mapping Experiences, 3rd ed.). Call it the 82/47 gap: most companies can produce the artifact. Fewer than half know what to do with it once it exists. That gap did not close because AI showed up. It widened, because AI made the easy 82 percent even easier. A team that used to need two days to draft a journey map can now get a first pass in an afternoon. The habit of stopping there, of mistaking a finished-looking document for a finished conversation, gets reinforced instead of interrupted. Polished is not the same as validated, and AI is very good at polished. This is the same trap showing up across every AI transformation program we see, not just customer experience work. Strategy decks, technical architecture diagrams, org redesign proposals, onboarding plans. All of it can now be generated fast enough that “we have a draft” stops meaning “we’ve thought this through together” and starts meaning “the model produced something plausible.” The organizations getting into trouble are not the ones using AI to draft things. They are the ones who stopped noticing the difference between a draft and a decision. Kalbach names the failure mode bluntly. Teams build “wall maps with butterflies and unicorns” that “failed because no one facilitated conversations around them, they were documentation, not dialogue.” That line was true before generative AI existed. It is more dangerous now, because the documentation has never been easier to produce and never looked more finished doing it.

It’s not the map, it’s the mapping

Kalbach’s reframe for the third edition is the sharpest sentence in the book: “it’s not the map, it’s the mapping.” The artifact was never supposed to be the deliverable. It was supposed to be the byproduct of a room full of people building shared understanding together, out loud, in front of each other. This is not a new idea inside Voltage Control. It’s the same argument underneath our own past writing on facilitation, and it’s flattering, if a little strange, to see it reflected back from a different discipline entirely. Kalbach’s book cites our 2024 piece on journey mapping directly, calling Voltage Control “a leading facilitation consultancy” and quoting our line that “this alignment of cross-functional teams around a shared understanding of the user experience is a catalyst for change.” Two people who never coordinated landed on the same conclusion from opposite starting points. That kind of convergence is worth taking seriously. Here’s what makes this interesting for the AI moment specifically. For twenty years, the map and the mapping were bundled. You could not get one without doing the other, because producing a decent map required weeks of interviews, synthesis, and cross-functional buy-in. The bundling did the alignment work almost by accident. Now AI unbundles them. You can have the map in ten minutes and skip the mapping entirely. The organizations that keep winning will be the ones that notice the unbundling and deliberately rebuild the mapping. The rest will ship more polished artifacts to teams that are no more aligned than before, and wonder why nothing changed. Rebuilding the mapping does not require throwing out the AI-generated draft and starting over by hand. It requires changing what the draft is for. Instead of walking into a steering committee meeting with a finished map and asking for sign-off, a facilitator puts the AI-generated draft on the wall at the start of a working session and asks the room to argue with it. Where is this wrong? What did the model miss because it wasn’t in the room for last quarter’s customer complaints? Where does this map contradict what sales just heard on three calls? The AI draft becomes the provocation that gets a cross-functional group talking to each other, not the artifact they file away. The mapping happens in the disagreement, not in the generation.

What IBM already knew

Enterprise Design Thinking, IBM’s internal transformation effort, ran into a version of this problem at massive scale, and Kalbach’s account of it is instructive. IBM did not try to change culture by getting people to believe something different. They changed what people did every day: playbacks, sponsor users, hills as a way to frame outcomes instead of features. The mechanism, not the mindset, is what moved. “You don’t change culture by changing what people believe,” Kalbach writes of IBM’s Enterprise Design Thinking effort. “You change culture by changing what people do.” That is a hard thing to hear if your instinct is to fix AI adoption with a better all-hands or a sharper vision statement. It is a much more useful thing to hear if you’re trying to figure out what to actually change on Monday. Applied to the mapping problem, the fix is not a policy that says “always facilitate a session before finalizing a deliverable.” Policies get skipped under deadline pressure, especially when the AI-generated draft already looks done. The fix is a changed default in how the work gets built. The AI-generated map becomes the opening move in a session, not the closing one. The habit that has to change is what a team does the moment the first draft appears on screen. That is a small design change with a large consequence. It moves the moment of AI use earlier in the process, before the deliverable is treated as settled, instead of later, as a stand-in for the settling. Teams that make this shift stop asking “did we generate a map” and start asking “did the room leave with the same understanding it walked in without.” Those are very different questions, and only one of them AI can answer for you.

The mapmaker becomes the facilitator

Kalbach makes one more claim that lands squarely in Voltage Control’s territory: the person who used to be called a researcher or a designer “needs to become a facilitator,” because “good facilitation feels invisible.” The skill that used to be a specialty is becoming a baseline expectation for anyone who produces shared artifacts for a living. That shift is not limited to UX teams. It is happening to strategists building AI transformation roadmaps, to product managers synthesizing customer feedback, to anyone whose job used to end when the deck was finished. AI collapsed the time it takes to build the deck. It did not collapse the time it takes to get a room of stakeholders to actually agree on what the deck means. That gap has to be filled by someone, and increasingly it is being filled by whoever happens to be holding the AI-generated draft when the meeting starts, whether or not they ever trained for it. “Good facilitation feels invisible” is a harder standard than it sounds. It means noticing who has gone quiet in a session and pulling them back in before the loudest voice in the room becomes the map’s point of view. It means treating disagreement about the AI-generated draft as the useful part of the meeting, not an interruption to get through before lunch. It means knowing when to let the room sit with a hard question instead of rushing to the next slide. None of that shows up in a prompt. All of it determines whether the map that comes out the other side reflects what the business actually knows, or just what one person typed into a chat window at ten the night before. This is the real implication of “it’s not the map, it’s the mapping” for an AI-native organization. The scarce skill was never cartography. It was convening. AI just made that fact impossible to hide behind a good-looking deliverable. The friction this creates is real, and it is worth naming plainly. Most knowledge workers were never trained to run a session. They were trained to produce an output and hand it off. AI just handed them a faster way to produce the output, without handing them the skill of getting a room to actually use it. That mismatch, a workforce equipped to generate and unequipped to convene, is exactly the kind of gap that determines whether an AI transformation program sticks or stalls. It shows up as meetings that end in polite agreement and no behavior change, as roadmaps that get rewritten every quarter because nobody actually committed to the last one, as decks that get more beautiful while decisions get slower.

The scarce skill isn’t creation, it’s convening

None of this argues against using AI to draft the map, the deck, or the plan. Draft it. Draft it fast. The mistake is treating the draft as an ending instead of an opening. A journey map that never gets argued over in a room is not a finished artifact, it’s an unfinished conversation with a nice layout. The organizations that internalize this will start every AI-generated deliverable the same way: as raw material for a facilitated session, not as a substitute for one. They will staff for facilitation the same way they staff for AI tooling, because the two are now inseparable parts of the same workflow. They will train the strategist who used to just build the deck to also run the room where the deck gets argued over, because that skill is no longer optional once the deck itself is nearly free. The organizations that don’t will keep producing beautiful, unused artifacts, and keep being surprised that alignment didn’t follow. That is the actual choice AI transformation programs are making right now, whether they realize it or not. Every budget line that goes toward another generation tool and none toward the capability to convene people around what that tool produces is a bet that the 82/47 gap will somehow close itself. It won’t. It has had years of journey-mapping practice and now generative AI to close on its own, and instead it widened. The 82/47 gap was always a facilitation gap wearing a documentation costume. AI didn’t create that problem. It just removed every excuse for not seeing it clearly. The map was never the deliverable. The mapping still is, and now it’s the only part of the work an AI can’t do for you.

The post It’s Not the Map, It’s the Mapping appeared first on Voltage Control.

The Scoreboard Nobody Updated

Walk into any leadership offsite this year and you will hear the same number celebrated: how fast the team is moving now that AI has entered the workflow. Sprint velocity is up. Time-to-first-draft is down. The deck that used to take a week now takes an afternoon. None of that is false. It is also no longer useful. Execution speed stopped being a scoreboard the moment every competitor got the same acceleration. When everyone’s code writes itself, everyone’s report generates instantly, and everyone’s analysis runs in minutes, speed stops being a differentiator and becomes a floor. You cannot out-execute a market where execution is free. The organizations still tracking execution velocity as their headline metric are measuring the one thing that no longer separates winners from everyone else. Worse, they are measuring it instead of the thing that actually does.

What Speed Used to Buy You

For most of the last century, execution speed was a reasonable proxy for organizational health. A team that shipped fast was usually a team that had already done the hard work: they knew what to build, they agreed on why, and they had cleared the internal friction that slows weaker teams down. Speed was the visible tip of a mostly invisible alignment. That correlation is what broke. AI decoupled speed from alignment. A team can now produce fast output with zero internal agreement about direction. Six people can each generate a confident, polished strategy document in an afternoon, and the fact that all six documents exist quickly tells you nothing about whether the team agrees on which one is right. If anything, it hides the disagreement, because everything on the page looks finished. This is the trap. Leaders keep watching the speed dial because it used to mean something, and it is still the easiest number on the dashboard. But a rising speed metric in an AI-accelerated org is no longer evidence of health. It is evidence that people are producing. It says nothing about whether they are producing the right thing, together, on purpose. Miro CEO Andrey Khusid named the mechanism from the vendor side at Miro’s Canvas 26 keynote: “Six people, six AI copilots, six confident, polished, completely divergent strategies.” Nobody is slow. Nobody looks unaligned. The speed dial reads great right up until the moment those six plans collide in a room and someone realizes the team was never actually agreed on anything. It was just producing quickly in six different directions at once.

Alignment Velocity: The Metric That Actually Differentiates

Here is the replacement metric, and it deserves a name because it deserves to be tracked with the same discipline leaders once reserved for sprint velocity: alignment velocity. Not how fast your team executes. How fast your team reaches genuine consensus and commits to a direction. Genuine consensus is the operative phrase. Not a meeting that ended in a vote. Not a document that got a thumbs-up in Slack. Genuine consensus is the point where the people who disagreed loudest can now articulate the decision in their own words, without translation, and act on it without a second private conversation about what was really decided. Alignment velocity asks a different question than execution velocity does. Execution velocity asks: how fast can we produce? Alignment velocity asks: how fast can we agree on what is worth producing, and how fast does that agreement actually stick? The organizations that win the next decade will not be the ones who moved fastest. They will be the ones who redirected their measurement, their meetings, and their leadership attention from the first question to the second. This is not a soft metric dressed up to sound rigorous. It is the metric that predicts everything execution velocity used to promise: fewer reversals, less rework, faster real-world delivery, because the team is not quietly building on a foundation half of them never actually bought into.

Polished Is Not Validated

The clearest recent articulation of why this matters came from an unlikely source: a tooling vendor’s own product keynote. At Miro’s Canvas 26 event this spring, Miro’s Kendra Wilkins, Product Director for AI Prototyping, named the exact failure mode organizations are walking into: “AI made it incredibly easy for something to look finished… But polished does not mean validated.” Her sharper line cuts even closer to the bone: “You’re building a hundred wrong things quickly, and you don’t even know it.” That is the mechanism. Before AI, the slowness of production was an accidental safeguard. It took long enough to build something that misalignment usually surfaced before the thing shipped. Someone would ask a clarifying question in week two. A stakeholder would push back before the deck was finished. The delay was annoying, but it was also a checkpoint, and checkpoints are where validation happens. Remove the delay and you remove the checkpoint. You do not just save time. You lose the moment where someone would have said, wait, are we actually agreed on this. Wilkins named the consequence directly: “That buffer is completely gone. Because while you’re planning, your competitor is shipping.” This is exactly why alignment velocity has to be measured on purpose now. It used to happen for free, as a side effect of how slow everything was. Nothing forces it to happen anymore. If you are not tracking it, you are almost certainly not doing it, no matter how fast your team looks on paper.

Where This Shows Up First

You will not see this in the projects everyone agrees are important. You will see it in the quiet ones: the mid-tier product line, the internal tooling decision, the vendor pick that nobody thought was worth a full alignment process because it “obviously” had one right answer. A product team splits a roadmap question across three sub-teams. Each sub-team uses AI to model options fast, and each converges on a confident recommendation within a day. On paper, that looks like extraordinary velocity: what used to take a quarter of workshops now takes seventy-two hours. Leadership rolls the three recommendations up expecting to rubber-stamp a synthesis. Instead they get three plans that quietly assume three different answers to the same unresolved question about what the product is actually for. Nobody argued about it, because nobody realized it was still unresolved. AI gave each sub-team the confidence to skip the conversation that used to force the disagreement into the open. The rework that follows does not show up as a rework metric. It shows up as a quarter of “replanning,” which is what a low alignment velocity looks like when nobody is measuring it.

Why Leaders Keep Scoring the Wrong Thing

If alignment velocity is the metric that matters, why does almost no leadership team track it? Because speed is easy to count and alignment is hard to see. Execution speed shows up in a dashboard automatically. Tickets closed, drafts produced, cycle time, all generated as a byproduct of the tools people already use. Alignment velocity requires someone to actually watch how a decision gets made: who spoke, who stayed quiet, whether the quiet ones agreed or just gave up arguing, whether the decision that got announced on Friday is the same decision people are executing against three weeks later. There is also a career incentive at work. A leader who reports rising execution speed looks decisive and modern. A leader who reports “we slowed down to make sure everyone actually agreed” sounds, to an impatient board, like an excuse. The visible metric rewards the behavior that looks like progress. The metric that predicts real progress requires the discipline to look past the appearance of speed and ask what is actually underneath it. This is not a call to slow down for its own sake. Slow is not the goal any more than fast is the enemy. The goal is a scoreboard that measures the thing that determines whether your organization’s speed is pointed anywhere useful.

How to Actually Measure Alignment Velocity

Alignment velocity is trackable, and it does not require new software. It requires leaders to ask three questions with the same rigor they once applied to sprint retros. Start with commitment lag: the gap between when a decision is announced and when the people affected by it can restate it accurately, in their own words, without checking with each other first. A short gap means real alignment. A long gap, even with a fast-looking decision date, means the announcement outran the agreement. Track the reversal rate next, meaning how often a “final” decision gets quietly relitigated, walked back, or silently ignored within a month of being made. A high reversal rate is not a sign that your team moves fast and adapts. It is a sign that the original alignment was never real, and the org is now paying twice for one decision. Finally, watch when dissent surfaces. Teams with high alignment velocity surface disagreement before a decision is finalized, in the room, out loud, where it can actually change the outcome. Teams with low alignment velocity surface the same disagreement after the fact, in side conversations, in the hallway, in the version of the meeting that happens once the real meeting has ended. The volume of dissent is not the signal. The timing is. None of these require a dashboard. They require a leader willing to sit in the room and notice what execution velocity metrics were never built to catch. This cannot live only at the top. The VP who owns the roadmap sees speed. The people closest to a decision see whether it stuck. Alignment velocity has to be tracked by whoever is closest to where the decision actually gets used, then rolled up, the same way you would never trust a single director to self-report their own team’s execution speed without a shared definition underneath it.

What’s at Stake

The organizations that keep optimizing for execution speed will get exactly what they are measuring: more output, produced faster, with no better odds that it was the right output. They will ship more polished work than ever, and quietly rebuild more of it than ever, because nothing in their scoreboard was ever designed to catch the difference between agreement and appearance. The organizations that shift to alignment velocity will look slower on the old dashboard and faster on the one that actually matters. Fewer reversals. Less rework disguised as iteration. Decisions that survive contact with the people who have to execute them, because those people were actually part of making them. The difference will not show up in this quarter’s output report. It will show up in how many of this year’s “finished” projects are still standing next year, and how many of them quietly had to be rebuilt because nobody checked whether the room actually agreed before it started moving fast.

Where to Start This Week

Do not wait for a new dashboard to start measuring this. Pull the last three decisions your leadership team called “final” this quarter. For each one, ask the three people closest to executing it to restate the decision in their own words, without conferring first. Where the restatements diverge, you have just found your real commitment lag, weeks or months after the fact, which is exactly the delay you are trying to shrink going forward. Then pick your next contentious decision and change one thing: build in a deliberate pause before you call it final, long enough for someone to voice the disagreement they are quietly sitting on. That pause is not the opposite of speed. It is the only way to find out whether the speed you already have is pointed anywhere real. Stop reporting how fast your team executes. Start reporting how fast your team actually agrees, and how well that agreement holds. That is the number that was always supposed to predict the other one.

The post Stop Optimizing for Speed appeared first on Voltage Control.