Why AI Output Metrics Mislead and What to Track Instead

Sixteen experienced software developers sat down to work. They had access to the best AI coding tools available. They had been told, reasonably, to expect a 20 to 25 percent productivity boost. When the study ended, they believed, on average, that AI had made them 20 percent faster. They were 19 percent slower. That is from METR’s July 2025 randomized controlled trial, the most rigorous study of AI’s effect on experienced developer productivity published to date. The 39-point gap between what developers believed about their performance and what actually happened is not a rounding error. It is a measurement failure at scale. And it should be the first thing any executive reads before reviewing their organization’s AI productivity numbers.

The Metrics We Default To

Most organizations are measuring the wrong things. Not because their teams are careless, but because the wrong things are easy to count. Tokens consumed. Lines of code generated. Pull requests merged. Tool adoption rates. Story points completed. Time-to-first-response in customer service queues. Meeting transcripts enabled. These are the metrics that appear on AI dashboards across the enterprise right now. Every one of them produces a number. Every one of them trends over time. Every one of them can be presented in a board slide. None of them tell you whether your AI transformation is creating value. This is output accounting. It measures what happened: how much AI was used, how many tasks were touched, and how fast certain activities were completed. It does not measure whether the right things happened, whether the quality of work improved, or whether the organization can now do anything it could not do before. The appeal is understandable. Output metrics are fast, cheap, and unambiguous. In a transformation that feels uncertain and fast-moving, the comfort of a trending dashboard is real. That comfort is the problem.

When Output Metrics Lie

The clearest proof is Klarna. In 2024, Klarna announced that AI had replaced approximately 700 customer service agents. By Q3 2025, the company claimed its AI agent was doing the work of 853 full-time employees and saving $60 million annually. The volume metrics looked excellent: faster resolution times, higher tickets-per-hour throughput, and lower cost-per-interaction. Then, quietly, in early 2026, Klarna began rehiring humans. What the output metrics had not captured was quality deterioration on complex interactions. Customer satisfaction scores on difficult cases had declined. The conversations that mattered most, the ones where customers were frustrated and needed real understanding, were getting worse. The metrics that declared success had optimized for speed in the cases where speed was least important. Klarna’s reversal is not a story about AI failing. It is a story about measurement failing. The organization tracked what was easy to track. The things that were hard to track, judgment quality on complex cases, customer trust in sensitive interactions, brand perception over time, deteriorated while the dashboard numbers climbed. This is not unique to Klarna. It is the predictable outcome of any measurement system that optimizes for outputs rather than outcomes.

The Counter-Signal Nobody Expected

Triumph Financial runs one of the largest payment networks in trucking, moving roughly $18 billion a year to carriers who often wait up to 90 days to get paid by brokers and shippers. In 2023, working with KUNGFU.AI, the company set out to speed up invoice funding with AI. It would have been easy to make speed the headline metric. Triumph didn’t.

Earlier attempts at automation, using rigid, hard-coded rules, had already failed once, rejecting too many good invoices to be useful. So this time, before anyone touted a faster approval time, the team agreed on three specific numbers to watch: disputed invoices, short pays, and write-offs. Not throughput. Not approval speed. The things that would reveal whether the model’s decisions were actually as good as a human’s, not just faster than one. Those numbers were put on a shared dashboard everyone could see, and the model wasn’t scaled up until a staged rollout, moving from historical data testing to a dark launch to a 100-day pilot, showed it held up.

Only after that did the speed numbers get to matter. And they mattered a great deal: invoice approval time fell from an average of 178 minutes to about 10 seconds, with more than $4 billion in invoices now running through the model and over half auto-approved. But the figures Triumph’s CTO Jason Heilig points to first aren’t the speed ones. Short pay is down 57 percent. Chargebacks are down 65 percent. Disputes are down 25 percent. The company didn’t get fast at the expense of getting careless. It got fast because it insisted on being careful first.

That is the inverse of Klarna. Klarna’s dashboard celebrated speed and volume while the quality of the hardest conversations quietly eroded underneath it. Triumph made quality the metric that had to clear the bar before speed was allowed to become the story at all.

What the Dashboard Cannot See

Output metrics fail for a structural reason. They measure what was done. What leaders actually need to know is whether things are getting better. That distinction sounds simple. It produces completely different questions. Counting tokens consumed is easy. Asking whether the judgment underlying those tokens improved is hard. Counting PRs is easy. Asking whether the engineering organization is now capable of work it could not previously do is hard. Counting tool adoption is easy. Asking whether the team’s AI outputs are being accepted, revised, or rejected, and learning from the pattern, is hard. The organizations that stay in output-accounting mode past the early adoption phase are not being prudent. They are deferring accountability. McKinsey’s November 2025 “State of AI” report found that 88 percent of organizations now use AI, but only 6 percent qualify as high performers with measurable EBIT impact. Only 39 percent report any measurable business effect at all. The gap between having AI and benefiting from AI is the gap between output accounting and outcome accounting. High performers, in McKinsey’s data, are 2.8 times more likely to have fundamentally redesigned workflows. That is not a technology finding. It is a measurement finding: the organizations that ask deeper questions build different systems.

Three Questions That Change the Frame

Output metrics answer the question “did we use AI?” The questions leaders actually need are harder and closer to the truth. The first: how many agents do you have running? This measures the scale of actual deployment, not licenses activated or employees who opened a tool. Agents running against real problems are a more honest indicator of organizational AI maturity than any adoption metric. The second: how long can those agents run without human intervention? This is a proxy for quality. An agent that requires correction every five minutes signals weak prompting, poor context engineering, or an immature tool setup. An agent that completes substantive work over hours signals a team that has genuinely learned to work with AI. Autonomy duration is a quality metric dressed as a timing metric. Anthropic’s internal research found that human interventions per Claude Code session fell from 5.4 to 3.3 between August and December 2025\. That four-month trajectory is more revealing than any adoption curve. The third: what novel work are you unlocking that was not feasible before? This is the one that matters most to leaders, investors, and boards. Not “we are shipping the same roadmap 20 percent faster” but “we stood up a customer-segmentation pipeline that had been on the backlog for two years because we could never justify the engineering cost.” Novel work is opportunity creation. It is the metric that corresponds to what organizations are actually hoping for when they invest in AI. None of these three questions are easy to put on a dashboard. That is the feature, not the bug. A metric that is easy to optimize is a metric that will be gamed. Consider what happened in the rooms where CEOs set personal token-consumption targets for their teams: staff ran purposeless prompts to hit the number. Output metrics corrupt the behavior they are meant to measure. Outcome metrics resist that corruption because they are attached to something real.

The Cost the Dashboard Hides

There is a second blind spot, and it sits on the other side of the ledger. The three questions above measure whether the work is getting better. They do not measure what it now costs to deliver it, and that is the other half of any honest ROI. For two decades, software ran on an economic assumption so reliable that most leaders stopped noticing it. The marginal cost of serving one more user was effectively zero. Build the product once, and the ten-thousandth user cost almost nothing more than the thousandth. Engagement was therefore an unalloyed good. More usage meant more value, more retention, more expansion, and almost no additional cost to carry it. AI breaks that assumption. Every interaction now consumes tokens, and tokens cost money in direct proportion to use. Jeff Gothelf, who co-authored Lean UX, put the consequence plainly: your most engaged users can quietly become your least profitable ones. The power user running fifty AI queries a day is the user you celebrated under the old economics and the user who erodes your margin under the new one. The dashboard that shows engagement climbing may also be showing cost climbing faster, and a usage metric will never tell you which. This is why measurement for AI cannot stop at value. It has to track cost-to-serve at the unit level: cost per successful task, gross margin per active user, model cost as a percentage of revenue. These are not finance-team afterthoughts to reconcile at quarter end. They are leading indicators of whether an AI product or workflow stays economically sustainable as it scales. An organization can be creating genuine value, clearing every outcome bar in this piece, and still be quietly building something that gets less profitable with every new power user it celebrates. The discipline is the same one this entire piece argues for. Measure the thing that is hard to see, not the thing that is easy to count. On the value side, that means outcomes over outputs. On the cost side, it means cost per successful result over raw usage volume. A serious AI scorecard holds both, because a transformation that creates value while quietly destroying margin is not a success the dashboard is equipped to catch.

Innovation Accounting: The Closest Precedent

The intellectual framework that comes closest to what is needed already exists. Eric Ries built it for a different context: startups trying to measure progress when traditional indicators, revenue, customers, and profitability, are all effectively zero. His answer was innovation accounting. Instead of revenue, measure validated learning. Instead of units shipped, measure hypothesis tests completed. Build, measure, learn is the loop. The goal is not to produce a big number. The goal is to reduce uncertainty faster than the competition. Nobody has operationalized innovation, accounting for enterprise AI transformation in a published, replicable form. That gap is confirmed across every major measurement research program. DORA has extended its software-delivery metrics toward AI. Anthropic has published a primitives framework that measures how AI is being used at the task level. Accenture and Wharton have built a skills-shift index tracking 150 million professional profiles. None of them answer whether the organization is learning faster, producing better work, or doing things it could not do before. The practitioner community is ahead of the published literature on this. Six consecutive executive dinners across Dallas, Houston, Boston, Boulder, Portland, and Raleigh surfaced innovation accounting independently, without anyone being prompted. In every room, leaders described the same measurement problem and reached for the same frame. In no room did anyone have an operationalized version to point at. That convergence is not a coincidence. It means the field is ready for a framework, and the gap is structural, not a matter of individual companies being slow.

The Objection Worth Taking Seriously

The obvious counter-argument is that outcomes are unmeasurable. That output metrics are at least something, while outcome metrics are a vague ambition. This is a legitimate critique of poorly defined outcome goals. It is not a reason to abandon outcome measurement. Anthropic published the AI Fluency Index in early 2026, analyzing nearly 10,000 human-AI conversations to measure the quality of collaboration, not just the quantity. They identified 24 specific behaviors associated with effective AI use across four dimensions. Quality measurement is not an aspiration. It is an active research program producing real findings. The staged-measurement argument has something to it. Token consumption is a reasonable early proxy when the goal is normalizing AI use across a skeptical organization. Cultural adoption does need to come first. But most large organizations are past that phase now. Adoption is widespread. The question is no longer “will people use this?” It is “are we getting better because of it?” The Goodhart’s Law argument cuts both ways. Yes, any metric will eventually be gamed. That is a reason to rotate metrics deliberately, to pair quantitative measures with qualitative judgment, and to build measurement systems that are harder to optimize against than a single dashboard number. It is not a reason to accept measurements that are actively misleading. Outcomes can be defined. What novel work did your organization do this quarter that was not feasible last quarter? What percentage of AI outputs required human revision, rejection, or acceptance? How has autonomy duration changed over six months? These are measurable. They require judgment to interpret, as all meaningful metrics do. That is not a bug. That is what accountability looks like.

Where to Start

Auditing your current AI measurement against a single question produces clarity quickly: does each metric measure what happened or whether things got better? Tokens consumed, meeting transcripts enabled, PR counts, story points completed: these measure what happened. Replace them with counter-metrics that track quality alongside volume. If PR count goes up, track average PR complexity alongside it. If resolution time goes down, track customer satisfaction on complex interactions alongside it. At one roughly 1,000-person software company, the PR count told one story and average PR size told a different one. Both were necessary to understand what was actually happening. Then introduce the three questions as a leadership review practice. Not a dashboard, but a quarterly conversation: how many agents are running, how long can they run unattended, and what novel work did AI unlock in the last 90 days that was not on the roadmap before? The answers will be uneven and sometimes uncomfortable. That is the point. The organizations that build the discipline now, before their output metrics lock them into the wrong optimization, are the ones that will join the six percent achieving real EBIT impact. Not because outcome accounting is easy, but because it is honest.

The Measurement That Matters

Stanford HAI named this moment the shift from the era of AI evangelism to the era of AI evaluation. The question is not whether AI is transforming your industry. That question is answered. The question is whether your organization is learning from that transformation or simply counting it. Output accounting produces numbers that trend upward while the business-critical questions go unanswered. Klarna had great numbers until it did not. The engineering executive had a disappointing PR count until someone looked at PR size. The METR developers believed they were 20 percent faster until the data showed they were 19 percent slower. The dashboard that looks best right now may be hiding your Klarna moment. Outcome accounting is not optional for leaders who want to know what is actually happening. It is the discipline that makes the difference visible before it becomes irreversible. Want to explore what an outcome-accounting framework looks like for your organization? We work with leadership teams on exactly this question.

The post Measuring What Matters appeared first on Voltage Control.

In this episode of the Facilitation Lab podcast, host Douglas Ferguson interviews Taran Lent, Chief Technology Officer at Illumia, about how his organization moved from individual AI experimentation to enterprise-wide capability. Lent describes building an “enablement task force” that deliberately avoided becoming a governing bottleneck, instead creating conditions for employees to play, learn, and share what worked, before this year’s push to elevate personal AI habits into shared team and company-wide skills, standards, and vetted tools. He talks about using AI as a contrarian thought partner and even having it grade his own interviewing and meeting behavior, while cautioning that transcripts alone miss tone and body language. The conversation also covers the governance side of scaling AI, including a stakeholder review process for new tools and skills, the four-to-six-week approval timeline for new vendors, and guardrails to prevent incidents like an unauthenticated internal dashboard. Lent connects this to Illumia’s recent merger of Transact and CBORD, crediting a shared “humble, hungry, smart” culture for making the integration smoother, and closes by arguing that judgment, creativity, and human discernment remain the differentiators as AI adoption accelerates.

Show Highlights

[00:00:00] Introducing Taran Lent And New Friction
[00:02:30] AI Loses Its Social Stigma
[00:06:00] Using AI As A Contrarian Thought Partner
[00:09:30] Having AI Grade His Own Interviews
[00:14:00] Building An AI Enablement Task Force
[00:20:30] Zach Kass On AI Working Invisibly
[00:23:30] Traffic, Tragedy Of The Commons, And Self-Driving Cars
[00:29:00] Vetting And Governing New AI Tools
[00:34:30] AI-Assisted Code Reaches 90 Percent

Links | Resources

Taran Lent — LinkedIn
Illumia — LinkedIn
Voltage Control

About the Guest

Taran Lent is Chief Technology Officer at Illumia, the company formed from the 2024 merger of Transact and CBORD. He describes himself as an engineer by training who has spent his career building and scaling technology companies, and at Illumia he leads engineering along with security and compliance responsibilities. Lent talks about designing tailored interviews and using AI as a feedback partner on his own leadership behavior, and about steering his organization’s shift from individual AI use to shared, enterprise-wide AI skills and tooling. He frames the recent merger as a test of culture, emphasizing that Illumia looks for people who are “humble, hungry, and smart.”

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. I’d like to introduce you to my conversation partner today, Taran Lent, Chief Technology Officer at Illumia. Taran is an accomplished entrepreneurial leader with a proven track record in building and scaling technology companies throughout his career. Welcome to the show, Taran.

Taran Lent: Hey, it’s great to see you, Douglas. Thanks so much for the opportunity. Looking forward to the conversation and what we might learn from each other today.

Douglas Ferguson: Agreed. I always enjoy our chats. Excited about diving into this one. So I guess to start off, we’ve spoken about this topic quite a bit. You’ve attended one of our executive dinners and have attended the mastermind that we do monthly as well. And I’m curious, since you know the topic well, what news emerging for you since we last spoke? I know that you’re experimenting with a lot and trying new things. What have you encountered most recently in this world of AI and working alongside AI and the frictions that come along with it?

Taran Lent: It’s a great question. Well, it’s obviously a rapidly evolving space. The visual I have in my head is a snowball rolling down a hill and with each turn, it’s picking up more speed and more surface area and it’s getting bigger and it’s becoming kind of a juggernaut. But I just think it’s such an exciting time to be involved in technology. Anytime you have generational emerging technologies that kind of change paradigms the way you think, it’s just fun to have that in your career. Before I get into the details of it, I think it’s worth noting that humans have a terrible track record historically anytime new technologies come along predicting what it means and how it’s all going to play out. I don’t think with electricity, with computers, with the internet, if you kind of go back, a lot of people were wrong about how things were going to evolve and turn out. And I think you have people that underestimate emerging technologies. I give people that overestimate it. And I think it’s okay by the way. It’s okay not to know the answers, but what we’re trying to do and what I’m trying to do personally is just stay on the edge of the learning curve, play and experiment a lot, learn from other people, share stories. And if you do that with technology, whether it’s AI or something else, your chances of ending up in a good place are better than not is my opinion of that. To me, I think the biggest thing, the biggest thing I’ve noticed is maybe just social. There’s no stigma of any kind when people use AI. I just noticed that when people use AI, it’s perfectly okay to say, “I’m using AI.” I think there was a period where people would use AI and present it as non-AI work. And now people are using AI out in the open and the public and in a very genuous way. It’s like, “Hey, let’s bring AI into this and help it brainstorm, help us do critical thinking, help us automate.” And so I think everybody that I’m interacting with, you included, it’s becoming more of an AI first. “Hey, let’s make sure we’re leveraging AI to help us do whatever we’re doing at a higher level.” Right.

Douglas Ferguson: Yeah. I was just at an educational conference recently and one of the tables stood up as part of the debrief and said, “We don’t care if it’s AI generated, we care if it’s true.” I though that was so profound in its simplicity because it’s like, let’s not put a stigma on the AI itself, but let’s hold ourselves accountable to what matters.

Taran Lent: One of the things that I’ve had an experience with, I would say early in my career, my superpower was my ability to write and structure information or be persuasive or make a pitch. And when AI first came out, I felt like my superpower had been neutralized because now I was really good at writing a five or 10-pager or a strategic document, and then suddenly AI, everybody can now generate a lot of content. And then I was reflecting on how I use AI to do my own writing. I’m not sure it’s actually any faster at this point, but I think it’s better ’cause I’m still providing a lot of content and a lot of context. I don’t worry so much about structuring and organizing it, but I’m using AI as a contrarian partner. “Hey, what are all the things I’m not thinking about? Rate this on a scale of one to 10. How could I make this a 10? What could I be wrong about? Is this concise enough?” And by the time I provide all my context and I do all my think about it from other angles and I iterate on it and then I review it and then make sure it’s in my own voice and my own style, it might be about the same amount of time I was doing before, but the quality of when I put it out there I would argue is better. I spend more time not on the creation of the content, but on making sure the quality of the message and the information’s really good. And I think the same is true for my developers, the people that are coding. So I think there’s an analogy between writing human prose and then writing code. What AI I think helps you do a lot is really iterate faster and have more cycles so that the end result in theory … And look, there’s obviously lots of cases where it does absolutely accelerate, but the only outcome is not speed. There are other outcomes in terms of quality, completeness. I think to your point, being right and being correct or truthful are important outcomes too.

Douglas Ferguson: Yeah, I can resonate with that higher quality. And it’s interesting too, it’s like, what you’re describing is maybe even runs deeper than quality because I would argue that the stuff you were creating before was probably high quality, but you might’ve overlooked something or you didn’t have time to uncover one little thing that might bite you down the road or you share it and someone asks a question about, “Hey, what about this corner case?” And you’re like, “Oh, I should have caught that.” And I’m finding I am able to include more things like that. I’m able to iterate more and maybe it’s more expansive and more thoughtful and inclusive of other ideas and perspectives.

Taran Lent: I think the inclusivity is really good. I mean, overwhelmingly for me, I love using AI as a critical though partner and as a devil’s advocate. And I’ll give you a couple of examples in my own situation and others, but there’s oftentimes friction between just since we run a product and technology company between product management and engineering, right. Because product management’s trying to say, “This is what we want to build and this is a saving,” and then providing inputs into engineering. And oftentimes I hear things like, “Well, you’re not operating the right level of detail,” or, “This story’s not clear,” or … And I’m like, “What a gift it is to a product manager if you’re providing an input to engineering before you actually share it to say, “Here are the personas of the different people on my other side.” Review what I’m about to provide from their perspective and say, “Hey, is this complete? Is there anything that would make it better? Is there something more I could provide? Is there additional research that I should do to make this great?” And so it’s such a safe place to critique your own thinking and your own work. And like you said, the inclusivity to think about … I absolutely do that with my stuff. I have a boss, that’s the CEO. I have a board of directors. I have leaders in other departments. And by the way, and I have different relationships with these people. Some are really harmonious and peer-to-peer. Some might have more dynamics to them. And so I love that, screen my communications through that and say, “Hey, thinking about these personas and thinking about the nature of our relationships, is this message going to be successful? Is it going to be effective? And what could I do to make it better?” But that’s just scratching the surface of what AI can do, but it’s an interesting launching point of we all work with it in different ways and I’m definitely not a person that takes the first output and said, “Hey, let’s take that to the bank.” To me, it’s all about iteration, A/B testing, alternative thinking. And so I think that’s been very valuable for me. And when I talk to other people about how I use it, I kind of encourage them, “Hey, are you …” I’ll give you one more example, Doug, before you … When I do interviews, I do a lot of interviewing. A big part of my job is recruiting talent to the company. I find AI is a great tool to help me design a really tailored interview for that person so I’ve already taken into account the resume, the job description. And so I use it to help design really tailored interviews. But what I find when I am done, I don’t have it grade just the candidate, I have a grade me. “Hey, how did I do as an interviewer? Did I conduct a good interview? Did I give them lots of space to answer the questions without prompting? Did I delve two and three levels deeper? Did I hit on all the questions that were important?” And I’ll be honest, the first few times it was some tough love. It’s like, “Hey, you’re not doing very good interviews.” I was like, “Okay, well, I need to …” And that was great. I love that I got that feedback and it’s kind of a feedback loop that’s making me think about, “Okay, what do I need to do different?” Right.

Douglas Ferguson: Yeah, I was going to ask about that actually. I love that you brought a story about reflection and feedback because when you were talking about the screening of messaging for peers and other individuals inside the organization that you had to collaborate with and work alongside, and as you said, some are more harmonious than others. So I was curious, have you used it at all for reflection or after the fact feedback maybe from email exchanges or meeting transcripts, like, how the meeting transpired, how you could have shown up differently?

Taran Lent: 100%. I have a bunch of skills and prompts that basically, for any meeting where I think I didn’t do a great job or I felt like maybe the dynamics weren’t right, I’ll go back and say, “Hey, evaluate.” Especially in my role, one of the things I worry about is I, because I have a high level role and the power of the post, I really work hard to make sure I speak last and give lots of space for people to do it. And so I kind of do it as a way of accountability, “Hey, did I …” I don’t want to be known as a person that necessarily dominated the meeting or the conversation or interjected my position too early because I could create bias for how other people think or what they say. So I really like that idea of everybody can … And it’s not necessarily meetings that I’m in. Sometimes there are meetings I hear about that I wasn’t at where there’s some conflict or some issue or some decision that people have different takes on what happened. And it’s a really fast, efficient way for me to get a sense of, “Hey, how did that meeting go? And was there anything from a cultural perspective that was not great that I need to know about and address and coach?” Right.

Douglas Ferguson: Yeah, much more efficient than trying to sit everyone down individually and try to figure out what was going on if you can go back to the source.

Taran Lent: You do need to be careful though, because that’s transcripts and body language still matters, tone still matters. There’s lots of other things that play into that. You have to be careful not to take just texts on a page and a transcript and an AI. As I get further and further, the question people are asking is what does this all mean for humans and what do humans bring to the table that’s special? And I still come back to judgment, creativity, resourcefulness. Those are always going to be valuable I think in our society and in business. And I think you have to remember, AI is probabilistic. It’s trained on what’s already happened and what’s already known. And so there’s still a lot of room for humans to use their creativity and the power of our minds to forge things that have never happened before. And AI can help us do that, but I think humans are still just innately so good at that part of creativity and invention.

Douglas Ferguson: Yeah. I’m curious, how have you been encouraging your organization to lean in to the human parts and to embrace AI and use it in ways that are going to benefit the business?

Taran Lent: So first of all, I’ll provide some context. If I wound the clock back, I’ll say two years, two and a half years ago, I would say that we were not where we needed to be. I would say we were kind of behind the curve, and for reasons that were good. As you know, we were going through a transaction and selling the business and Roper acquired a company and then they merged us with another company. So it consumed a lot of capacity just to work through those mechanics. And I think as a side effect of that, we weren’t leaning into AI as much. We woke up one day and said, “Okay, hey, we’re not where we want to be.” So I looked at last year. Last year was the year where we really enabled. So the first thing we did is we created what we call the enablement task force and the naming of that was intentional. We didn’t want it to be a governing board. We didn’t want it to be a central bottleneck. We said, “Hey, look, we want to create greenhouse conditions where people can start to play, learn, experiment, apply, and then share with each other what’s working and what’s not.” And so the task force was pretty big. We’re a thousand person company. The task force was 40, 50 people. And we started really the whole focus of the conversation is, “What can we do to grease the skids to make it easier for people to get started on their personal journey?” And that included things like creating, you know, getting an updated AI policy, making it very clear, “Hey, here are all the tools that are already approved that you can use.” We looked at our process for how we review new software requests and we could get new tools approved more quickly while still keeping true our security and compliance obligations. We started creating resources and opportunities for people to share. So one of the things we did is at our company all hands, we always showcase at least one or two AI showcases that we think that’d be interesting to the whole company. But I think that word enablement was really the key piece. We said, “Hey, let’s help people get started.” There’s money and licenses for people to have one or more AI tools. So we did enterprise deals with Anthropic and with ChatGPT. We’re a Microsoft shop, so we enabled the Copilot M365 for employees, which is amazing ’cause that has access to the Microsoft Graph, OneNote and Teams and Outlook and so forth. So last year I would say was the year of, “Hey, get everybody in the game.” And by the way, I lead engineering at the company, so the developers are a whole nother story. We forget that developers created this technology. They’ve been playing with it for many years. And so the developers are in a different place in this maturity curve ’cause they’ve been … Developers don’t like to do work that they find tedious. And so they were extraordinarily resourceful at automating things that we don’t want to do. And I’ll come back to that point in a second. But this year is more about, “Okay, hey, it’s not good enough to be using AI at a personal level anymore. We need to really elevate it to team and enterprise. Like, how do we create skills that can be shared across the company? How do we make sure people have access to prompts and standards and defaults that really represent our company and our principles, our values, our thinking, our branding?” So this year the emphasis is really on elevating it beyond team. And so it’s no longer okay to have something that you just do yourself. And there’s an expectation is if it’s really providing that value, how do you bottle that up and make it available to the whole team? I want to come back to the point that I made earlier is, and this is my advice to anybody doing this, success is contagious and success is kind of compounding. And the number one best way, and this would apply for any role, any function, any department is, and I use this quote all the time, “Just look for high toil, low joy work, work that can be automated or where AI can provide assistance or leverage.” And anytime you free up capacity so people can work on other things or more strategic work or more fulfilling work, those use cases just build momentum 100%. So we still are … And we’re on the hunt for that internally in our org. So we call it reducing the drag. Anywhere where we have friction, toil, slowness, we now surface that and say, “Okay, let’s just go back and reimagine how can we leverage all these technologies we have to make that better?” And then in almost every case, we can find a better way to do it. And we’re trying to do the same thing in our products for our clients. All of our clients are being asked to do more with less and tighter budgets. And the only way you can do that is leveraging technology to help you have leverage and to force multiply people. And AI of course is a great technology for that. And so we’re just looking for opportunities where we can help people do different work, more strategic work, or free up capacity. Even if it’s just five to 10 hours a week across an organization per person, that’s huge.

Douglas Ferguson: Yeah. It’s also making me think this idea of reducing the drag, reducing toil can actually move folks into a place where the work becomes more enjoyable because they’re removing the things that they like doing the least. And so that has an opportunity to maybe improve morale.

Taran Lent: One of the most inspirational things I’ve heard in the last year, we had Zach Kass, one of the founders of OpenAI, just an incredible thought leader. And he’s thinking about this technology on a humanity level. And he was our keynote speaker at our annual client conference this year. And he was talking about what a problem it is when children in particular are spending all this time on their devices and their screens. And there’s lots of science and research around that. But he said one of his hopes for AI for humanity is, “That technology has the potential to work silently invisibly behind the scenes to make our lives better so we spend less time on screens. ‘Cause AI can be assisting us in doing work and doing things so that we can spend more time with in-person interactions versus having to work through [inaudible 00:21:05]. And so maybe there’s a future where technology’s just kind of persistent behind the scenes, making our lives easier, better, and it’s freeing us up to do more of the stuff that’s really human, right.” So I really encourage people to check out his writing and his vision of that. But if that were true, that would be a pretty amazing outcome of the technology for us as a civilization.

Douglas Ferguson: Yeah. And a great example is driving a car. Our cars are becoming more and more intelligent. The artificial intelligence that’s baked into a car is very invisible to us, but we enjoy the benefits when it’s able to adjust the lanes or alert us that we might be falling asleep or all of these things. We’re not sitting there laboring over or thinking about it, but it’s right there when we need it and it can save the day quite often.

Taran Lent: 100%. It’s a great analogy. Adaptive cruise control to me in Houston traffic is like, I love it.

Douglas Ferguson: Yeah.

Taran Lent: I was an engineering major in college and I actually got to work on a traffic study project at one point. And what a lot of people don’t know is our highway systems in most cases could support 10 times more traffic if people just drove sensibly.

Douglas Ferguson: Yeah.

Taran Lent: You maintain spacing, we’re in the correct lane for what’s your next move is, collaborated with each other. It’s incredible. There’s a phenomenon called tragedy of the commons. And when you have an individual or many individuals acting in your own self-interest, you unwittingly degrade the system to everybody’s despair. And the other thing’s interesting about traffic, by the way, this is a fascinating thing, but in a traffic jam, it takes only one car, one driver to unblock a traffic jam. Not if there’s an accident, but just if one car just backs up and provides a lot of space around it and that will unblock a traffic jam in most cases in 10 minutes. So think about if you had cars that were maintaining spacing, allowing other cars to do what they need to do. There’s one, I think we would find that traffic would become less of a problem. And then the safety aspects of that, I’m sure you would have fewer. There’s just no way that’s not our future. There’s just no way that that’s not going to be a part of our future, right.

Douglas Ferguson: Yeah, absolutely. And also now we’re getting into self-driving car land, but I’ve long been dreaming of a world where, yes, the self-driving cars are more respectful and traffic becomes less of an issue, less traffic accidents. And we don’t have to fill our urban areas with parking garages ’cause the car can just go home or go grocery shopping or whatever.

Taran Lent: Yeah. 100%. One thing that’s kind of a corollary to that is I think human tolerance for bad software is going to be a thing. We are not going to tolerate bad software, bad design, bad workflow, because it’s going to get increasingly easier if an experience is not good or not efficient or not at the standard. AI is very good at analyzing that and comparing it to all the other code repos out there and best practices. And I just think there’s going to be very low tolerance for software that’s not well-designed, that’s not well-crafted and works well. And if you’re honest with yourself and you kind of step back, there’s a lot of bad software in the world. And you look at the app store and there’s no reason to have an app of any scale that’s below three stars, but there’s many of those. And I think expectations and the standard is going to get higher and higher and higher and it’s going to be easier to meet that standard. And I think that’s going to be great for almost every realm of life where we have technology and software. The expectation’s going to be very high. And if you just think about, look at my kids, my kids, we have this instant gratification society, but their expectation when they order something, whether it’s DoorDash, Uber or Amazon, when they order it and when they’re going to get it and the level of convenience that comes with that, it’s actually relatively new in the last few years and it certainly didn’t exist when we were growing up. And that just is an example of people are just going to have different expectations over time with how this technology works.

Douglas Ferguson: I wanted to come back to your point around this year being about the move beyond the individual and thinking about these kind of team and organizational use cases. And I’m curious from your perspective, what’s the pathway that you’re taking to get there and any early wins or what are you noticing?

Taran Lent: Almost everything that we do, you do have to think about it from a guardrail perspective and compliance. We sell enterprise software. Our customers depend on us for mission-critical solutions and in some cases their data. And so everything we’re doing has to meet that bar. And so as an example, that means … I’ll take skills as an example, right. People were individually building skills that were very useful for them or maybe they’re a really localized team, but there are absolutely skills that are valuable that could be shared across the whole enterprise. And so just as a simple one, we’re rebranding to Illumia and we have the Illumia branding skill that knows our design language, knows our colors, our fonts, our imagery, everything. And so we built a skill where any document you might be working on, a presentation, a document, a letter, you can have the skill, check it for brand compliance and put that in there. And so that’s obviously a use case that was a no-brainer for us. But even skills have risk. And so we had to put in place the foundation of, hey, if somebody creates a skill, whether it’s internal or external, and it’s going to be shared across the enterprise, what policies and process need to be in place so that we can review those, make sure that they’re okay and approve them and get them published and do that in a way that’s safe. And so that’s an example. And I get requests almost every day for some new something that somebody wants to try out. It could be a plugin, it could be this or that. And honestly, our old way of reviewing requests for these things wasn’t fast enough and it wasn’t modern enough to deal with this new world. And so that’s an example where to get to the next level, we had to say, “Okay, how do we think about this and how can we support this at scale? And how can we anticipate the volume of requests we’re going to see? And how can we get these things decided or approved? Or at least if it’s not approved, a decision with, hey, we can’t do this right now for these reasons.” And so that’s an example of for our company, we had to think about those things so that we could have an operating environment where these things can happen and employees can build these things and share them with each other, right.

Douglas Ferguson: Yeah. So I’m curious, and I would imagine a lot of listeners would be curious ’cause folks are either actively designing similar processes or re-imagining existing ones. Who’s responsible for that review process? Is it a group, an individual? And is it the same process for external tools as it is for an internal skill? How does that work and even get communicated out that something’s approved?

Taran Lent: Right. We have a stakeholder group because everybody adds some value. There’s architects involved, there’s security analysts involved, there’s IT people involved because there’s a lot of things that we want everybody to evaluate from their perspective. But at the end of the day, you have to answer questions like, “Who’s the company that created this? Is it a credible, legitimate company? Are they doing business with other Fortune 500 companies? Do they have a security trust center? Do they have any compliance or assurances? Do they have an AI position? Are they clear about whether you can turn this on or off? Do they use your data to train their models?” And so what’s good is there’s good frameworks for this, but you want to know who created the tool, how they’re supporting it, what the service levels are behind it. Have they given thought to what the potential of abuses of the tool or software could be? And then with AI, you have to think about, “Hey, what happens if it does go wrong? What if it does give you the wrong answer and gives you bad advice or hallucinates? How do you confirm whether it did or didn’t? What telemetry do you have in place to track over time and then how would you retrain it to get it back on track?” And so those are the types of issues you need to think about. One of the things that I think is quite interesting is ’cause Claude’s obviously, and Anthropic are moving really, really fast and they introduced, to people who don’t know about it, a bunch of plugins that I think are amazing. They have this operations plugin and it’s got all sorts of things that are related to operations of a company and one of it’s kind of risk analysis. So they have their own risk analysis skill. And what’s interesting is that when you use the risk analysis skill on some of the new features Claude’s coming out with, it’s quite honest. It’s like, this probably isn’t really ready for primetime yet for a company at our scale. Companies are all different. We’re a public company at scale and so there’s a different standard that we operate to, which might be different than a startup. But that’s even an example of, like, even you could even leverage AI to help you with your risk analysis and to think through, “Okay, what are all the vectors here that could be exploited or abused or cause unintended consequence?” And just so you can have your eyes open when you’re making decisions. And by the way, the goal is never for risk to be zero, just so … As the CTO and I also am responsible for security and compliance, the goal is never for risk to be zero, it’s just to be informed and have your eyes open and the benefits have to outweigh their risks. And you got to say, “Hey, I think this is worth it.” Right.

Douglas Ferguson: Yeah.

Taran Lent: Or, “Hey, mitigation’s in place,” or you can put other measures in place to make it manageable.

Douglas Ferguson: And what’s your typical turn time on approvals now that things are moving so fast?

Taran Lent: So what I would say is if it’s something new, if it’s a company or vendor we’ve never ever worked with before, and the party we’re working with internally is well-informed on what the process is, it’s usually four to six weeks ’cause there’s contracts, there’s usually redlining and there’s some …

Douglas Ferguson: Okay. Yeah, yeah.

Taran Lent: And now if it’s already an existing vendor and something we’ve been doing business with and they’re introducing some new AI capability to plug in or tool, we can kind of fast track that. But one of the things we’re trying to do too is how can you do some provisional approvals? How do you have different tiers based on risk? But what I tell people is yes, and by the way, people complain about the four to six weeks and I understand that. But what’s great is somebody’s got to make the argument and kind of push it through. But after that four to six weeks, then it’s approved and we can use it for the next decade. And so in relative timescale. And look, at the end of the day, our customers depend on us to be thoughtful and to be smart and to be safe. And for me, that’s part of the value proposition you get from our company is that you can trust us with your mission-critical processes and you can trust us with your innovation and we’re going to help you. And by the way, our customers are hospitals and healthcare and universities. They tend to be relatively conservative about these things. They’re absolutely trying to protect. There’s HIPAA and FERPA and all these things. But that’s an opportunity for us to be a thought leader and to help them create frameworks and structure for how you can safely adopt these technologies and apply them to your use cases.

Douglas Ferguson: What’s your approach to sharing skills with the broader organization? The reason I’m asking, I’m really curious because I see a lot of folks checking these things into Git, but then that requires anyone who wants access to kills to also have access to Git. So then there’s challenges there.

Taran Lent: Yeah. Well look, and the other thing too is people need to understand that the real value of the skills too is they’re going to evolve over time. So the first version that you put in is probably not the best and it’s not the last. And so the question is more, I think open source software is a great model to look to ’cause … So for example, we’re really into the Silicon Valley Product Group, product operating model at our company. And we had somebody create the SVPG product operating model skill so you can have it evaluate things. Well, that was just one person. We’ve got a lot of people that are well-trained on this and have points of view. And so the question is how do you create a space where people can review the skill, can add to it, you can add it, collaborate it, evolve it. Ultimately you do need version control. And so Git is a good way to do it. Not everybody has that skillset. So that’s where that board comes into play is, “Hey, get us your feedback on the skill however you want.” And then so long as we have people who help you can get it published and manage version control, there’s a way to do that. But look, I think you do need version control. You do need to have reviews to make sure, “Hey, is the quality there? Is there anything there that may not be in alignment with what we’re trying to get done?” And by the way, kind of a related thing to that, one of the things that’s happened in our company that’s unique is for 20 years, all the developers were in my department and we established process and standards, things like, “Here’s your annual secure coding, here’s how our pipelines work. These are the security and vulnerability scans that are going to get run on code when you check it in. When you download third-party software, it has to come from a repo that we’ve verified it’s coming from a legitimate source.” There’s all these controls around these things. And so my teams are expert at working this way. Suddenly now other departments are hiring developers or builders or creators, right, and they’re creating things and then wanting to publish them and share them, but it’s outside of my org, so they’re not necessarily subject to … And so the question is how do you enable that? ‘Cause I certainly don’t want to stand in the way of that. That’s just where we’re going. But how do you create sandboxes and process where people who are not engineering the products that we deliver to our clients, these are a lot of times our internal productivity tools. How do we put them in a position where they can build things and then release them, but we’re confident it’s … So just as an example of, I think you said you wanted me to talk about some failures too.

Douglas Ferguson: Yeah.

Taran Lent: I’ve seen people build solutions that had access to confidential information that we wouldn’t want our competitors to have, and they published a dashboard or whatever that had no authentication. It was open to the public. You could take the link and put it in incognito and I’m like, “Well, that’s an example of something you absolutely can’t do.” So then the question is how do I create it so that it’s really easy for someone that may not have that skillset to publish their app and have it behind their SSO authentication, and they don’t have to reinvent that wheel, but we can create a place where they can publish that, that you only can get to it if you’re an authenticated person that should have access to it? Point though there is, like, everybody’s going to start building. We’re going to see an explosion of builders and creators. And if you can anticipate that, how do you make sure you set up an environment where you can teach them what they need to know and you can make it easy for them to do what they’re trying to do leveraging these new capabilities?

Douglas Ferguson: And what sorts of guardrails and sandboxes might we create so that-

Taran Lent: 100%. Right.

Douglas Ferguson: … they can play and not worry about creating harm? So there’s a couple of things I wanted to hit on before we run out of time. One is I’m curious what sorts of shifts and impacts you’ve seen on your product development life cycle. Have there been things that you’ve just straight up removed or completely changed or things that you’ve tweaked to support these new ways of working and bringing AI into these moments?

Taran Lent: So I’ll start with talking about engineering and how it’s working there. But if we went back two years ago and you looked at it, probably less than 20% of our code was being AI assisted. If you look today, it’s more like 90 to 95% of the code that we’re putting out is AI assisted. That could be AI generated, it could be AI reviewed, it could be agentically-created code, but that just shows you the natural adoption curve within the engineers. We’re actually seeing, if we actually look today, it’s different based on the tech stack you’re working on, but if it’s a modern tech stack, we’re absolutely seeing 20, 25, 30% productivity gains on throughput. On legacy code, that may not be as standardized and AI models aren’t as trained on, we’re not seeing that kind of gain. And then there’s a few areas where we’ve seen orders of magnitude productivity. But where I’m actually most excited about is not on the engineering productivity. I think on the upfront product discovery, validation, research, prototyping with clients, I think that’s going to be where we see this extraordinary leverage and gains. And you mentioned it earlier, but product managers used to do surveys and advisory boards and all these different ways to get feedback. Now you can just go talk to clients either in person or over the phone, you can observe them while you can capture these transcripts and you run those transcripts through a bunch of AI, you can get insights about your products, problems they have, feedback for services, support. And to me, I think just the tools available to product managers to research, to uncover insights, to prototype, to get early feedback to fail and learn, it almost makes you want to go back into a product management career. I just think it’s going to be so fun for people. And I do think there’s going to be a convergence of, ’cause historically there’s a designer and a product manager and a tech lead. And I think there’s a category person that I think is going to rule the world. The technical person that has design sensibility and good business product acumen, I think in some cases I can converge all the way down to one person using AI in a really resourceful way or maybe two people doing that. But I think, ’cause if you can get validated work that’s really clear and then you provide that to an engineering team, they’re going to go wicked fast, much faster than they’ve gone historically.

Douglas Ferguson: Yeah. And I think the amount of information you can process, not only interviews that I’ve conducted or my team’s conducted, but also what about all the customer service calls and all the sales calls? And there’s so much that could go into learning and extracting insights.

Taran Lent: It’s the best form of feedback. It’s the best form of feedback. There’s no doubt about it. And innovation a lot of time is about seeing patterns that other people don’t see or seeing insights, you know, and people talk about looking around the corner. AI can absolutely help you look around the corner if you have enough data with enough signals and enough patterns, right.

Douglas Ferguson: Yeah. And then there comes the new friction, which is the discernment on which pattern matters and where we’re going to invest our dollars.

Taran Lent: Well, that’s never easy. And I tell people all the time, “Great companies, you’re never deciding between a great idea and a bad idea. You’re looking at 20 great ideas that all have merit and you can do three.” And that’s where we get back to the humanity of it. Like, yes, there’s data and yes, there’s science, but there’s art to everything and human judgment, human discretion, human intuition still has a role to play in this. And we all know them. There’s people that we work with that just are right a lot. They’ve got really, whatever it is, their life experience and everything they’ve read and how their brain works and how they connect dots. And that’s always going to be valuable in this world. And so people that operate that way, AI is only going to make them more impactful, more effective. That’s my view.

Douglas Ferguson: Absolutely. My last question, I know y’all just went through a merger and so you’re in an environment where you’ve got two different cultures, which sometimes can be vastly different and sometimes can be very similar, but rarely are identical. And we’re in this moment where people are asked to show up and work different. So there’s this transition in our ways of working and how we’re using these tools that are frankly evolving daily. And then you’ve also got two different cultures that are coming together. So to me, when I think about that, there’s some extra layers of complexity. I’m curious what you’ve noticed and has that been a smooth ride or is it kind of figure it out as you go? What can you share about that?

Taran Lent: It’s a great question. The culture to me is the X factor. Most companies have intelligent people, but it’s the culture that I think wins the day. I think we’re relatively fortunate the cultures of the two companies we’re putting together. So Transact and CBORD are coming together at Illumia. Because both companies were very purpose and mission-driven … At the end, look, what we do, we help colleges use technology to operate more efficiently and elevate their end user experience for students, parents, faculty, staff. The shorter way to say that is we use technology to make college even cooler than it already is, right. And then in healthcare, we provide solutions around helping hospitals and healthcare environments provide world-class food services. And we think about it when you’re in a patient in a hospital healing from something, food is medicine and food is care. And it might be the one bright spot in the day. And so our technology helps make sure patients get the right food based on their doctor’s orders and also that nurses, doctors, family are well-nourished when they’re in a stressful setting. And because we’re mission-driven like that, I think our cultures were more similar than they weren’t and we were actually quite eager to learn from each other like, “Hey, how are you doing this? How are you doing that?” But what we look for, I mean, we look for people that are humble, hungry and smart. So humble means you care about the team more than yourself and you put team first. Hungry means you’re competitive and you want to win for your clients, you want to beat the competition. And smart means you’re not only intellectually smart, but you’re EQ smart in terms of the culture and the dynamics. But those things matter. And so I think those people that kind of fit that criteria are people that tend to be more adaptable and willing to be self-learners. And look, what AI demands of all of us is that you lean in and you try, you experiment, you fail, you learn. And if you do that, you’re going to be fine. I tell people all the time, “Look, if you show up and you put the team first, you work hard, you’re learning, you’re experimenting, you’re keeping your skills sharp, you should not worry about the future for yourself or your career. If you’re resisting or you’re not willing to learn, you’re not willing to change, that might be a tough road for you, so …” But people have a choice. And for me, this is the most fun I’ve had my whole career just ’cause it’s just so exciting. How lucky are we that this is happening during our careers and that we can … And just put yourself in my shoes. If I can drive productivity in my teams, if I can accomplish the same thing with smaller teams, that means I can just self-fund more ideas and more innovation. It just means the dollars go further and I don’t need to go ask for money or resources. I can free up capacity and go be in control of my own destiny. So as a tech leader, that’s amazing.

Douglas Ferguson: Yes, totally agree. And as we come to a wrap here, I want to give you an opportunity to leave our listeners with a final thought.

Taran Lent: I’ll go back to what I said at the beginning. None of us really know where this is all going and that’s okay. So don’t pretend. I think there’s a whole bunch of people that are overestimating what this means for us. There’s a lot of people underestimating and I just would encourage people to just experiment, to play, to have conversations like this one, to learn, to share. There’s so much information out there, but I think we need thought leaders that are going to use this technology … All technologies can be used for good or for bad, so if you’re in this industry, be a force for good. Help steer this in the right direction. Be engaged and be active. And I think if we have enough people do that, we’re going to see a really amazing future that we’re all proud to be part of.

Douglas Ferguson: I agree. It’s been great chatting with you, Taran. I’m looking forward to catching you again soon.

Taran Lent: Yeah. Thanks again for the opportunity and you take care. We’ll be in touch.

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 Scaling AI From Personal Habit To Company Capability appeared first on Voltage Control.

Which Friction to Remove, and Which to Design Back In

For most of the last two decades, removing friction was the whole job. Every extra click, every approval step, every handoff that made a customer wait was waste, and the work of good leadership was to find it and delete it. We built entire disciplines around it. Lean. Six Sigma. Growth. Conversion-rate optimization. Design thinking, in its most reductive form, became a hunt for anything that slowed the user down. The companies that got smoothest fastest won, and they deserved to. AI has now made friction removal nearly free. Whatever obstacle is left in a workflow, there is a tool that will dissolve it this quarter. The drafting step, the research step, the first-pass review, the scheduling back-and-forth, the synthesis of twelve documents into one. The reconciliation, the summary, the first draft of nearly anything. Gone, or going. And that is the trap. When removing friction costs almost nothing, the temptation is to remove all of it. But not all friction is waste. Some of it was the only thing developing your people. Some of it was the only thing keeping a human close enough to the work to notice when something was about to go wrong. Strip that out along with the rest, and you get an organization that runs beautifully right up until the moment it needs judgment it no longer has. The discipline leaders need now is not friction removal. That skill is commoditized; the tools do it for you. The new discipline is friction discernment: the ability to tell the difference between the friction that drains people and the friction that develops them. Remove the first kind without mercy. Design the second kind back in on purpose. Everything else in the new friction follows from getting this one distinction right.

The two kinds of friction

Draining friction is friction that costs effort and returns nothing. The approval that exists because someone got burned in 2014 and no one has revisited it since. The status meeting that could have been a sentence. The reformatting of a report from one template into another. The manual data pull that a script does in a second. The form that asks for information the system already has. This friction does not build skill, protect quality, or surface insight. It just taxes attention and demoralizes the people subjected to it. AI should eat all of it, and you should let it. There is no virtue in preserving busywork, and no one should confuse what follows with nostalgia for it. Developmental friction is different. It costs effort and returns capability. The junior analyst who has to build the model by hand the first ten times, and only then earns the right to have a tool build it, because now they can tell when the tool is wrong. The reviewer is forced to articulate why an output is flawed before they are allowed to reject it. The team that has to argue its way to a decision instead of accepting the first plausible recommendation that appears on the screen. The new hire who sits in on the hard customer call instead of reading the AI summary afterward. This friction is slow. It feels like waste in the quarterly numbers. And it is the entire mechanism by which expertise, judgment, and trust get built. Here is what makes discernment hard, and why it is a discipline rather than a checklist. The two kinds of friction look identical on a process map. Both are steps that slow things down. Both show up in a time-and-motion study as cost. You cannot tell which is which by measuring duration, because duration is not the variable that matters. You can only tell by asking what the friction is producing. A leader who optimizes purely for speed has no way to see the difference, and will remove both with equal enthusiasm.

Why we are getting this wrong right now

The error is not stupidity. It is a structural asymmetry in what leaders can see. Efficiency is legible. It shows up in the dashboard the week after you automate something: fewer hours, lower cost, faster cycle time, a clean line that goes the right direction. You can put it in a board deck. You can attach your name to it. Judgment loss is illegible. It shows up nowhere, for a long time. It hides inside the year-over-year improvement metrics and the reduced headcount and the deliverables that ship faster and look clean, right up until a situation arrives that needs taste, or context, or the ability to know what is not in the data. By then the people who would have caught it have either atrophied the capability or never built it at all. JoAnna Vanderhoef gave this hidden cost a name: capability debt, the widening gap between an organization’s apparent efficiency and its actual adaptive capacity. Like technical debt, it accumulates quietly and charges interest later. Unlike technical debt, most organizations are not even tracking it. They are removing developmental friction at speed, booking the efficiency, and treating the judgment that disappears as if it were free. It is not free. It is borrowed, and the loan comes due on the worst possible day.

The evidence that friction can be load-bearing

This is not a motivational point. It is measurable. In a controlled study presented at the BIG.AI@MIT conference this year, Renee Gosline’s MIT team gave people cognitive tasks with AI assistance. In one condition, the AI made a recommendation and the person accepted or rejected it. In the other, the person first had to articulate their own reasoning, or predict what the AI’s reasoning was, before deciding. That single step took about thirty seconds. It measurably reduced over-reliance on the AI and preserved the person’s own critical thinking. Thirty seconds of deliberate friction kept the human’s judgment intact. Remove it, and the judgment quietly erodes until the day the AI is confidently wrong and no one in the room has kept the muscle to notice. The mechanism behind where this damage concentrates was formalized by a team of researchers at MIT, Yale, and Microsoft led by Mert Demirer. They studied what they call AI chains: sequences of work steps where the automatable steps are contiguous, so a human only has to verify the final output. The economic incentive is to keep extending the chain until the marginal cost of an error overwhelms the saved verification. The jobs that automate fastest are the ones where AI-suitable steps cluster together. Those are also, and this is the part that matters, the jobs where learning loops used to live. The junior who once did the research, drafted the slides, and watched a senior edit them loses three apprenticeship cycles per deliverable when the whole chain collapses into one automated unit. The work still gets done. The person stops getting made. So the friction you are tempted to remove fastest, the long contiguous chain, is frequently the exact friction that was developing your bench. Efficiency and capability erosion are not opposing forces you can balance. In the most automatable workflows, they are the same move

The test

Before you remove a piece of friction, run it through three questions. They take a minute, and they are the discipline in practice. First: what is this friction producing? If the honest answer is nothing, it is draining friction. Remove it without hesitation. If the answer is a skill, a judgment, a relationship, or a moment where someone learns to catch what a system would miss, you are looking at developmental friction, and removal has a hidden cost you need to price. Second: who was getting developed here, and where will they get developed instead? Most automation quietly deletes an apprenticeship without anyone deciding to. If you cannot name where the replacement reps come from, you are not saving time. You are borrowing capability from your future bench, and the interest rate is high. Third: what happens on a bad day? Efficiency holds until something breaks, and then recovery runs on the slack and the judgment you preserved, not the slack and judgment you optimized away. If removing this friction means no human is left who could step in when the system is confidently wrong, the friction was load-bearing, and you are about to knock out a wall. Run a concrete case through it. A team proposes to fully automate the first draft of every client proposal. Question one: what is the drafting producing? Not just a document. It is where account managers learn the client’s business well enough to defend the recommendation in the room. Question two: if the AI drafts them all, where do new account managers build that fluency? No one has an answer. Question three: when a client pushes back hard in a meeting, who has internalized the reasoning well enough to respond? The honest run-through does not say “never automate this.” It says automate the formatting and the boilerplate, and keep new managers writing the core argument by hand until they have earned the shortcut. That is friction discernment producing a different, better decision than “remove it” or “keep it.”

The moves

Discernment becomes real when it changes what leaders actually do. Three moves follow directly. Stop automating contiguous chains to the end without asking what skill the chain was building. The most automatable workflows are exactly where capability debt compounds fastest, because they are where whole apprenticeships used to live. Automate them deliberately, and keep a human in the loop where the learning was, not only where the legal liability is. The liability checkpoint protects the company this quarter. The learning checkpoint protects it in five years. Start designing developmental friction on purpose. Route a deliberate fraction of automatable work to humans anyway, so the capability stays alive. Require a thirty-second reasoning step before anyone accepts an AI output on a decision that matters. Run novelty drills, where work that could be automated is occasionally done by hand to keep the skill warm. Sample AI outputs not for quality assurance but for drift. Bring in someone who has not been close to a pipeline to ask whether it is still doing the right thing. None of these are productivity moves. All of them are capability moves, and the point is not to make the system slower. The point is to keep it teachable. Change what you celebrate. When a team automates forty percent of someone’s job, the reflex is to bank the savings and move on. The better move, which we have watched work, is to make the freed capacity a deliberate conversation: what harder, more developmental, more human work does this person now get to do? Organizations that celebrate only efficiency teach their people that the goal is to automate themselves toward the exit. Organizations that celebrate the redeployment teach them that AI is how they grow into more valuable work. Friction discernment is not anti-efficiency. It is efficiency pointed at the right target.

Why this is the leadership job now

When execution was expensive, leadership’s job was to clear the path: remove the blocker, approve the budget, unstick the review cycle. That job is mostly done, and the leaders still doing only that are optimizing a bottleneck that has already moved. The new job is friction discernment, and it cannot be delegated to a tool, because it is precisely the judgment about which judgments to keep. It is the one decision the AI cannot make for you, because the AI’s entire bias is toward removing friction, and the question in front of you is when not to. The organizations that get this right will look slower for a few quarters and less impressive in the efficiency reports. They will also still have, when the situation changes, the people who can do the work the model cannot. The organizations that remove every obstacle they can afford will discover, on the worst possible day, that they removed the ones holding the building up. Stop removing every obstacle. Learn to tell the difference. Remove the friction that drains your people. Design the friction that develops them. That is the discipline, and everything else in the new friction follows from it.

The post The Friction Discernment Test appeared first on Voltage Control.

In this episode of the Facilitation Lab podcast, host Douglas Ferguson interviews Sarah B. Nelson, Distinguished Designer at Kyndryl and co-founder of Kyndryl Vital, about why AI’s promise to remove friction is actually surfacing the human dynamics organizations have always avoided facing. They unpack how a single word like trust splinters into distinct concerns — model accuracy, data use, organizational credibility — and why treating human in the loop as a rubber-stamp step risks disengagement and stripped-out meaning. Nelson draws on the NeuroLeadership Institute’s SCARF model to explain why AI rollouts stall on status, certainty, autonomy, relatedness, and fairness rather than on the technology itself, and shares stories spanning cybersecurity burnout, Holacracy at Zappos, and the extraction economics behind AI training data. The conversation keeps returning to her insistence on designing with people rather than at or for them, and on imagination as the resource most at risk of being engineered out of enterprises chasing speed. She closes with a Buckminster Fuller line she keeps returning to: that people are called to be architects of the future, not victims of it.

Show Highlights

[00:01:46] Why 95 Percent Of AI Initiatives Fail
[00:09:20] Trust Is Behavior Over Time
[00:12:23] Human In The Loop Versus On The Loop
[00:16:03] Psychological Safety And Cybersecurity Burnout
[00:25:59] The SCARF Model And Organizational Autonomy
[00:30:27] Lessons From Holacracy And Flat Organizations
[00:35:40] Building New Rituals For Working With AI
[00:42:38] Imagination As The Friction Worth Keeping
[00:47:48] Architects Of The Future Not Victims

Links | Resources

Sarah B. Nelson on LinkedIn
Voltage Control

About the Guest

Sarah B. Nelson is a Distinguished Designer and co-founder of Kyndryl Vital, Kyndryl’s co-creation and experience design service, and hosts Kyndryl’s The Progress Report podcast. She has spent her career at the intersection of human-centered design and enterprise transformation, including roles at IBM and PepsiCo, building the methodologies and communities that moved organizations toward shared futures even on shaky ground. She previously joined Douglas Ferguson on Episode 42 of the Voltage Control podcast, “Healing the Collaboration Pain Point.” A classically trained violinist whose first computer was an IBM 360 terminal, Nelson describes her current focus as figuring out what comes next for design — new applications, new methods, and the new organizations that support them.

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. I’d like to introduce you to my conversation partner today, Sarah B. Nelson, Distinguished Designer at Kyndryl where she specializes in emerging human-centered design practices. She’s also the host of Kyndryl’s The Progress Report Podcast. Welcome to the show, Sarah.

Sarah B. Nelson: Hey, hi. Happy to be here.

Douglas Ferguson: Yeah, it’s great to be in conversation with you. I always enjoy our conversations and I think today will be no difference.

Sarah B. Nelson: Excellent. Yeah, same.

Douglas Ferguson: Yeah, let’s start off with this reframe that I’ve been considering. It’s like designers have always been the people in the room arguing for friction, the user research, the design phase. Let’s slow down and understand the human first. Now that we’re operating in a world where AI’s whole pitch is removing friction, are you the resistance or has design just become redefined?

Sarah B. Nelson: I think it’s still a yes. We’re in a transition period and transitions aren’t… It’s not like flipping a switch. I think there’s a sort of dawning realization that I see on a pretty regular basis when we look at the statistics around the number of AI initiatives that fail, and it’s like 95%, which I always say is like, well, 5% succeed. I don’t say that as to be Pollyanna, but I like that that number is a lot smaller because it’s sort of saying that there’s something going on, more than one or two things going on about why these things are failing. Some of it… And generally, at least my bias is that most problems, the root cause of most problems is something to do in people dynamics. And I think that’s a lot of what design does, is it is that sort of pause to ask what’s going on. And I think, I hate to say it like this, but sometimes lessons have to be learned the hard way. And so people, you can see it, they’re investing the dot strategies. They’re like, “We got to do this, but then our data’s not set up and then none of our people want to use it, and some people are even sabotaging it.” There are all of these signals that are much louder than, “We have this persona, or we talk to 20 people, or trust us, bro. We stand for the user.” I think there’s some really clear stuff coming up and then the friction becomes everyone’s problem. It’s not just designers waving a flag. And I think that’s where it becomes really interesting when people start to realize that experience is everyone’s responsibility and everyone’s problem, because the technology itself does not… If you put technology first, it doesn’t fix it. Because I feel like a lot of times people go, like technology, money, process, people. And it’s exactly the opposite. It’s people into process into money into technology. Technology kind of comes at the end. By money, I mean how does the economics of the solutions work as well?

Douglas Ferguson: Yeah. And it’s funny, a lot of the people that I see starting to realize the orders flip, they typically end up putting the process first, as they’re trying to flip it and invert it. And it’s like, no, no, no, you really need to start with the people. And to your point, it needs to be ubiquitous. We can’t just have, just like where heads of innovation or little innovation groups never really actually worked. When design is something only one group is doing or thinking about, we’re going to be fraught with issues because the fact of the matter is every part of the organization is getting disrupted by AI, and we all had to be approaching this from a design problem, from a systemic kind of lens so that we’re not just, to your point, throwing a technology solution at it and hoping it works.

Sarah B. Nelson: Yeah. I mean what’s interesting is that in some of the projects that we’re working on, we’re rethinking roles. I mean, obviously I have distinguished designer, but I think the question of, what does it mean? I mean, so my definition of designer is every human… Designing is what we do as humans. And some people are professionally trained to do that. But everyone is designing. So there’s a lot of skills that need to go in behind that. But what’s kind of interesting right now is the conversations, even in this deep in the technical work, you hear the words trust thrown around a lot, transparency, explainability, accuracy, because we’re not calling it hallucinations anymore, but I just say lying on the part of the model. But all of these things that become this soup of, at the heart of it, understanding why people are hesitant to use it. So if it’s inaccurate, why should I trust it? What’s it doing with my data? Why should I trust it? If it’s sucking up to me all the time, why should I trust it? And then am I training people? Am I training it to do my job? All of those very fundamental pieces that are rocking people at their very, very core. But it’s interesting because I see that language in even the most technical conversations. Sometimes the solution is then technical because the next step doesn’t necessarily always say, “Well, what is it that humans are experiencing?” It’s like, “Well, how do we ensure more accuracy?” And there’s this next level of digging into what the next level problem is. I think that’s going to come next as people are starting to make these workflows and test them and seeing what works as well.

Douglas Ferguson: I think you’re right. And in addition to drilling into the knock-on effects, the second and third order, we also need to step back and even consider what we mean by these words because there’s many facets of trust as we walk into this moment and into the future. The word trust comes up a ton. Very similarly, trust and governance are two that come up a bunch and they can mean a lot of different things. And we had to be careful when we throw the words around without getting a layer deeper and really book-ending and compartmentalizing it. What are we concerned with in this moment? What are the outcomes we’re trying to design to? And what kind of environment are we trying to create? Because a great example of this is, you touched on one facet of trust, which is like, is it giving me reliable answers? And this came up in Buffalo when we were working on the Empire AI Summit, and it was a table of librarians. They said, “I don’t care if it’s AI generated, I care if it’s true.” So it’s just like this trust and this like, is it true? Is it accurate? But then there’s also so many other types of trust that come up in these conversations, but another one that’s surprising, just to give you an example, is trust in the organization.

Sarah B. Nelson: Yes, that’s what I was just going to say. Yeah.

Douglas Ferguson: Yeah. Orgs are constantly reorging or they’re just trying to respond to the market and what’s developing around the capabilities of AI and how things are getting reshaped. The message might change a ton and that can be very, especially if an org hasn’t necessarily put people first in the past. It’s a double-edged sword because now you’re like, “Well, I don’t trust your past behavior, so what does this even mean now?” So it just almost adds kerosene to that fire.

Sarah B. Nelson: Yeah, that’s what I was exactly thinking. I think there’s so much foundational work. I was trying to think about… So I think trust is behavior over time. Are you doing something? Are you showing up in a consistent way? I mean, in some ways you can trust a lot of businesses’ behavior because they will always put shareholder first. On one level, you can trust that you know that that’s how they’re going to behave. But there’s this fundamental, I think I 100% agree with you that, if you haven’t demonstrated that you put people first to now, why should I believe you that you would do that? And I think that’s where I just get really interested in how people respond to that. There’s this idea in relationship systems coaching called rank and revenge, which I love. So the idea of rank and revenge is that people respond when they don’t have power often by rank, their power is in revenge. And they can be little small things. They can be overt revenges. They can be little small things, like I’m five minutes late to the meeting. Or, oh, I ate your lunch. I don’t think that that necessarily is one, but I don’t know, it could be. But I guess it’s been really fascinated by this idea of, or what’s happening in some places where people are putting in false data or taking the company data and polluting it into public models. How can they respond when they feel like they have no power? Oh, and we were at the same thing. We were at the Gardner Workplace thing and they talked a lot about this. Trust was huge and experience was huge. And one of the things I really took away from that was how do you engage people in the design of their own future? I mean, I’ve always been a participatory design person. I really think you should be designing with, not at or for. And I think the question is how do we engage people in this, the design of the systems they’re going to use so that they see themselves in it and it actually solves their needs? I was then run up into the, how do you do that at scale? Blah, blah, blah, blah, blah. But you can’t force people to change. They will change when they want to, in general.

Douglas Ferguson: That’s right. I remember early on in one of our conferences, maybe our second or third conference, and we were holding a workshop on facilitation. It was a little two-day session, kind of a introductory thing. And someone raised their hand at some point and say, “Well, when people aren’t doing the thing I need to do, how do I make them do it?” In regard to some activity or something.

Sarah B. Nelson: Bad question.

Douglas Ferguson: Yeah, it was like a laugh out loud moment because I was like, “Well, you don’t make people do anything. It’s all about creating the conditions where they want to do it. They’re enrolled, they’re enticed, they’re invited.” And I liked what you were saying about a participatory design and how important it is. And there is a question around how to scale it, but if you take a systems approach, anything’s possible one step at a time. And I think that in this age, one way to rethink it is, we talk a lot about human in the loop, but if we rephrase that to human on the loop, we start to think about something that people have a little bit more agency. They’re not just a cog. I’m not just on this assembly line moving my little piece. It’s like I’m observing the loop. I’m noticing patterns. I’m maybe evolving the loop. I don’t necessarily have to be a stage gate. I can be a more authorship, ownership agency.

Sarah B. Nelson: Yeah. I’ve been thinking a lot about that because I’m seeing diagrams, I’m seeing well-intentioned people designing these processes and they take the human in the loop and that’s the acknowledgement that not everything’s going to be accurate. But that’s one of the concerns I have is that it starts to put people in a spot where they’re button pushers, or I worry about not challenging people, giving people meaning. And I worry about it for a couple of reasons. There’s the humans need meaning. They need to matter. And that’s I think a huge part of what work brings us actually. But the second part is disengagement. So you start, you put in these stage gates and people can just, they become rote or they don’t feel like they matter so they just get approved without really looking at them. Or you just become used to the machine giving you information being like, “I trust it. I trust it. I trust it.” Even if it’s not giving you that. So I like the idea of changing that relationship on the loop. One of the things we’ve been talking about is how do you have… I can’t think of the word for it right now, is when something is like… A decision is made that is unfair in some way or incorrect. How as a human can you intervene in a system where human maybe wasn’t designed originally to intervene? So I don’t know if restitution, I can’t think of what the word is.

Douglas Ferguson: Well, it’s reminded me of in the lean manufacturing, it’s the Andon cord where Toyota had a whole line. It was literally the cord that people could reach up and pull. So anybody, regardless of rank or position or whatever role they were performing, could shut the entire assembly line down. Yeah, so what are these ripcords or these kind of eject halt all progress because we’ve noticed something? I think that’s going to be super critical in the systems we build that are truly agentic and cross-functional.

Sarah B. Nelson: Yeah. What you just put me in mind of is around safety. And there’s something about in that assembly line that there’s actual… I’m sure they can pull it for quality reasons, but they can pull it for physical safety reasons as well. And it’s interesting because safety is a huge part of what… One of the big concerns around AI as well, but it’s almost in some ways more abstract. It could be real. I mean obviously if you’re doing in physical applications, yes. But I think about this, what is safety and how do you notice safety in that way? I don’t know, but there’s something, this might be completely off the topic, I don’t know. So let me try first. I did this podcast at Kyndryl. One of the ones that I really enjoyed is a strange word for it, but it was about PTSD in cybersecurity professionals. And a lot of cybersecurity professionals and CISOs and people like that, they have one of the highest burnout rates of any profession, including frontline nurses. And one of the reasons is that they sit in a perpetual state of threat. They can’t see threat. So if you’re in a battlefield, there are bombs going off or you have a sense of threat, but the threat ends. Let’s assume you make it out, the threat ends, you go back somewhere. Now people do PTSD as things will trigger it. But in security world, there’s a sense that there are people who are intruding. You cannot see them. You’ll never see them coming. You’re trying to do your best. And what happens, is your body never lets it go. So it’s a different kind of this perpetual stress and they’re often in their homes. So their homes are where this stress is. So this is a guy who works with them in different processes to help folks relieve themselves the PTSD, particularly after intrusions. But it just strikes me that there’s these different notions of what safety is, and that we don’t know exactly what the impact would be on workers and maybe even on seemingly safe kinds of applications. So I don’t know if that-

Douglas Ferguson: No, I mean it’s interesting. It brings up a whole new definition of psychological safety. Not only, like the Amy Edmondson’s, do I feel comfortable speaking up? But is this safe to my psyche? Is this going to be neurosis-inducing or it’s going to cause issues if we’re using it in these ways? It certainly hasn’t been studied yet. There’s lots of folks that say that our test scores are failing because of how much computers are used in education now and it’s impacting actual deep learning. I don’t know. I think the jury might still be out on that a little bit. There’s some people that are very passionate about it and they have evidence and research, but we certainly don’t have research yet on how AI is impacting our brains at that level and not any longitudinal ones for sure.

Sarah B. Nelson: Yeah, not longitudinal. I think there’s also the other parts of what’s happening in AI. And I’m thinking about the extraction in the global south, that a lot of AI, the models are being trained by people in areas that are economically challenged areas. They get paid very little to see often very traumatic information. And so that’s kind of in the system. And I think about, so companies have given them those kinds of things to do. And they’re like, okay, there are these humans, we need humans. So these are humans in the loop, but they’re going to do the stuff that we won’t want the Westerners to look at. We don’t want it to even show up for… So we work on these models already that have been cleaned by humans. And then I think in solution land, we have to be thinking about that whole human in it. And I think obviously the ethics of how these models are developed and the large tech companies and how they’re doing that. And then thinking about how we’re setting up employees and where are we dehumanizing them? Well, technically keeping the human in the loop as well. And I think just to your point, I think we just don’t know where some of these things are going to really do. Just know that pushing buttons all day long is not… Pushing buttons that doesn’t have a sense of connection or all of that.

Douglas Ferguson: Talking about dehumanizing, I ran into someone the other day while walking my dog and I hadn’t seen them in a long time. I was just chatting about things, and they’re a bit out of this space. They work kind of tech-adjacent. They have a white collar job, but they’re not living in AI. They’re not building products. And they’re a little bit outside of the spaces you and I occupy day-to-day, but it’s still hitting them. And it’s really fascinating because she’s very disgruntled about, there’s a specific project that leadership was pushing through and she’s like, “We’ve been telling them for months, if not years, that this is important. And now because the AI is saying it’s important, now they’re prioritizing it.” And it’s kind of dehumanizing because it’s like, “Wait, now that this machine that often gets things wrong is saying this, you’re going to believe it, but you didn’t believe us?” And so I think we have to be careful, even if it is helping us see the world a little differently as leaders, we have to think about how our actions that are influenced by these machines are getting perceived by those around us.

Sarah B. Nelson: Yeah. So those are these kinds of, for instance, leaders constantly make decisions without… And I mean it all, good intent, bad intent can make decisions without really being aware of impact, or just thoughtlessly. So there is more of a need for attention to what’s happening on the ground. And again, it goes back… There’s a fundamental, I can’t quite put my finger on it. There’s just this fundamental mistrust of other humans. I don’t know. I mean, if I get all wax, I’m so intellectual, I keep thinking about Turnerism and the history of, at least American business that Peter Drucker was one of the first people that said, “Hey, thought workers are not assembly line workers, you need to manage them differently.” But that even in the world of business education and all of that is that we’re not that far off of the ’50s, ’60s belief that business is an assembly line. And I remember actually there was a company I had joined and I went through the orientation. It was like, “This is how the business works.” And the entire business was about getting product to market and getting money for that. And it was every single thing in the business was doing that. Now it was manufacturing, so it was about that. And then they kind of just tucked… Design and innovation and marketing were almost literally tucked at the sides of it. And it was a moment that I had a realization, it’s like, the way that I think about what we’re doing and what my role is, and what my role is in the company is very, very different than everyone else’s. And it was the first time I saw it very laid out, as my job is to, are we working on the right thing? Are we serving the people? Are we developing new sources of value by doing that? There’s all these assumptions in there, but it is not about doing that in literally an efficient way, in the way that the rest of the business is clearly measured on. So that just becomes like… Do you know what I’m saying?

Douglas Ferguson: Yeah, it reminds me of just innovation functions. Innovation’s not meant to be efficient. It’s meant to uncover the next big opportunity. And then operationalizing is when you think about bringing in efficiency. And I think a lot of folks don’t necessarily set their strategy accordingly. If we’re in an innovation cycle, we should not be trying to optimize and make things as efficient as possible, but oftentimes that’s the posture. And I think that’s another good point, is making sure that we as leaders identify good postures for how we want to leverage AI. So it’s not just, “Hey, everyone’s doing it. We got to jump on or we’re going to get left behind.” It’s like while those fears and anxieties might be rooted in truth, we’re not going to be successful unless we step back and say, “Well, to what extent? What is the remit? Why do we want to use this stuff? What kind of outcome is it going to drive for us?” And that allows us to get beyond this intoxicating speed in which it can generate things.

Sarah B. Nelson: Yeah. It’s interesting too, because I keep thinking when I’m listening to you say that, this we got to do it or we’re going to lose in the market. This comes back to these really fundamental leadership things, that people will get on board if they know why something is happening. There’s, what is the SCARF model from the NeuroLeadership Institute?

Douglas Ferguson: Oh yeah.

Sarah B. Nelson: They talk about when people are threatened, it’s like status… I can’t remember all the ones, but I do remember fairness as one of them. And that for people, if they understand why decisions are made, they’re more likely to accept them. And a lot of the resistance comes from when they don’t know why they were made and it feels like it’s being imposed on top of them. So there’s that kind of, remember the basics of human dynamics of leadership. And I think there’s so much noise in the world. We have organizations that financially benefit from scaring everyone ahead of their IPOs.

Douglas Ferguson: That’s right.

Sarah B. Nelson: And you can see Sam Altman backing off. “Oh, it’s not going to take all the jobs.” It’s like, oh, because the message doesn’t work for you now. So I think people are starting to pay attention to that. But I did want to go back. I saw this morning, Alan Kay from Apple, from the ’80s, if any of the listeners don’t know who he is, he was one of the major folks in Apple in middle ’80s. And he was giving this talk and he was talking about, if you’re digging a hole and you’re looking for gold and you get down three feet and there’s no gold, you have two choices, is that you can dig faster or you can acknowledge you might be digging in the wrong place. And what he was saying was that American business just digs faster. It’s like, “We got to dig faster, get more people in here to dig more. There’s gold down there someplace.” And so I think a little bit about that discipline of going right back to what you said in the beginning, where can you introduce friction, asking people to slow down in order to just say, “Are we doing the right thing?” And then how can we do it better?

Douglas Ferguson: Yeah. And there’s alternatives to digging faster. Is there better instrumentation that might help us know if we’re digging in the right spot, et cetera. And I want to come back to the SCARF just for listeners that may have not have run into it. Status, certainty, autonomy, relatedness, and fairness. And I think the reason I wanted to come back to it is because autonomy is a really interesting thing and certainty are two really interesting things right now, because certainty is something that feels very elusive right now. And I think as leaders, we can acknowledge the fact that there’s a lot that’s uncertain, but what can we make certain? Because if there’s anything that we can make certain, whether that’s our point of view, our posture, the direction we want to go, the strategy we’re going to take, there’s so much unpredictability right now. Anything that we can make more certain and predictable and knowable is going to make the organization more calm, more supportive, more aligned, more understanding. Autonomy is another interesting one because people have this sense of losing autonomy in this new agentic AI-driven world and how they imagine it will even become less and less autonomy. And that’s very frightening for folks. And I think that’s really wrapped up into the identity and I’m going to lose my job and all these things. And what we can do is that if we start to really step back, and this is really why it’s so critical that folks need to adopt multiplayer team-based AI habits versus before they go to the full systemic agentic cross-functional use cases. Because the more that we can map the playing field, understand how we want to use AI together and understand the potential and align that with our vision, and we get to the shared perspective together, then we could start to understand where our autonomy can reside and then we can be very autonomous. People don’t feel autonomous when it feels like their autonomy’s being threatened in all these ways. But if they understand, if they look back and look at the system and go, “Oh, I shouldn’t have autonomy there because of X, Y, and Z, the system is going to function better if I’m not autonomous over here. But look, these are the places where I’m autonomous.” But when people don’t see the system and they don’t see it all mapped out, they don’t even understand where their autonomy resides and then it feels like they have none.

Sarah B. Nelson: Then it feels like they have none. That’s interesting because I always think constraints will set you free, but that clarity of where… Because I think about autonomy a lot as this ownership. I mean, just before AI, just that question of where do I get to make decisions? But I think that I’m just probably just very much emphasizing what you’re saying, but that making clarity of roles, clarity of decision making, all of that discipline that, honestly most corporations struggle with anyway, because we know that those things, when you have clarity of roles, when you have clear goals, when you have good communication and you have a leader who shows up shoulder to shoulder, you have all of those things, then people start to rise to the occasion because you’ve taken a ton of noise out of the system. And I don’t have any… And this is maybe just me complaining, but I don’t have any solution for it, but I just never really understand why speed to somewhere always trumps the just like, “Let’s just put the bricks in place in order for us to be able to go faster.” Because we know that if you do that, you go slower to go faster. The process is… Every time I’ve ever done that it’s like, “Oh yeah, I trust that process.” But I think most people, it’s risky. I don’t know what that’s about, but it’s too hard maybe? I do remember this Zappos, what was it called? Holacracy, this organizational model Holacracy. Does that sound familiar?

Douglas Ferguson: Oh yeah, for sure.

Sarah B. Nelson: It was a guy, came from the agile world and he was thinking about organizations as operating platforms. So the Holacracy was like the operating system for an organization. And then the idea was you didn’t have managers anymore, or a leader, you had a constitution and there were certain kinds of rules of engagement around all kinds of things. And it included things like rules of decision-making, rules of ownership, how certain kinds of meetings were conducted. And Zappos was the largest adoption of it. But one of the things that’s interesting is that we’re so ingrained on these kind of hierarchical ways of doing things, which actually turn out to be easier than trying to do this sort of super flat organization so everyone’s excited, “Oh my gosh, no more managers. I can do what I want.” The work becomes so much harder because now the decision-making is collective and there’s tons of models in the world, like Quakers and things who have collective decision making, but that is not a quick process. That is a slow process. So it’s interesting to me those kinds of the organizational systems and beliefs that people have, and how that then impacts the work that comes out of it.

Douglas Ferguson: Yeah. I think also too, there’s some rhetoric around flat structure and whatnot, but a lot of it is about cost-cutting and savings, not actually trying to build a culture that’s resilient to that. And often I found it’s not just about an unwillingness to go slow, to your point, a lot of the process is low, but it’s an unwillingness to attend to the process that’s necessary to operate in that way. And it’s just a matter of like, “Hey, we want to remove the middle managers or we’re cutting costs or whatever without being attentive to how the organization… What does the system need to look like to support that?”

Sarah B. Nelson: Yeah. I think with AI, the emphasis right now is like, “Oh great, cost efficiency.” First of all, we already know that consumption… With what’s happening with consumption, cost is actually probably not going to be the driving force around this. And to me, it’s like you have to be more creative about thinking, like what can you do? If you take the drudgery out and you take the high production things that are highly manual and you take that out, what does that enable you to do? So to me, it’s about this sort of identify, I don’t want to be businessy, the new sources of value, new things that become possible because you’re no longer consumed with that. In design, over the last few years, there’s been all these small technology advancements that I’ve gotten weepy about multiple times. The first one was the Post-it note, the 3M Post-it note app, that would let you capture Post-it notes and break them up and bring them into whatever program you were using. And then you start to get them with OCR attached to them. And I actually did get a little teary the first time I used that 3M app. And then the next time was that now I’ve got these things into Miro and I just highlighted all of them and asked it to sort it and see what it saw. And what would’ve been a three-day job or a two-day… Because after every workshop, we would sit and type them all in and then we would hand analyze them. And there’s something very valuable… I’m going to put an asterisk there because there’s something really valuable about that too. But there was this other part which was like, this got me pretty close to where I need to be and it did it so now I can focus on where is the unusual insights in here? So then my asterisk is sometimes the unusual insights come from doing the manual work.

Douglas Ferguson: Well, here’s something to think about. This is a really important point and it’s come up a couple times in some of the events we’ve hosted and the work we’re doing to try to understand where we’re headed with this stuff. And one of the new frictions that comes about is, now that the AI is doing a lot of the grunt work and the analysis and things, now then what we might’ve gotten through osmosis by just taking notes or doing the things that we would’ve had to do to be prepared for this all the post-event work or whatever it is, insert your problem. But the ways that you were showing up and the little rituals you had adopted prepared you to then do the final project to be ready for the presentation. And so an example was a designer had adopted a tool that could basically record user interviews, did a bunch of synthesis, did a bunch of analysis, generated an amazing report, but he had to study the report to be able to present it. Normally by the time you’re done making the report, you don’t even need to practice it. It was like you know it in and out, you just present it. Which was interesting, because I wanted to reframe that whole question he was posing because he was saying it’s actually shifting the work to where we need to study the presentation. But I said, actually, this is a design problem. This is analyzing the friction problem and saying, “Hey, how do I need to change my rituals and how I show up in the first place to maybe make it easier? So it’s not about cramming for some presentation. It’s about how I’m using this new tool to learn in a new way versus having to then take its answers at the very end and cram.” So I don’t know, I’m really fascinated by, we can’t just take our old ways of showing up, our old rituals and just jam these tools in. We really need to step back and say, “How are they materially changing how we need to show up?”

Sarah B. Nelson: Yeah, I 100% agree. The words that keep coming up for me are data intimacy. I don’t know. It popped into my head one day. I’m sure somebody smarter than me said it someplace, but there’s that idea of how well you know something. I mean, for me, when we would do mental models of complex workflows, I know that workflow. I could still talk about it because I have visceral stories that we captured from people, and spending time really manually with that data. So I know a lot. There was some stuff that was like… The flip is, is that sometimes you spend a lot of time on it and you only get to the stuff everybody would know anyway. So you don’t get any place in particular. But one thing that, there was someone, I listen to millions of things, but was talking about when you need to really learn something and change your thinking, you need to make yourself go slow and pull out the book, sit with the book, read the book, and munge at that information because that is when your brain is making connections. And so it’s sort of knowing about when you need to summarize something and when you need to actually spend time with it. And I think everyone’s kind of going like, “Oh my gosh, we can summarize everything.” And I think it’s, to your point, finding what are new things we need to do to make sure we retain the things that are really meaningful and useful.

Douglas Ferguson: Yeah. And also even if we’re using to summarize, what are the signals that we should identify ahead of time so that when we see them, we know to slow down, to do the deeper look, to say, “Hey, there’s something new to learn here.” Because frankly, people are using this stuff all the time to create rapid synthesis, to do a lot of grunt work, to use that other word. I think we have to invent some new signals, some new ways of looking at this stuff so that we know when, hey, this is a moment to dive a little deeper, to ask some other questions.

Sarah B. Nelson: Yeah, interesting. I think because it’s also thinking about the recipients of this. So recipients of reports, it’s always like… That’s often the thing is they read them, it’s hard to internalize, they get some information out of it. It’s not internalized. So there’s also probably the question of, and now we’ve got both sides not internalizing it, but maybe this is also the opportunity to have both sides do some more internalizing too. It goes from reports to ways of using the information from the reports in some way, that that’s how we experience the outputs. I don’t know. I’m just thinking off the top of my head.

Douglas Ferguson: Yeah, no, I love that. And also it makes me think too, we need to be intentional about how we break the cycles because when it’s my agent sending your agent an email, then your agent replying to that email, at which point is something real happening versus things just getting thrown around. It reminds me of this cartoon, it’s like self-driving cars were starting to become a conversation some years back and the cartoon was these two cars, and one of them kind of looked like a police car and the policeman’s standing out in front of the first car and he’s saying, “Does your car know why my car pulled you over?”

Sarah B. Nelson: Yes, that.

Douglas Ferguson: Yes, I think we need to… That’s something to contemplate as we’re building these systems, right?

Sarah B. Nelson: Yeah. Yeah, for sure. Yeah, for sure. I think maybe that’s just one of the most important things is just being able to… You’ve got to check yourself for when you go into automatic. I mean, I think about this a lot. I’m working on something and I’m like, am I conditioning myself to just go ask, have a conversation with Claude about it, where I would’ve talked to a human about it, or I would’ve gone an written about it and then evaluated it myself. So I’m thinking about those things, like where now I have to have some interventions on myself about when, no, actually you need to go back to what you know how to do, which is, you need to write about this or draw about it, or do some other mode that isn’t having a chat with something that may just be blowing sunshine up your butt. You know what I mean?

Douglas Ferguson: Yeah, yeah.

Sarah B. Nelson: And there are times that I sometimes think, am I actually getting… I don’t want to lose the muscles, but am I kind of in a reflection anyway? Am I already in a mirrored room? And so maybe working on my own and writing, I could probably do the same or better anyway. So it’s an interesting… I guess the main thing is to really stay self-reflective. I feel like that’s the name of the game right now. It’s like what’s happening? What’s happening to me? What’s happening to others around me? Is this better work or worse work or different work, or, yeah.

Douglas Ferguson: Yeah, I think that’s why we feel that this framing around friction’s important because are we taking note of where the friction points are? Which ones are good friction? So we’re intentionally slowing down, which ones that we might want to repair or lean into to redesign around. And so it’s introducing a little slowness, a little contemplation, reflection, back to what you were saying. But yeah, I think we just have to stay aware and attuned versus just falling into this kind of automated soup.

Sarah B. Nelson: Yeah.

Douglas Ferguson: So five years out, what’s the friction we’ll wish we hadn’t removed?

Sarah B. Nelson: Five years out. It’s hard to even imagine five years out. If things go wrong, it’s imagination. I actually think it’s time for imagination. That would be the thing I think would be the worst thing that we would lose because imagination is the thing that, I think that is something that humans uniquely do. I think, okay, whatever, never say never, but I think it’s like we’ll have all of this information and we have all these possibilities, but if people can’t think of creative ways to use it or doing like what we’re doing in this moment, of like, what does the future look like? What could it be? We don’t ask those questions anymore. I mean, I don’t know what we’re doing. I think I just imagine this sort of spiraling or flatness, or things don’t change or… I don’t know, but imagination to me feels like a keystone.

Douglas Ferguson: Yeah. It’s interesting too that you reach for imagination as an example of friction. And I think it is something that a lot of organizations try to lubricate out of the system. It’s like, “Hey, let’s not stop and worry about that. Who needs daydreaming or whatever? You need to be more professional.”

Sarah B. Nelson: That’s for children and artists, and they’re all silly people. Yeah, absolutely, because it’s amorphous, it’s threatening, it feels like guessing. It goes against this sort of belief that we can rationalize everything out. We can put it all on the spreadsheets and add it up and organize it, and make diagrams about it. It’s much harder. It’s much harder because it’s more subjective. There’s a lot more risk involved in all kinds of ways. But none of this exists without someone imagining it. I mean, some of it obviously comes out of needs, but even that, it’s the, like what is the problem we need to solve here? I mean, it’s like dumb stuff. How do I make it easier to light my candles? It’s like somebody said, “Oh, that’s imagination too.” So I guess that’s the thing that I think is the most precious thing to hold onto.

Douglas Ferguson: Yeah. It’s easy to note that, imagine has image in it and it’s conceptually bound to this idea of visualizing things and sketching and drawing and having vision. And I think that’s very strategic, and it’s unfortunate that’s not part of how most people define and capture strategy. And I would argue if you look at a… In fact, we just did a webinar last week and I talked about how we all know a photo’s worth a thousand words, and then [inaudible 00:45:23] Law said that a prototype’s worth a thousand meetings. Well, I’m now saying that a visual specification is worth a thousand prompts because text prompts are linear. And if we visually build up and imagine together what the future could be, the AI is going to be a lot more aligned with how we’re imagining and perceiving the future. And I think that’s a beautiful way to think about working with these tools when we start to work collaboratively.

Sarah B. Nelson: Yes. Yeah. I’ve been really impressed with how some of these models are dealing with visuals. I don’t mean creating them, I mean being able to interpret them in all kinds of ways. I’ve actually given it paintings of mine and I’ve been shocked at the critique I’ve gotten back from it.

Douglas Ferguson: Yeah. You mentioned stopping the sketch versus consulting with the AI. Have you experimented with sketching first and then given the AI the sketch?

Sarah B. Nelson: No, but I’m going to.

Douglas Ferguson: It’s pretty fun. In fact, it’s really fun to do a really loose sketch where you’re just like, you’re not even worrying about how understandable it is. It’s not for any other human’s consumption. So you can just flow and go wherever you want to go and then get in a conversation with it, and it’s really fun because you’re unlocking parts of your brain that maybe wouldn’t have just gone into language. Then it’s really good at being able to extract things. It is a fun use case.

Sarah B. Nelson: All right. Well, because I actually have a diagram. I was like, I need to go get a big giant piece of paper and actually draw this whole system out. And the idea that I don’t have to have it for another person but myself and AI is like, that’s awesome because it takes so much work.

Douglas Ferguson: Yeah, exactly. And also I’ve found too sometimes that it’s not quite a critique, it’s almost like just a dialogue around, hey, what’s here? What are we emerging? It’s kind of almost emergent meaning that can be fun to extract with it. Because it’s really, at the end of the day, I’m nudging and prompting, and it’s just reflecting back some things. So it’s almost like a fun way of trying to drill deeper than I might’ve gone on my own self-reflection.

Sarah B. Nelson: Yeah. Oh, interesting. Okay. Well, I have a project for this afternoon then.

Douglas Ferguson: Fun, fun.

Sarah B. Nelson: Nice. Nice.

Douglas Ferguson: So I think this is a good time to maybe hit the pause on this conversation. So I want to invite you to leave our listeners with a final thought.

Sarah B. Nelson: Yeah. So the thing that’s been just rattling around in my brain on a daily basis is this quote from Buckminster Fuller, which is, “We’re called to be architects of the future, not victims of it.” And it’s hit me really hard because I think that’s the hope that I have for all of us, is that we do actually have autonomy. We do actually have the ability to use our imaginations to bring a new future in. We’re not locked into the one that’s being sold to us right now. And by attending to the moments that we’re in and building towards the thing we actually want it to be, I think we have a lot of power to do that. So that would be what I would encourage people, is to look for the power that you have to bring the future that you believe needs to happen into life.

Douglas Ferguson: Incredible. Well, thanks for joining me, Sarah. It’s been a lovely conversation. Looking forward to our next.

Sarah B. Nelson: Awesome. Thank you so much. Great conversation.

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 Readiness Is A Behavioral Transformation, Not A Technical One appeared first on Voltage Control.

Why Your AI Case Studies Aren’t Working

Your organization has done the work. You have accuracy benchmarks, SLA guarantees, pilot results, case studies with named clients and documented ROI. Your vendor has third-party audits. Your legal team reviewed the data handling. Your IT team certified the security posture. And your employees still are not using it. This is not a failure of evidence. It is a category error. You have been building trustworthiness. You needed to be building trust. These are not the same thing, and conflating them is why most enterprise AI adoption efforts stall at exactly the moment they should be accelerating.

Trustworthiness Is About the System. Trust Is About the Person.

Trustworthiness is what the evidence shows: accuracy rates, compliance certifications, SLAs, pilot results, and audit trails. It is an attribute of the AI system itself. You can measure it, document it, and present it in a deck. Trust is different. Trust is a psychological act that happens inside a person. It is the moment someone decides to rely on something they cannot fully verify. And that decision is not primarily driven by evidence. It is driven by experience, context, identity, and social proof from people they respect. The distinction matters because the interventions are completely different. Loading more evidence into your adoption campaign, another case study, another ROI breakdown, another compliance badge, does not move the needle on trust if the underlying psychological conditions are not met. You are solving for trustworthiness while employees are asking a different question. The question is not “Is this AI trustworthy?” The question is “Do I trust this AI, here, in my role, for this kind of work?”

The Robotaxi Paradox

Here is the pattern that reveals this most clearly. A knowledge worker who hails a robotaxi and lets software navigate them through city traffic at 40 miles per hour is the same person who refuses to accept a Copilot-generated first draft without rewriting it from scratch. Objectively, the stakes do not compare. A robotaxi error could injure them. A hallucinated summary wastes fifteen minutes. But their trust behavior inverts what the evidence would predict. Why? Because the psychological conditions are entirely different. With the robotaxi, the role boundaries are clear. The car drives; they sit. The system is visibly working in real time. Social proof from colleagues who have used it accumulates passively. And critically, their professional credibility is not on the line. If the robotaxi takes an odd turn, they observe it. They do not own it. With Copilot, everything changes. The output lands in their document, under their name, in their domain of expertise. If the summary is wrong and they forward it, that is their error. The AI did not fail. They failed to catch the AI failing. Their reputation as someone who knows their material is at stake in a way it simply is not when they are a passenger. Trustworthiness is similar across both systems, or arguably higher for Copilot given its output transparency and audit trail. Trust diverges completely because the psychological stakes differ. This is not irrational. This is exactly how trust works. The lesson for AI leaders is specific: the trust gap your employees have with enterprise AI is not primarily about the model. It is about the context in which they use it and what failure costs them professionally. An employee who trusts AI to help draft internal updates may not trust the same AI to help draft client recommendations, even if the capability is identical. The context changes the psychological stakes. The psychological stakes change the trust response. Treating both contexts as equivalent, and responding to the skepticism in the second context with more evidence from the first, is the mistake most adoption programs make.

Why More Evidence Backfires

The conventional response to adoption resistance is to produce more evidence of trustworthiness. Refine the accuracy stats. Commission an independent audit. Write up a case study from a similar organization. Schedule a lunch-and-learn to walk through how the model works. This is understandable. It is also almost always wrong. Craig Roth at Gartner’s Digital Workplace Summit named what actually happens: organizations deploy AI rapidly, loading employees with technical information about the system, and create trust deficits precisely because speed and data-loading leave no room for the gradual, experience-based trust-building that works. Speed is a trust deficit. Evidence is not trust. Research on what actually drives psychological trust identifies three factors: perceived ability (can the system do what it claims?), benevolence (does it act in the user’s interest?), and integrity (does it behave consistently and honestly?). Evidence addresses ability. It barely touches benevolence and integrity, which are primarily established through direct experience, not documentation. Worse, detailed technical explanations often activate a risk mindset rather than a trust mindset. Walking through the training data surfaces concerns about bias. Explaining confidence intervals surfaces concerns about accuracy in edge cases. Describing the audit methodology surfaces questions about what the audit did not cover. You have made the system more transparent, which improves trustworthiness. You have also made the failure modes more vivid, which suppresses trust. The information is accurate. The effect is the opposite of what you intended. This is the core tension: the moves that build trustworthiness and the moves that build trust operate through different mechanisms. Most organizations invest heavily in the former and wonder why it does not produce the latter.

What Actually Builds Trust

Trust in AI builds the same way trust in anything builds: through repeated exposure, positive experience, social modeling, and calibrated stakes.

Small starts, visible wins.

The organizations seeing genuine AI traction are not the ones who launched enterprise-wide mandates backed by polished training programs. They ran tight pilots in one team, let people experiment with low-stakes tasks, and let word of mouth carry the initial momentum. When someone uses AI to draft a rough first cut of a weekly update and it saves them an hour, they tell people. That conversation transfers more trust than any case study. You cannot engineer the conversation directly, but you can create the conditions for it: start small, start where the AI clearly succeeds, and give people room to discover it themselves.

Top-down permission, bottom-up testimonials.

Both matter, and they serve different functions. Leadership commitment, when an executive uses AI visibly in their own work and says so, creates permission. It signals that experimentation is safe and that the organization values the output even when it is imperfect. Bottom-up testimonials from actual practitioners, not trainers or IT leads but respected domain experts who talk about specific ways AI helped them, create desire. They answer the question employees are actually asking: “Does this work for someone like me?” Top-down without bottom-up is a mandate. Bottom-up without top-down is shadow AI, happening outside governance, invisible to the organization and to any accumulated trust benefit. You need both.

Sequence use cases to build a track record.

Not all AI use cases carry the same trust-building or trust-destroying potential. A rough first draft on an internal update is low stakes and often succeeds visibly. A client-facing analysis output is high stakes and will be scrutinized in ways that compound skepticism if it fails. The sequencing of early experiences matters enormously. Start where the AI succeeds clearly, with work that is iterative and internal, where recovery from error is easy and the user stays in control. The trust you build in those contexts transfers to harder ones. The distrust from an early public failure also transfers, and it spreads faster.

Address the identity question directly.

This is the piece most adoption strategies miss entirely. Knowledge work AI almost always has professional identity stakes embedded in it. Am I still the expert if the AI writes the first draft? Am I still the analyst if the AI runs the summary? Am I still the strategist if the AI builds the framework? These questions are not irrational objections to be overcome. They are prior to the trustworthiness question. Answering “yes, the model is 94% accurate” does not address “yes, you are still the expert.” The leaders building AI fluency that holds are addressing this directly. Not by reassuring people that their jobs are safe, which most people do not believe, but by making the new shape of expertise visible. Directing a tool well is a skill. Editing a first draft to a high standard is a skill. Knowing when to override the output is a skill. Recognizing what the AI missed requires knowing your domain deeply. The expert who uses AI well is more capable, not less. Making this visible and valued is not an HR exercise. It is a trust-building move.

What to Stop Doing

If you have an adoption problem, the instinct is to add more proof. Resist it. Ask instead what is driving the psychological conditions that make trust difficult. The answers are usually specific. If employees feel AI is happening to them rather than with them, involving them in defining what good output looks like makes a material difference. People trust systems they helped shape more than systems deployed at them. Letting practitioners set the quality bar for what AI-assisted work needs to meet is not a political gesture. It changes how they relate to the system. They will defend the standard they set. If the social modeling in your organization is skeptical, one champion in the right position is worth more than a hundred case studies. Not a trainer. Not an IT lead. A respected domain expert who uses AI openly and talks about what it changed for them. Their credibility transfers to the tool. If you are building the business case around accuracy stats and ROI figures, understand that you are building a trustworthiness case. That case needs to be made to procurement, to legal, to the board. It is not the case employees need. The case employees need is not about whether the AI is reliable. It is about whether they can rely on it, in their context, for their work, in a way that protects their credibility rather than threatening it.

The Real Work

Trustworthiness is table stakes. It gets you through the governance gate and into the pilot. Trust is what gets you to adoption. Adoption is where the value is. The organizations that figure this out are not producing better case studies. They are building different conditions: room to experiment without professional exposure, social proof from real practitioners, early use cases where success is obvious, and an explicit reframing of what expertise looks like when AI is in the room. The ones that do not will keep wondering why employees who nodded through the AI launch presentation still open a blank document and start typing. If you are working through this in your organization and want to talk about where you are stuck, the gap between trustworthiness and trust is usually where the most interesting questions live. Start that conversation here.

The post Trustworthiness Is Not Trust appeared first on Voltage Control.

The design thinking process is a 5-step human-centered framework for solving complex problems: Empathize, Define, Ideate, Prototype, and Test. Each step is designed to reduce assumptions, surface real user needs, and produce solutions that work in practice rather than just on paper.  

79% of companies report that design thinking improves their ideation process, and 71% have seen a significant shift in work culture after adoption, according to the Design Management Institute’s research. The process is not limited to designers: product teams, operations leaders, healthcare administrators, and cross-functional groups working through AI adoption all use it to address high-stakes, human-dependent problems where the right question matters as much as the right answer.  

This guide walks through all five steps in sequence, with practical notes on what each step produces, the most common mistakes practitioners make at each stage, and how the process applies to AI adoption programs where the human-centered foundation matters most.

What is the Design Thinking Process?

Design thinking is a process for creative problem-solving that helps teams move past the first good ideas and discover creative solutions. Rather than a one-shoe-fits-all mindset, the approach encourages a holistic view where uncertainty and ambiguity are welcomed and embraced so a team can consider all sides of a problem. A design mindset can be applied to any organizational challenge, including how to introduce AI into a team without breaking the trust and rhythm that already works.

The method is steeped in a deep belief that the end-user should be at the heart of every decision. The benefit of design thinking is that, through empathy for your customer, employee, or partner, you create products, processes, and adoption strategies that truly help people. That same empathy is what separates AI adoption that lands from AI adoption that stalls.

In this article, we will explore the five-step process that enables teams to come up with impactful solutions to real problems, vetted by the people they intend to serve before they have even been built. These key steps launch you into an innovative and experimental approach, whether you are designing a new product or rolling AI into the daily work of a 200-person team.

Pro-tip: use our Liberating Structures templates to get the most out of the design-thinking process with your team. At Voltage Control we also love to use the Workshop Design Canvas.

The 5-Step Design Thinking Process

1. Empathize 

The first stage of the design process is to develop a deep understanding of the people affected and their unique perspective so you can identify and address the right problem. To do this, design thinkers cast aside assumptions about the problem, the people involved, and the world around them (because assumptions can stifle innovation). This allows them to consider all possibilities about the people they serve and their needs. In 2026, this step is supercharged by AI sentiment analysis, which helps teams process thousands of user interviews and global trends in seconds to find hidden patterns. The team still has to choose what matters.

Typical Activities

• Observations: You go where your users go and see what they care about.
• Qualitative Interviews: You hold one-on-one interviews with a handful of users to understand their attitudes on the topic you are exploring. Asking someone to tell a story about the last time they experienced the problem you are investigating provides a rich description that highlights details you might not have otherwise considered. Use our Interview Observation template to interview someone close to the problem you are working on.
• AI-Enhanced Synthesis: Use large language models to summarize key pain points from massive data sets while preserving the human signal. This is the same pattern we use when running AI readiness assessments inside organizations: machines surface scale, people choose meaning.
• Immersions: Step into the user’s day-to-day so you can feel and experience it.

Immersions: Step into your user’s shoes so you can feel and experience their day-to-day.

Tools like empathy maps consolidate the valuable information gleaned from interviews. Empathy maps capture what people do, say, think, and feel in the context of the problem. They help colleagues understand the context and how people experience it.

2. Define

Pull together the information gathered while empathizing. The next step is to define the problem statement clearly. The ideal problem statement is captured from the perspective of human-centered needs rather than business goals. For example, instead of setting a goal to increase signups by 5%, a human-centered target would be to help busy parents provide healthy food for their families. When the problem is AI adoption, the same rule applies: instead of “roll out the AI tool to 200 people,” define “help mid-level managers feel confident enough with AI to use it for the work they already own.”

Based on the frustrations you observed or heard about, generate questions for how you might solve them.

Typical Activities

• Clustering and Themes: There are many ways to do the Define phase, but most include a wall of sticky notes filled with quotes, observations, and ideas from your research. Group and cluster ideas until you find the prevailing themes.
• Problem Statement: Take time to properly articulate the problem statement. Answer the questions: What is the problem? Who has the problem? Where is the problem? Why does it matter?

As you explore empathy data, focus on identifying patterns and problems across a diverse group of people. Gathering information on how people are currently attempting to solve the problem and how they explore alternatives provides clues to underlying root problems.

You cannot solve every problem your users face. Identify the most significant or painful issues to focus on as you move forward.

3. Ideate

Now that the problem is clear, it is time to brainstorm. Today’s teams often use AI co-creators during brainstorming sessions to push past obvious answers and spark concepts that the room would not have reached alone.

Typical Activities

• Brainstorming: Brainstorming is a critical part of the ideation phase. It generates a wide variety of ideas, all aimed at addressing the problem or challenge at hand. It allows the entire team to bring their perspectives, experiences, and insights, fostering diversity and richness in idea generation. Ideas shared can serve as stepping stones to innovative, out-of-the-box solutions.
• Worst Possible Idea: The “Worst Possible Idea” activity may seem counterproductive, but it encourages creativity and eliminates psychological holdups that stall innovative thinking. It allows team members to brainstorm and share their worst ideas without fear of judgment or criticism. Identifying why an idea is the worst can help in understanding the parameters and constraints of a problem.

The ideation stage marks the transition from identifying problems to exploring solutions. It flows between idea generation and evaluation, but it is important that each remains separate.

When it is time to generate ideas, do so quickly without focusing on quality or feasibility. Ideation techniques prioritize quantity over quality so you can move past the first good ideas and find the truly novel ones. Only after you have exhausted idea generation do you move on to evaluate.

The ideation phase is usually a creative and freeing phase because the team has permission to think out-of-the-box before deciding what to prototype.

4. Prototype

It is time to experiment. Through trial and error, your team identifies which of the possible solutions can best solve the identified problem. This typically includes scaled-down versions of a finished product or system, so you can present and get feedback from the people they are intended to serve.

Typical Activities

• Create a Vision Board: This visual representation of ideas, inspirations, and intended outcomes allows team members to envision the desired final product. The vision board is a shared reference point for the whole team. It facilitates communication, aligns understanding, and encourages creative problem-solving.
• Rapid Prototyping: The aim of rapid prototyping is to create low-cost, scaled-down versions of the product or specific features quickly for initial testing. Use paper, sticky notes, cardboard, or digital mockup tools. Use our Take 5 template when you want to collect diverse ideas from the entire room.

With the advent of generative tools, the gap between a paper prototype and a functional mockup has shrunk. It is now possible to use generative design and no-code tools to build interactive models in hours rather than weeks. The same is true for AI adoption pilots: a “prototype” can be a single team running a constrained AI workflow for two weeks before any larger rollout.

The goal is to start with a low-fidelity version of the intended solution and improve it over time based on feedback. Begin with a paper prototype to learn quickly with minimal effort. The prototype should be a realistic representation of the solution that allows you to gain an understanding of what works and what does not. It is changed and updated based on feedback from the Test phase in an iterative process.

5. Test

The prototype is at the center of the final phase as we put all our ideas to the test. The testing phase is part of an interactive cycle. You will have the opportunity to hear from your users again, just as you did in the Empathize phase. User testing is critical to understand how your audience will react to the ideas in your prototype and how desirable that experience will be.

• Observational Testing: Real users interact with the final prototype in a controlled setting while the design team observes their behavior and responses. The goal is not just to confirm whether the solution works as intended but to gain deeper insights into how the user interacts with it, how they approach the problem the product is meant to solve, and where difficulties or confusion arise.
• Iterative Testing: This process uses the results of initial testing to make improvements, and then tests again. Use our 5 Act Interview Cheat Sheet to build the right team for the project.

Testing with real users is essential because everything is ultimately about the people who will use your products. After you collect insights, revisit the problem statement and reflect on how well the prototype is meeting needs and resolving frustrations.

In 2026, teams often perform hybrid testing, combining real-world user interaction with data-driven simulations to predict long-term behavior.

Applying these five steps to AI transformation? The same shape works: empathize with the people whose work is changing, define the human problem before the AI use case, ideate with the team in the room, prototype with one constrained pilot, test with the people doing the work. Read more in Adopting AI-Driven Change Management or explore the AI Transformation Program.

Design Thinking in the Age of AI

The five-step shape has not changed. The work inside each step has. Three shifts matter most for leaders running AI transformations:

• Hyper-iteration: The line between steps is blurrier than ever. Because prototyping is now fast, teams jump between Testing and Empathizing in a single afternoon, creating a live feedback loop that was impossible a few years ago.
• AI as a collaborator, not a tool: AI is now part of the room, not a feature you reach for. From analyzing empathy maps to generating prototype code, AI lets design thinkers focus on high-level strategy and emotional intelligence. The judgment about what is meaningful still belongs to the team.
• People-first adoption: Most AI initiatives fail at the human layer, not the technical layer. Design thinking gives leaders a way to move from “we deployed the tool” to “the team actually uses it.” That is the New Friction we keep seeing across enterprise AI rollouts, and it is the reason design thinking is having a second moment.

Our tools and timelines have evolved. The target has not: meaningful impact through a deep understanding of human needs.

Putting the 5 steps to work.

Design thinking is not a poster on the wall. It is a way of moving through a problem with other people. The teams that get the most out of it have someone in the room whose job is to hold the process so everyone else can hold the problem.

If you are using design thinking to drive AI transformation, our AI Transformation Program is built on the same five-step shape, applied to the specific friction of getting AI adopted across a team or org. If you want your own people to be the ones holding the process, the Voltage Control Facilitation Certification is where leaders learn to do that work.

Need an expert facilitator for your next meeting, gathering, or workshop? Let’s talk

FAQs

• What are the 5 steps of the design thinking process?

The five steps are Empathize, Define, Ideate, Prototype, and Test. Empathize involves research into the people affected by the problem. Define synthesizes that research into a clear problem statement. Ideate generates solution options. Prototype builds a low-fidelity version to test assumptions. Test puts the prototype in front of real users and surfaces what to refine.

• How long does the design thinking process take?

It depends on scope. A focused design sprint can run the full 5-step cycle in 3-5 days. A complex organizational challenge might take 6-12 weeks. The process is iterative rather than linear, so teams often return to earlier steps as they learn more.

• What is the difference between design thinking and agile?

Design thinking is a problem-framing methodology focused on understanding users and defining the right problem. Agile is a delivery methodology for building and shipping solutions iteratively. They are complementary: design thinking informs what to build, agile governs how to build it.

• Can design thinking be applied to AI implementation?

Yes. Design thinking is particularly valuable in AI implementation because AI projects fail most often at the human-adoption stage rather than the technical stage. Empathize and Define help teams identify which problems AI should solve. Prototype and Test help validate AI tools before organization-wide rollout, reducing the risk of adoption failure.

• What is the most important step in design thinking?

Most practitioners cite Empathize as foundational because every subsequent step depends on how accurately you understand the people affected by the problem. Skipping or rushing this step typically produces well-built solutions to the wrong problem. That said, Define is where many teams fail in practice: translating research into a problem statement that is specific enough to generate useful ideas.

The post 5 Steps of the Design Thinking Process: A Step-by-Step Guide appeared first on Voltage Control.

In this episode of the New Friction podcast, host Douglas Ferguson speaks with Peter Bell, founder of Gather.dev and author of the forthcoming O’Reilly book Scaling AI Adoption in Engineering. Bell draws on his work running invite-only peer communities for senior engineering leaders to diagnose why most organizations stall out in AI pilot mode rather than achieving meaningful transformation. The conversation maps three distinct patterns of engineer resistance—skeptics burned by early models, craft-focused developers who resist the shift toward managing agents, and those with principled objections to AI—and offers concrete tactics for reaching each group. Bell and Ferguson explore how AI amplifies existing organizational health: strong DevOps practices compound upward while process debt scales its dysfunction. They examine the mandate trap, measurement via token usage as a diagnostic rather than a performance metric, and the non-negotiable role of psychological safety in any serious adoption effort. The episode closes with Bell’s call for engineering leaders to build hands-on with current models, arguing that firsthand intuition—not secondhand reports from a VP of AI—is what this transition demands.

Show Highlights

[00:00:00] Introduction to New Friction
[00:01:30] Peter Bell on Agentic AI and His O’Reilly Book
[00:04:30] Three Patterns of Engineer Resistance
[00:09:00] Encoding Craft and Taste Into AI Quality
[00:14:30] Delegation Skills and the Agent-Manager Mindset
[00:19:00] Harness Engineers and Developer Experience
[00:26:30] Psychological Safety and Blameless Postmortems
[00:33:00] The Mandate Trap and Measuring Adoption
[00:42:00] Token Economics and Rebuilding the SDLC

Links | Resources

Peter Bell on LinkedIn
Gather.dev
Scaling AI Adoption in Engineering (O’Reilly)
The Future of the Engineering Org (Substack)
Voltage Control

About the Guest

Peter Bell is the founder of Gather.dev, an invite-only peer community for senior engineering leaders navigating what he calls the agentic transition. He is writing Scaling AI Adoption in Engineering: A Leader’s Guide to Driving Alignment, Adoption and Impact for O’Reilly, and publishes The Future of the Engineering Org on Substack. Bell previously served as SVP of Engineering at General Assembly and built Flatiron School’s engineering team to 50 people in 18 months. He hosts the O’Reilly CTO Hour and facilitates CNCF Executive Summits at KubeCon, and is actively building his own multi-agent orchestration systems—keeping him well outside pure pundit territory.

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. I’d like to introduce you to my conversation partner today, Peter Bell. Welcome to the show, Peter.

Peter Bell: Douglas, thank you so much for having me. I’m excited to be here and to kind of have this conversation.

Douglas Ferguson: Absolutely. And we’ve been in conversation a lot over the years and it’s been a lot of fun recently diving back into this new era of hosting conversations around what matters for leaders.

Peter Bell: Absolutely. Well, I’ve really been getting into how agentic AI is transforming the SDLC, the software development lifecycle. I’m writing a book for O’Reilly called Scaling AI Adoption and Engineering, which is like the hard part’s like, “I got 300 humans. How do I get them to work and be different?” And then, I’ve also been doing a lot of builder work myself. I’ve built my own harness and dreaming systems and orchestrators and tools like that. And it’s been really fascinating just to see the impact of this both on a personal level and also at the larger organizations where I’m discussing with the CTOs how this is impacting their teams and their priorities.

Douglas Ferguson: Yeah. I’ve been along on that ride. I’m building some of my own stuff and we’ve been comparing notes. And personally, I’ve found it illuminating to dream about the future a bit more, being able to get hands-on and making some things that are useful for me, and then I can more easily see how this is impacting organizations.

Peter Bell: One of the really interesting things has been fundamentally the model’s changed in mid-November of last year. You got like four, five, you got… I’m forgetting now, the version of Codex. It was at 5.2, 5.3. And what’s really interesting is I’ve found that there is a absolute divide between two types of engineer and leaders. There are the people who have taken a day to go build anything in Claude Code or something similar since then, and there are people who haven’t. The people who haven’t are still like, “Man, I’ve got a VP of AI. They’ll take care of this stuff or my platform team will figure it out.” And the ones who have done are like, “Wait, we need to call an all hands. We are not going to be writing code in a year and we need to ready the organization for our new future.” So I feel like if you’re not doing this, this is one of the few transitions as a leader where you can’t just manage and lead through it because your intuitions are going to be wrong.

Douglas Ferguson: Yeah, that’s an important point. It’s funny, not only have I seen it from leaders, but I’ve also seen leaders really struggling to bring some of their engineers or just any talent along because the talent, the individual has made an impression of what AI is based on earlier versions of the model. You were kind of touching on that a little bit, but I think it’s really important to really sit there for a moment because it’s an important thing to wrestle when you’ve got folks that have made a determination about what a thing is, but it’s evolved tenfold over.

Peter Bell: Well, I feel like there are three broad patterns of pushback and we’re seeing this in everything from juniors to some of the most senior engineers, product leaders across the board. One is, “I tried it last summer and it sucks. I can do faster.” So they just need to try it again. That’s manageable. Another is, “I understand that this works, but this is now not the job I want. I love being the person who goes on Stack Overflow and figures out just where the semicolon should be. I love the crossword puzzle nature of designing an elegant API. I don’t want to be babysitting a bunch of agents.” That’s hard because the job has changed and artisanal software development, I would be surprised if that’s a real profession for most people in the field a small number of years from now. And then, the third is, “AI is bad. It’s going to world apocalypse, destroy the population, destroy the planet, climate impact.” And there are lots of very valid reasons to have an issue with AI. At the same time, it’s here. I don’t expect it to be going away anytime soon. And so the question is as a leader and with responsibility to shareholders, you need to help the people within your team to build the outcomes you need, and not everyone’s going to self-select into that population.

Douglas Ferguson: Yeah. I’d love to dive into those three a little bit more deeply. And maybe let’s start with the I-want-to-be-a-coder category. That’s just my quick little name there for that. But I’ve seen two versions of this. And so I’d be curious if you’ve seen other layers or variants as well, but this notion of people being in love with the craft and being passionate about the craft. And the interesting thing about them is that you can actually use that as a value or as something to lean into to help them explore and experiment with using AI because you can say, “Well, how can we evolve the craft? What does the craft look like when we bring in these new tools? And if the craft is really about quality, what are the principles baked into the craft rather than the practices?” You know?

Peter Bell: Mm-hmm.

Douglas Ferguson: This comes back to the agile days when say they were doing agile because they were doing story points or user stories, but they weren’t really practicing the values or living up to the principles. And so it’s like helping people distill down their craft into principles that then they can apply in the AI world. I think that’s really fascinating.

Peter Bell: I’ve seen a couple of approaches that you’ve absolutely nailed it. One approach is the, “Oh, you don’t believe AI code is any good.” Great. What I want you to do is review all of it and tell us how bad it sucks. And that effectively, firstly, it means you don’t ship crappy AI-generated slop, which is wonderful. And secondly, it means that you get a training corpus that means that the AI stops generating slop in general if you implemented it well and manage your context and deterministic quality gates and adversarial multi-step reviews. I mean, you need to engineer this correctly, but what it allows you to do is it allows that person to say, “AI code sucks,” and for the business to get better by then being precise about how and where it sucks, which then improves the quality of generation. And then, I think the other point, the one that you doubled down on, which I love, is this idea of saying, “We’re effectively moving up another layer.” It’s we can now take infinite pains for these things. You really think that we need to have thoughtfully orthogonally designed names. We need to think about like Eric Evans, domain-driven designs and ubiquitous languages and rich domain boundaries. We can do all that stuff, but rather than doing it, what we’re going to do is teach an agent to care about it and then ensure that we have a review step to make sure that the quality of our architecture is better than we’d probably have time to ship if we’re doing it manually. So yeah, it’s absolutely true that we get to encode taste, which is actually an amazing way to improve the quality, not just of the software you write, but of all the software that is then written by the factory that you’re helping to train.

Douglas Ferguson: Yeah. I mean, there’s kind of no end to the depth that you can go into if you really explore with these new capabilities unlocked from a perspective of craft because you look at test-driven development, that’s something that everyone kind of aspired to, but how many people actually did it? This is a thing that where you can instantaneously have tests if you have well-defined boundaries and well-understood contracts and you can get them for free now. You don’t have to spend the time. And I think it really could put us in a position where we’re being more thoughtful, more mindful about our design processes and things that we might have spent more time designing if we had the time in the past. And also kind of pulling on that thread more, something I’ve seen be really effective for organizations is where if folks are really pushing back and saying like, “I can write better code,” or, “I don’t trust this thing,” have it start doing the code reviews. Ideally in an autonomous fashion, sure, still have human code reviews, but have the humans look at what the AI is discovering as far as the bugs and issues and concerns. And when you’ve got senior engineers where the AI is discovering bugs in their code, it starts chipping on the ego a little bit and they start to realize, “Wow, this thing is actually pointing out things I should have noticed,” and they start to give it a little bit more credit.

Peter Bell: Absolutely. And I think it goes both ways. I think that you get value from the humans reviewing the AI code because it improves as long as you are capturing the context, capturing the transcripts, and feeding them into a well-designed context management system. And then, absolutely, I think we’re going… It’s bizarre, but it feels a little bit like self-driving cars in a couple of ways. In the one way, it’s really hard to get a hundred percent of the way there. Anyone who’s like, “Dude, I just switched on Claude Code and now we’re generating production-ready code,” is either doesn’t know what production-ready code is or hasn’t looked at the code they’re generating. You can absolutely one-shot or few-shot stuff, but it’s a real engineering effort at least today to ensure that it is of the quality and maintainability you’d want. So it’s hard to get all the way. But the other thing is eventually, people are going to think 20 years from now, the idea like, “Wait, Granddad, they used to let humans drive? I mean, how did that work? Didn’t they get drunk and look at their cell phones and kill people?” Isn’t it much safer to use Waymos?” And I feel like we’re going to have exactly the same with writing code by hand, which is, “So wait a minute, in a mythos-level environment where you can get CVEs coming in and they maybe need to be patched in 15 minutes before autonomous agents are basically scanning, seeing what your tool stack is and exploiting a close to zero day, humans can’t patch CVEs in under five minutes, 24 hours a day, but agents can.”

Douglas Ferguson: Yeah. Yeah. That’s pretty soon going to be zero hours.

Peter Bell: Right. I mean, you really need to get to that point where to the extent that you are using third-party open-source tools, which I do still believe bring value, the downside is there’s lots more value in exploiting them. The upside is there are lots more people trying to ensure that they’re not exploitable. So there’s the trade-offs, but to the extent you’re using that, you need to have a dark factory in place by I’m going to say sometime next year for most of your key production code. And if you’re not working on that today, you’re going to be in trouble in Q4 when somebody asks why your competitors are going five times as fast and you’re like, “We’re investing. Give us nine months, we’ll catch up to their velocity.”

Douglas Ferguson: Yeah, your story about the self-driving cars and it makes me think about how we used to write programs on punch cards. And what was that transition like? If you were really into how to provide instructions to a computer via punch cards, your future wasn’t very bright. In retrospect, it seems kind of absurd to think, “Oh, I’m going to hang onto this punch card thing because that’s the way it’s done. And that’s my identity as someone who uses these things.” But I think at the time, there might have been folks that surely felt like, “This is not really programming.”

Peter Bell: Well, and it’s because technologies don’t start off perfectly. And it’s just when we moved from assembler to higher level languages, there were absolutely professional software developments who were like, “Huh, these automated compilers are fine, but then they’re going to work well on a 16-kilobyte memory system on an embedded system.” Or, “I want to double-check that they’re using the registers effectively so that they’re adding and storing in the appropriate register because I think I can do better than that.” And for a period of time, they were right. Today, I’d be pretty hard-pressed to think of anybody who’s literally hand coding hexadecimal to add two registers together to get business outcomes.

Douglas Ferguson: Yeah, and with the compiler optimizations, you’d be hard-pressed to find someone who was better at it.

Peter Bell: And that’s the point. It went from it sucked for almost everyone to. It was good enough for some people to it, was good enough for most people, but there were range cases where it didn’t work to there was no good reason for a human to be doing that. And I think that we’re going to see that in terms of encoding in C or Python or Rust or whatever it is you use to program. The only difference is I think the timeframe is probably going to be compressed given how quick all of these kind of sigmoid curves are kind of stacking on top of each other because so many people are working so hard to improve everything from the underlying silicon all the way up to the harnesses and the context that we wrap the models with.

Douglas Ferguson: Yeah, and also, it’s a reinforcing loop. So the advances in AI create advances in the other areas, which creates more advancement. Advancement advances advancement.

Peter Bell: And the crazy part is like we could stop now. I mean, if we were just to say like, “Okay, 4.8 is good enough, 5.5’s good enough,” there’s so much overhang just-

Douglas Ferguson: Oh yeah.

Peter Bell: … with the current state-of-the-art models, we could became busy for the next decade. And I hear that they’re not stopping. So my case is it’s going to get even better.

Douglas Ferguson: That’s my stance as well. Now, the other piece, because I said there were at least two things that came to mind when I thought about subdividing this I-want-to-be-a-coder perspective. And this one is about pushback on the need to be a manager in this world of working with agents. And so some folks opt to go down the management track, others opt to go down the principal engineer track or something similar, depending on what the terminology is at your organization. And this agentic workforce is pushing everyone into this kind of management model. You can’t just do it yourself. You have to be able to delegate, you have to be able to review work from others. And I think you and I were not that long ago talking about how it somewhat feels like having an army of interns that you’re managing, right?

Peter Bell: It’s really interesting because I think that you’re absolutely right, and the perfect first-level analogy for this is hiring. And I think it’s why a bunch of honestly old ex-technical people like me are having the best time in our lives because like, “Wait a minute, now we can actually ship exactly what we want and bring our understanding of systems design and engineering rigor and good practices, but also shape, merge that with the fact we spent 30 years asking humans to engage and build things for us.” And we’re going to get… It’s not quite the same as managing humans. Actually, you’re not going to need a sick day because your [inaudible 00:15:21] died. That doesn’t happen to Opus. But on the other hand, a lot of the delegation patterns and a lot of the patterns about, “How can I use generalized language patterns?”, the models are good enough now that I’ve got my harness to the point where I spend at least 20% of my time saying, “What would be three ways that you could economically and token-efficiently improve the thing you’ve just shipped?” And I will review the answers, but more often than not, I’ll be like, “Yeah, go with number two.” And so I’m not even proposing what they should do. I’m simply doing what I would do with a very smart… And by this time they start to feel like a junior to senior engineer, not an intern, which is, “Tell me what would make this better for the definition of better that I give you and what would be a token-efficient way of shipping that this week?”

Douglas Ferguson: You know, I think to that point, acknowledging the fact that these delegation skills, these managed tracking, prioritization, all of these skills are going to be super critical in the future and making sure that we spend time upskilling and investing and ensuring that our individual contributors are ready to start taking on those duties. And also, that’s something to even look for when we’re hiring new folks. Do they have those skills? Do they have an innate ability to do some of these things or they kind of wired that way to begin with?

Peter Bell: I think you’re right. This is fundamentally going to change not only the interview process, which I think was already broken in terms of managing the flood of inbound resumes and the validation of competence and fit process. I think that’s going to change, but it’s also going to change fundamentally what we’re looking for. And I think we’re moving towards this world where in R&D, you’re broadly going to have platform and feature as you do now, but the way it’s going to look is you’re going to have what’s effectively harness engineers who are primarily thinking about, “How can I capture more with… You know what? How can I create a step where effectively an instance of something that looks very much like Kent Beck meets Martin Fowler looks through our code and says whether it’s good or bad? How can I extract those insights, capture them in a context-efficient way and help agents to generate a rubric for it and then manage the pipeline for managing that?” So that’s going to be people who are effectively either on the platform team or are embedded in streamlined or feature teams. And then, I think the feature engineers are going to look much more like MTS, like we’re already seeing this member or technical staff where we don’t have front end, backend product engineering design so much as people who are deeply understanding the customer problems and trying to frame experiments and features designed to deliver value to those customers using whatever combination of product and coding front end and backend is required.

Douglas Ferguson: Yeah. The piece you were talking about there around the harness builders or maintainers made me think a bit about DevOps because there was a certain group of organizations that treated DevOps more as a developer experience, especially if you’re thinking about developer experience of internal developers. And then, there were some folks that thought of it more like site reliability or the cloud version of sysadmins, but the organizations that were thinking more around how are we making it more streamlined and more enjoyable to do work as a developer, as an engineer, I think you think about that role, that definition of DevOps and it very much is this kind of universe of how are we building the harness? How does it make for a great developer experience and provide all the tools and functionality we need to excel and create basically agentic teammates?

Peter Bell: Exactly. And I think we’re going to see that there’s two components to this. And the companies that already have some kind of DevOps platform org will be in the best place. And as you called out, if they happen to have already renamed a subset of that DevEx, or developer experience, they’re killing it because they’re thinking about the right things, which is, “How can we help stream align teams, feature teams who are shipping the stuff our customers want? How can we make them stars? How can we make them succeed better? And I think that what you’re going to see is that the platform team’s going to own most of the harness design and management. But I could also imagine at least in an intermediate period for the next couple years, 18 to 36 months and maybe ongoing, you’re probably also going to have embedded harness engineers or DevEx engineers within each team because what you’re going to see is, well, turns out that a good harness, a good set of steps in a pipeline for throwaway React code for an internal admin dashboard is probably different from the level of quality and the type and definition of quality you have for the stuff you use to build your customers every day.

Douglas Ferguson: Mm-hmm.

Peter Bell: And so you’re going to find that different teams working on different projects will require different subsets of… You’re still going to have the same basics, orchestrator, context management, but the details of the rubrics and the steps and the validations are going to be very different across your org depending upon what people are building and how much it matters.

Douglas Ferguson: Yeah. Security and uptime guarantees are totally different when you’re looking at internal tools versus external as well.

Peter Bell: Yeah. Or even similar, so I was speaking with Rob Zuber, the CTO at CircleCI, and he’s like, “Look, it would suck if our admin dashboard went down for an hour. We don’t want to do that. But if we can’t run continuous integration runs for an hour, we’re going to be getting phone calls. They’re two different things.” And so you have to look at the blast radius of the changes you’re making.

Douglas Ferguson: Yeah, that’s an interesting point around even as we’re experimenting with AI and what ways we might leverage it because there’s some obvious use cases around, “Oh, we can have it review pull requests, or we can have it sit here and help generate code,” but there’s tons of nascent opportunities we haven’t pinned down or identified and that’s going to require a lot of experimentation. But there’s a lot of folks in organizations that are afraid to experiment because they don’t know what the consequences are. They haven’t been given the latitude. It hasn’t been spelled out. And I think being very clear where the no-fly zones are and where there’s rife opportunity for experimentation gives people a bit more confidence when they do fly an experiment so they can avoid those no-fly zones but lean in certain areas.

Peter Bell: A lot of this is the context. A couple of this separate things I’d say. The first thing I’d say is don’t expect a hundred percent adoption. That’s not a realistic goal. I was speaking with Angie Jones, who did this transformation off the last year at Block, Jack’s company, before she moved onto the Agentic AI Foundation, and she was like, “We looked for 3 to 5% of people. That was our number, 3 to 5% of the engineers. And they were spending evenings and weekends, they’d installed Gas Town on their personal computers. They were like doing all the things, and we unblocked them and we elevated them.” Although the one interesting thing she also said is she said, “You know what? We also made sure that we picked them from all of our core teams across the company so that rather than just saying, ‘Huh,’ it worked for that admin dashboard or a little bit of app modernization, but it wouldn’t work for hard engineering problems, they weren’t given that chance.” The good news with that is it meant that they created an org-wide transformation very, very quickly. But to give you an idea of the level of executive support that required, that basically meant Angie had somebody from legal and security in her team seconded to her. And it was kind of along the lines of if they couldn’t either approve or reliably say, “No, no, we can’t do that because model hosted in China, probably not a good idea from a security perspective,” if they didn’t have a clear red line they could show or couldn’t approve a tool in a small number of days, they would just pull the lever. And it’s like, “Okay, we’re going to stop everything. Do we need to get Jack in the room?” And because of that, they had such strong executive support they could get things done. I’ve been talking with other companies where they still, “The CISO’s just approved Copilot recently for 10% of the engineers,” and I’m like, “They’re going to get exactly the outcomes you’d expect from that level of support.”

Douglas Ferguson: Yeah. You know, the varying levels of support is an important issue you just pointed out. There’s also even lack of understanding around what governance is. And when you’ve got different folks in the org thinking different things and expecting different things and there’s a lack of alignment there, and then there’s not great governance being provided, you kind of get this perfect storm of like everyone being kind frozen and afraid to do anything because they don’t quite understand. So not only does it take good, solid governance, but great communication as well to make sure that people understand what that means and how to apply it.

Peter Bell: Yeah. And it’s really interesting because I’m all in. I’m all the way AI-pilled. You don’t have to be. I mean, even the book, I’m talking about this idea of pick a lane. It’s like we have a technology adoption lifecycle and there’s going to be no different for this than anything else. And there are valid reasons to be an innovator, an early adopter, early or late majority, maybe a laggard. For example, let’s say you’re in the business of ski resorts, literally you run a bunch of ski resorts. Your biggest business risk isn’t AI. It’s climate change. That’s what you need to deal with. It’s whether or not you’re going to get enough snow. And honestly, if you’re six months or a year late to the party and you’re like, “We’re just going to wait till Microsoft folds it all into 365,” you probably could have made a little more money and shipped a few more features earlier, but who cares? If, however, you are Shopify or like Wix, like a website builder, you probably need to be an innovator or early adopter. Otherwise, you’re probably not going to be here in five years. And so it’s important firstly to pick a lane that is consistent with the business risk and opportunity you have, and then, secondly, to make all of your communications consistent. Otherwise, you get into this… The worst anti-pattern is where the CEO is on NBC telling everyone how AI-pilled you are whilst the CISO is still saying nothing but Copilot.

Douglas Ferguson: Yeah. Yeah, and that kind of gets into this issue we hear time and time again across clients and folks at these executive dinners we’ve been hosting is this issue around trust. And it cuts both ways because you’ve got folks that don’t, and we talked earlier about people that don’t trust the AI. And then, also, you’ve got trust in the organization, and that’s partially because of the phenomenon you’re talking about where CEO’s going on C-SPAN or whatever saying some things, and then might not be in agreement with the CISO, whoever else, but also things are changing so rapidly. The company’s message is going to morph a bit because, “Hey, there’s new things we understand now.” And I think that a lot of individuals are really frustrated by that. And it’s not necessarily a company’s fault, but if we don’t pay attention to that and shape that narrative and make sure that we’re consistent in it and make sure that people understand why it might be evolving, maybe acknowledge, “Yes, we understand we said this last month, but now we know this and so we have to take that into account.” I think it goes a long way to be transparent around the thought process, not just like, “What does everyone need to know?”

Peter Bell: I think that data messaging is always hard in large organization and change management, and this is a huge change management issue. Plus, the fear is, “Wait a second, am I just encoding my tastes so this thing can replace me? Are you going to need the same number of engineers and product managers?” There’s very valid reasons to be scared. And at the end of the day, the transition is happening and the thing that’s most… What’s really interesting to me is, and we saw this in the DORA report like last year, the rich get richer in every dimension. And what I mean by this, if you’ve already got good DevOps practices, it turns out if you’re doing agentic coding but Sally still has to FTP the files to the server, you’re only going to get so much acceleration. There are continuous integration, continuous delivery, test coverage, feature flagging so you can decouple, deploy from release and run experiments in production, whether you’re using Datadog or Honeycomb, like the telemetry that you’ve got the observability data so you know what’s going on in production. All of those are more critical than ever. And the reason I thought of this is the other thing that’s more critical than ever, blameless postmortems, an environment where everyone… If you can’t create psychological safety, nobody’s going to tell you how their job works because otherwise you might replace them with a machine. And nobody’s going to tell you that they’re scared about being replaced by a machine and they’re just going to tell you that Copilot doesn’t work very well, and that’s not going to work for anyone.

Douglas Ferguson: Yeah, I love that point. And I want to come back to your comment, the rich get richer. And I just want to be really succinct there because you can be rich with process or you can be poor with process, and those rich with process will get richer. It will amplify that wealth of process that you have. But if you’re poor and you haven’t invested in process, you’ve got some dysfunction, it’s going to amplify that dysfunction. So not only does Sally FTPing the file over prevent you from really leveraging the agentic workforce to help out in those areas, it’s probably indicative of some other process debt that you have that’s maybe going to get scaled in its own right. And what about the edges of those moves? None of that can be integrated. And so I think that’s the thing we’ve been encouraging people to think about, and that’s what we really mean by new friction is Sally moving the FTP file is going to present itself as serious friction in our ability to become the next-level organization.

Peter Bell: And I feel that the other thing also is it’s investing in your team, not only in terms of don’t expect 60, 80% of your team to jump straight on board. You find the 3% to 5%, the coalition of the willing, the people who are going to spend their evenings and weekends doing this, not because you tell them to, not even because you want them to, but just because what would be more fun? And there’s a certain point in your life as a builder where playing with this stuff is just fun, and that’s great. But then, you need to then build the tools and the trainings and the systems to help at least the 60% in the middle to make that move across, and you’ve got to give people time to win. If you’re like, “Hey, we need you to ship everything, which is still critical, oh, but also take 15 hours a week to go learn this new thing,” that’s not going to work. One way or another, it’s going to break with anybody who has kids or family or commitment or parents to deal with. And so you really you have to give people the time to adopt. And the good news is you actually don’t usually lose velocity, but you need to give them the permission-

Douglas Ferguson: That’s right.

Peter Bell: … to lose velocity for a quarter so that you can speed up in the next quarter.

Douglas Ferguson: Yeah. It comes back to that psychological safety piece you mentioned earlier. You have to make it safe to experiment in a number of ways. It can’t be a side-of-desk project. They have to have reserved and protected time. And then, also, they have to be treated with, I would say, respect and encouragement when things go wrong. To your point, if you miss a deadline because you’re experimenting with AI, well, we need to step back and look and say, “Did we actually learn stuff? Does that mean we’re going to beat the next deadline by 50%? Okay, well, it all comes out in the wash.” But if instead we just have an immediate reaction, that’s bad, we need to be punitive here, then we’re really going to miss the boat. People are going to stop experimenting.

Peter Bell: And I feel like I remember Etsy back in the day, and it’s different, but I think it’s comparable. They used to have this commit-on-day-one policy and they still do, and I think it’s much broader now, but this was maybe 10, 15 years ago. And most people would be like, “Wait, you’re letting somebody who knows nothing about your systems like commit some kind of, even if it’s just a nominal fix to a button, on day one? What if they break things?” And the feedback, the answer from Etsy was, “If your system is so fragile and brittle that somebody with good intentions can break it on their first day at work, you should be building your systems, not putting more gates in place.” And I think that’s the way to think about all of the agentic engineering as well, which is we need to build both the culture of psychological safety and support, but also these deterministic and adversarial gates, these tools to make sure that if somebody does make a mistake, you catch it early and quickly. And it’s unlikely, A, to go to production, and B, to waste two weeks of their time trying to figure out why these prompts don’t work.

Douglas Ferguson: You know, I joined a startup years ago and my first day on the job as CTO, the junior engineer who had just gotten promoted before I came online, they had promoted him from… he had just wrapped up his degree at UT, and so they converted him from intern to a full-time engineer. And it was within my first week and he managed to delete the production database. And, luckily, there were processes in place, we got it recovered, et cetera, et cetera. And I was posting, I can’t remember, it might have been Hacker News or it was somewhere that I posted just like, “Oh my gosh, first week on the job, da, da, da, da, da.” And then, of course, someone commented like, “Don’t let them near production systems anymore.” And my comment was, “I have more confidence in that individual on the production systems now than I do some of the other folks.” Because that experience, watching them go through it and them doing what they could to… A, the fact that they reported it, they didn’t try to hide it, the fact that they were just terrified and they’re going to be walking around on pins on needles anytime they’re on a production machine. And I think that’s the lesson we should learn. It’s like, “Not how do we punish someone, but how do we actually learn from our mistakes?”

Peter Bell: Absolutely. I guess last anecdote for that, so I remember one of the… I think it was the first CTO of the United States, there was a guy who helped to turn around HealthCare.gov, I believe it was, back in the time, I’m thinking Obama days maybe. And what was interesting is he gave this talk at a group I was involved with and he said he couldn’t. So imagine you brought in, this thing is months behind schedule, it’s not working, it’s a piece of junk, and you need to fix it using the same people with no different budget. You can’t change out the team. How do you turn it around? And the first thing he did, he actually kind of seeded it where one of the people stood up and said, “I lost some data from production.” And everyone’s like, “Contractors like Washington, D.C., I mean, this is like, ‘Okay, you’re never going to get another federal contract again.'” And he said, “Great, let’s take a moment. Let’s have a round of applause for that person for being honest and sharing. Great. What did we learn and how can we build processes so that doesn’t happen again?” And that was, he said, the turning point where they could start to build the psychological safety so people were focused on sharing the problems they had so they could fix them rather than hiding them and hoping to run out the clock.

Douglas Ferguson: Yeah. So important, especially in this era of AI where we’re moving so quickly and adopting new things, and creating those environments is so critical.

Peter Bell: Absolutely.

Douglas Ferguson: So I want to switch gears a little bit. You kind of touched on this a bit when you mentioned that in reality the adoption’s about 3% to 5%, and yet we see a lot of organizations with these top-down mandates, and we actually refer to it as the mandate trap. It’s one of the things we’re noticing right now, and we’re trying to coach any of our clients away from any of those behaviors, but I’m curious what you’ve noticed. And specifically when you think about this adoption rate of 3.5%, maybe how to get it up, how do we measure success in this AI world, I guess, is kind of what I’m getting at because that’s how we get past the mandates is being able to measure the process, I think.

Peter Bell: Absolutely. So firstly, I should clarify, I think you’re going to see 3% to 5% of super adopters, and then you’re going to see… I mean, the number, Steve Yegge got into a lot of trouble on Google… on Twitter or by X by saying, “You know, 20% of people are killing it, 60% of people will come along, and 20% will never touch it. And the same’s true at Google and anywhere else.” And first-level round numbers, he’s about right. There’s a few people who are killing it, a bunch of people who are willing to follow along, and a small tail who just have no interest in going. So first thing to do is drop this, not like fire, but don’t focus on the last 20%.

Douglas Ferguson: No.

Peter Bell: What you do is you elevate and you unblock that first 3, 5, 15%, whatever it is. You make sure that they get the tokens they need, the support they need, the resources they need, and you elevate them. Then, you help ask them, “Great, now you’re doing this. How can we do this as an org? Join a council, do lunch and learns. Can we build a small DevEx or platform team that has shared skills and shared resources? How can we get more observability and capabilities within our platform?” So a lot of this is about unblocking and supporting. Another part then is creating a path for the middle, the kind of quiet middle who just want to go home in the evenings, but unopposed to AI, you just need to tell them how to do it. And then, the other piece of this is in addition to that, you need to support these groups in figuring out what problems they have. So you were talking about management and metrics. The success metrics are, honestly, business ones, and you can take proxy metrics as long as you don’t performance-manage them. You learn something by token usage. If somebody’s not blown through a $20 a month plan, they’re probably not using it enough. But if somebody spent 8,000 bucks last month and has spent 6,000 this month and their output increased, they’ve probably improved the efficiency of the levels of the models they’re using. So it’s not that token maxing is good, but it is okay to know how many tokens people are using as a diagnostic to put them into populations which you can then support with adoption in different ways. The true success metrics are pretty straightforward, all right. It’s revenues, it’s customer retention, it’s all the numbers you care about. The challenge becomes that it’s hard to map those to a particular feature deliverable or a particular agent. So I think the main thing to do is the AI token usage and stuff like that, that is a diagnostic to help you to cluster people around common failure patterns of adoption so that you can give them the training and support to learn how to get through, “Oh, that’s the kind of thing we see when somebody’s still on an IDE.” We should teach them how to use skills with agents. That’s the thing we see when somebody’s waiting for one agent 15 minutes at a time, we should show them how to use multiple agents and so on towards moving them towards using a dark factory. And then, the other piece is classic DORA, DX Core 4 space metrics, I think still have a place. They’re not the answer, but things like cycle time, meantime between failures, PR rates, all of those can be gamed, but if there’s no reason to game them, they can be useful diagnostics to help you to see how you appear to be doing.

Douglas Ferguson: Yeah. And it’s really interesting, too, when you think about cohort analysis, you could look at that in a number of ways. You could look at any of our standard metrics like cycle time, a few others you mentioned as it relates to folks that are heavily using AI, barely using it to not using it at all, because then there’s an interesting story to be told there. It’s like, “Well, what kind of outputs are we seeing from these individuals and different teams as well?” The other thing around cohorts that’s fascinating to me is what are we noticing as far as the friction that we might be seeing from each of those cohorts? And because you mentioned looking at, “Well, what signals are indicative of someone still being in the IDE or whatever some of these types of behavior shifts that we’re looking for?” And I think, likewise, if we diagnose where are the sticking points in the organization and what are those indicative of? It’s like, “Hey, if we’re going to be investing in this 20% that’s really leaning in and we’re trying to remove obstacles, well, let’s actually make note of the obstacles they’re running into. And then, how do we codify that into repeatable patterns or better ways of supporting them?”

Peter Bell: Absolutely. And I think we’re seeing that what’s nice is I think that 5 to 15, 20%, what they do is they’re actually as the obstacles they usually run into are self-induced by the company. And I have lots of friends who are CISOs, but like security, compliance, governance, audit, risk, it’s those groups that are designed to keep things the same so we don’t break it all, which is a noble mission, but we need to understand that there’s risk to not changing and support those teams in being enablers and not blockers. And then, once you’ve got that in place, then what they can do is they can… The truth is what they’re doing is hard and it probably is requiring evenings and weekends, but what they can do then is synthesize the good practices, create standard skills libraries, create a standard factory harness and standard adversarial reviews, improve the quality of the observability and the DevOps and CI and CD pipelines, all the things that are going to make it easier for other people on the teams to then kind of join along. And the other thing, it feels to me like I remember when you mentioned TDD earlier, test-driven development, you had to get… Most of us got test infected. We’d read the books, we kind of saw the stuff, it didn’t really make sense. And then, you paired with somebody from like a Pivotal Labs or a Thoughtworks back in the day and you’re like, “Oh, that.” And after two or three hours of pairing, it made perfect sense. And just as you had to get test infected, I think there’s huge value in getting AI infected where a coworker just sits down with you, pairs on a couple of features, and shows you how they’re leveraging skills, how they’re jumping between agents and how they’re building these kind of pipelines so that they can start to trust the quality of code that’s being shipped.

Douglas Ferguson: Yeah, I mean, sure we see the CISO friction all the time like, “Oh, we really want Claud Code, but security has only approved Copilot,” or whatever. And so that certainly is an obstacles we should as leaders be trying to remove if we’ve got folks on the team eager to push things forward in ways that are responsible and secure, then we should pave the way there. But I think the latter half, the stuff you got into, I think is a little less obvious. It’s totally clear if they’re trying to use a tool that’s not available, but what about these models and patterns? Because you can’t go just grab a book off the shelf. You can’t go read about Spotify’s model of how to do this. And so are we creating opportunities to sit with peers and see how they’re each using skills and really look at what is some of that minor friction that they’re running into that’s not maybe apparent or where they’re scratching their head a little bit? A great example, buddy of mine mentioned that someone on his team was… He’s a VP of engineering, and someone on his team had one-shot this piece of code that was like, I don’t… It was like 250,000 lines of code or something insane. And admittedly, the engineer came in and said, “This seems to be working,” but I’m like, “I can’t even fathom how to read this much code. I’m stuck.” And so then, that became a conversation around, “Well, this is some new friction. Look at this thing. It’s brilliant. It seems to work. When we poke it does the things we want it to, but we need to understand this better.” And the thing they came to was, “What if we then use the AI to decompose this into more meaningful, smaller chunks that are easier to read? We’re still get this out the door way faster than we ever would have previously, but let’s induce some slowness here because we want process and we want care and quality. And I think that’s a great example of the types of friction we should be listening out for and helping our teams work through because that’s what’s going to create the models of the future.

Peter Bell: Exactly that. So there’s a guy called Sam Schillace. I first came across him when he was SVP engineering at Box. Now, he’s a deputy CTO at Microsoft. He has helped them to build this tool called Amplify, which it’s like the best harness nobody seems to know anything about. They don’t promote it very much. But what’s interesting is he’s got this Sunday letters from Sam on Substack, and he’s got a couple things that he’s built into his pipeline. One was Cranky Old Engineer, which is basically the salty old engineer like, “That’ll never work under load. You’ve got to ensure that there’s a fallback and you back off your retries against the API or whatever it is.” But now he’s got COS, Cranky Old Sam, which is based on Cranky Old Simplicity as well, which is basically saying, “Hmm,” and it will literally go back to the agent that’s generated a code that’s passing the functional test that’s meeting the performance requirements saying, “Would there be a simpler way to do this?” And proposing unifications and simplifications and simpler ways of solving the same problem. And it turns out that a lot of this is just reprompting and loops. And if you’re willing to burn the tokens, most of the problems the agents solve, you can get other agents to tell them how to fix.

Douglas Ferguson: Yeah, it’s amazing. It’s so fascinating. I mean, and to your point, willing to burn the tokens, I think that’s going to be a conversation that evolve even more so over the next six to 12 months. As we’re seeing the cost of tokens rise, more competition against models, the IPOs are certainly going to influence us because now the market’s going to be a driver and have a voice in the cost of these tokens. So it’s going to be fascinating to look and see how we start to optimize around token consumption and when, where, and why to use them.

Peter Bell: And I just want to throw one thing in there because what happens is every so often people who want AI not to succeed, and I get it, I understand why, will be like, “Oh, token costs are going to become crazy, so we’re just going to hire humans to do it.” If there was one piece of generalized advice I could give is don’t bet against the models. I don’t think that’s a good long-term bet to take. And there’s no question that sanity is going to prevail. Tokenomics is a real thing now just as FinOps is for cloud. We’ve started by, let’s say, we’re just going to run all this Kubernetes stuff in the cloud and it’s going to be perfect. And then, the CFO comes calling like, “Why did our operating cost go up by $12 million last year?” “Oh, we forgot to switch off the… We had this test run and we forgot to switch it off for six months.” That was like a million and a half. And so then you started to bring sanity and improve operational and then the spot versus reserved instances and all the rest. We’re going to do the same here, but here it is you should never use a model to do something that code can do perfectly well. Long running, don’t use supervisor model, use deterministic pipelines. If you’re extracting text from a PDF, have a Python script extract it and just put the text into the model. Don’t burn the tokens on a 4.8. And it’s all of that. I just ran a bunch of evals. I had a bunch of stuff running on Opus that I’ve now downgraded to Sonnet and then to Haiku with evals and test sets and they just auto-tuned the prompts until it would work. So all of this is just a simple engineering problem. We know how to engineer the costs out of stuff. So, yes, token costs are real, and no, don’t believe that somehow magically you’re going to stop this, it won’t.

Douglas Ferguson: So what you’re making me think of is that Chaos Monkey might be coming back but in the age of AI.

Peter Bell: I think it’s going to be so many of the things we’ve seen before coming back just at another level, and it’s going to be really interesting to see how they all play out.

Douglas Ferguson: For sure. Well, as we come to our end here, I want to give you an opportunity to leave our listeners with a final thought.

Peter Bell: Absolutely. I’ll give a two-for-one. The first thing is do it yourself. If you’re a CTO, you shouldn’t be writing production code and blocking that for three months as you’re going to performance review season. But if you’re not spending time building with these models, you won’t get the right intuitions, and that’s the only way to keep up. And second, have a sense as to where we’re going. This isn’t about Copilot, this isn’t about IDE. This isn’t honestly about the kind of interfaces we’re seeing now. We are building systems that will write the software, and our job is to identify the experiments and the verifications and build the toolings to make that work. And understand that until you fundamentally rebuild the SDLC for agents, you are not going to get the kinds of ROI that you’d expect out of these systems.

Douglas Ferguson: Important words. Great to be chatting with you today, Peter, and looking forward to talking again soon.

Peter Bell: Douglas, thank you so much for the invite. So much fun.

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 AI Transformation Is About Alignment, Not Tools appeared first on Voltage Control.

What Two Real Cases Reveal About AI Governance

Joe Mariano said something at the Gartner Digital Workplace Summit and it should be on a poster in every AI governance committee in the country. “AI is a tool. It is not a legal shield.” Two recent cases prove him right. In both, an organization deployed an AI system, the system did exactly what it was designed to do, the organization got sued, and the organization lost. Not because the model misbehaved. Because nobody on the human side was watching. These are not abstract risks. They are the first two real precedents we have for AI liability in the enterprise, and they both turned on the same thing: a monitoring and data gap that the legal system treated as the company’s responsibility, not the AI’s. If you are a leader thinking about AI governance, you are no longer thinking about it in theory. You are thinking about it inside the ruling that other companies have already lost.

The Air Canada Chatbot Case

In November 2022, Jake Moffatt visited Air Canada’s website to book a last-minute flight to attend his grandmother’s funeral. He asked the airline’s AI chatbot whether bereavement fares were available. The chatbot told him yes, that he could book the flight at full fare and apply for a bereavement refund within ninety days of travel. He booked. He flew. He filed for the refund. Air Canada denied the claim. The actual policy required bereavement-fare requests before travel, not after. The chatbot had hallucinated a refund window that did not exist. Moffatt took the airline to the British Columbia Civil Resolution Tribunal. Air Canada’s argument was the part that should make every AI governance lead pay attention. The airline argued that the chatbot was, in their words, “a separate legal entity that is responsible for its own actions.” The tribunal rejected that argument flatly. In Moffatt v. Air Canada, 2024 BCCRT 149, the tribunal ruled that Air Canada was responsible for all information on its website, regardless of whether it came from a static page or a chatbot, and ordered the airline to pay damages. The decision is short, the legal reasoning is clean, and the precedent is simple: if your AI tells a customer something false, your company said it. The chatbot does not have its own lawyer. It does not have its own bank account. It does not have legal standing. It is a tool you deployed, and the output is your output. Air Canada’s failure was not that the chatbot hallucinated. Hallucination is a known property of generative systems, and any organization deploying one in a customer-facing context should plan for it. The failure was that nobody checked. There was no monitoring layer, no review pipeline, no human in the loop verifying that high-stakes policy claims matched the airline’s actual policy. The model behaved as models behave. The organization behaved as if the model would not.

The iTutorGroup EEOC Settlement

In August 2023, the U.S. Equal Employment Opportunity Commission settled a case against iTutorGroup, a tutoring company that had used an AI-driven recruitment system to screen applicants for tutor positions. The system was configured to automatically reject women aged 55 and over and men aged 60 and over. More than two hundred qualified applicants were filtered out before any human ever saw their applications. The EEOC argued, and iTutorGroup agreed in a consent decree, that the company had violated the Age Discrimination in Employment Act. iTutorGroup paid $365,000 in damages and committed to anti-discrimination training and oversight changes. It is widely cited as the first EEOC enforcement action targeting algorithmic discrimination, and it set the regulatory tone for what was to come. The interesting thing about this case is that the AI did not malfunction. It did exactly what its rules told it to do. Somewhere in the configuration, somebody had set age thresholds. The AI applied them. Hundreds of times. What was missing was the question of whether anybody should have set those thresholds in the first place. There was no review of the screening logic against employment law. There was no monitoring of who was being filtered out and why. The data quality, the rule design, the oversight layer, all of it sat inside an AI deployment that nobody thought needed governance because the AI itself was working. That is the iTutorGroup pattern, and it is more dangerous than the Air Canada pattern because it does not look like an AI failure. It looks like an AI success.

The Pattern: Monitoring Gaps, Not Bad Models

Joe Mariano walked through both of these cases at Gartner DWS 2026, and the framing he landed on is worth repeating: the failures here were not in the technology layer. They were in the layer above the technology, where humans decide what the AI is allowed to do, what data it sees, and who is watching when it is doing it. The Air Canada chatbot worked as a generative chatbot works. It produced a plausible answer to a question it did not have grounded knowledge to answer. The failure was that the airline deployed it on a high-stakes policy page without a verification pipeline. The iTutorGroup recruiter worked as a rules-based filter works. It applied the configuration it was given. The failure was that the configuration had been set by humans without legal review, and there was no monitoring on the output to flag the discriminatory pattern. Both failures, in other words, traced to the same place: the human-decision system around the AI was not designed. The technology was deployed faster than the governance scaffolding around it could catch up, and the legal exposure that resulted was real. This is the part most AI governance conversations skip. They focus on the technology, on which model, on which vendor, on which compliance certifications, when the actual exposure lives in the workflow. Who reviews high-stakes outputs before they go to customers. Who audits the rules the AI is using. Who is watching for patterns that look fine inside the model but look discriminatory in aggregate. The Gartner data backs this up. There are over 1,000 proposed AI rules and regulations worldwide right now, and not one of them has the same definition of AI. The regulatory landscape is going to get harder, not easier. Companies that are still treating AI governance as a policy document, rather than as an active facilitation problem inside their organization, are going to keep producing the next Air Canada and the next iTutorGroup.

Why AI Does Not Absorb Accountability

There is a comforting fiction that some leaders are still telling themselves about AI deployment, which is that the model carries some of the liability. It does not. Across multiple jurisdictions, in multiple legal frameworks, the rulings are converging on the same answer: the deploying organization is accountable for the output, full stop. This makes sense the moment you say it out loud. The AI did not sign a contract with the customer. The AI did not file a lawsuit. The AI did not get sued. Your company did all three of those things. The model is a tool the company chose to deploy, and the output of that tool is the company’s output, the same way that an internal email written by a junior employee is the company’s email. What this means in practice is that the conversation about AI governance has to move from “is the model trustworthy” to “is our deployment of the model accountable.” Those are different questions. A trustworthy model deployed without governance is still a liability. An imperfect model deployed with rigorous governance is, in many cases, fine. The trustworthy-but-ungoverned configuration is what produced both cases above. The Air Canada chatbot was, by industry standards, a perfectly normal AI product. The iTutorGroup recruiter was, by configuration standards, perfectly capable of being used legally. Neither model was the problem. The deployment around it was.

Four Governance Patterns That Actually Work

If the technology is not the gap, what closes the gap? Mariano’s session offered four patterns, and they map cleanly to what we see when we walk into client governance work. Brain-first deployment. Before AI is brought into a workflow, the team uses human judgment to define the goal, the boundary, and the success criteria. The AI is then brought in to assist a human-defined process, not to replace the human-definition step. Air Canada skipped this. The chatbot was deployed on a policy page without anyone defining what counted as an acceptable policy answer. Human in the loop for quality control. Some volume of AI output gets reviewed by a human before it goes to a customer or a decision. The exact percentage depends on the stakes, but the principle is non-negotiable: zero human review on high-stakes outputs is a deployment, not a governance posture. iTutorGroup ran a recruitment AI with apparently no auditing of the rejection pattern. That is the failure case. Data quality management. AI systems accessing wrong, stale, or biased data will produce wrong, stale, or biased outputs with full confidence. Both Air Canada and iTutorGroup had data quality problems at the root. The chatbot was answering questions about a policy it had not been grounded in. The recruiter was applying rules that had not been audited against current law. Neither case was a model problem. Both were data problems wearing model clothing. Continuous skill and process maintenance. Governance is not a one-time training. It is an ongoing practice, with periodic reviews, audits, and skill refreshes for the people running the system. The model evolves. The regulations evolve. The use cases evolve. A governance framework that was designed twelve months ago and has not been touched since is, by definition, stale. These four patterns are not novel. They are the basic discipline of any high-stakes deployment, applied to AI. What is new is that the legal system is now treating them as the standard of care, and organizations that ignore them are losing the cases.

The Real Move: Treat Governance as Facilitation

Here is the move most organizations miss. AI governance is not a document. It is a set of ongoing agreements between security, legal, business, and operations about what the AI can do, who is watching, and what happens when something goes wrong. Those agreements have to be negotiated. They cannot be written by one team and handed to the rest. This is where the work gets uncomfortable, because it requires the same cross-functional conversation that most organizations are structurally bad at. Legal does not want to talk to Engineering. Security does not want to talk to Marketing. The business unit that wants to deploy the chatbot does not want to slow down for a review. And so the governance conversation never happens, and the deployment goes out, and somebody loses a tribunal. The organizations getting this right are the ones that treat AI governance as a facilitated, recurring practice, not a sign-off process. They have a standing forum, with the right people, that meets often enough to keep up with what is being deployed. They produce decisions, not policy documents. They review the deployments that have shipped. They ask, every time, what would happen if this output ended up in front of a regulator or a tribunal. That is the New Friction. AI eliminated the old friction, which was execution time. The new friction is the human-decision layer that has to keep up with what AI now lets you ship. Organizations that do not invest in that layer ship faster, get sued more, and lose the cases. Organizations that do invest in it ship slightly slower, ship better, and stay out of the tribunal. If you are building or refreshing your AI governance posture right now, the question is not which model you trust. The question is which decisions your organization can keep up with, and which conversations you are willing to have to keep up with them. That is the work. That is the entire work. If your organization is in the middle of that conversation, or trying to start one, that is where Voltage Control comes in. Read our New Friction primer for the full framework, or reach out if you want to talk about where your governance posture is stuck.

Frequently Asked Questions

Can companies be held liable for AI mistakes?

Yes. Both the Air Canada and iTutorGroup cases establish that the deploying organization is responsible for AI output, regardless of whether the output came from a human or an AI system. Air Canada explicitly argued that the chatbot was a separate legal entity. The tribunal rejected the argument. Across jurisdictions, the legal direction is consistent: the company that deploys the AI owns the consequences.

What happened in the Air Canada chatbot case?

A customer asked Air Canada’s chatbot about bereavement fares. The chatbot hallucinated a refund policy that did not exist. The customer relied on it, booked the flight, and was denied the refund. He took the airline to the British Columbia Civil Resolution Tribunal, which ruled in Moffatt v. Air Canada, 2024 BCCRT 149, that the airline was responsible for the chatbot’s output. Air Canada paid damages.

How do organizations govern AI systems effectively?

Effective AI governance is a recurring facilitation practice, not a static policy document. The organizations doing this well bring legal, security, business, and operations into a standing forum that meets often enough to keep up with deployments, audits real outputs, and produces decisions. The four operating patterns are brain-first deployment, human in the loop for quality control, data quality management, and continuous skill maintenance.

What is AI accountability in the workplace?

AI accountability is the principle that the organization deploying the AI is responsible for what the AI produces. That responsibility cannot be delegated to the model, the vendor, or the AI system itself. It lives with the humans who decided to deploy the system, configured it, fed it data, and chose how much oversight to give it.

Who is responsible when AI makes wrong decisions?

The deploying organization. In every major AI liability case to date, including Air Canada and iTutorGroup, the courts and tribunals have held the company responsible for the AI’s output. The model is treated as a tool, and tool failures attach to the operator, not to the tool.

The post AI Is Not a Legal Shield appeared first on Voltage Control.

In this episode of the New Friction podcast, host Douglas Ferguson speaks with Jeff Grabill, Dean of the College of Arts and Sciences at the University at Buffalo, recorded in the immediate aftermath of the IHE US AI Summit 2026, which both men attended. Grabill recounts what emerged from that two-day working convening: the foundation of the Buffalo Statement, a collective public agenda for AI in higher education, and reflects on why the room’s patience, grounded confidence, and willingness to question prior assumptions exceeded his expectations. The conversation explores why universities, often criticized for moving slowly, may possess exactly the right instincts for AI transformation: designing conversations intentionally, engineering productive friction, and moving fast and slow at the same time. Ferguson and Grabill dig into how AI has relocated rather than eliminated friction, particularly in learning environments, where effortless output now threatens the productive struggle that actually builds expertise and ideas. They close on a librarian’s insight from the summit — “I don’t care if AI created it, I care if it’s true” — and Grabill’s call for businesses and universities to actively seek one another out as partners in working through this moment.

Show Highlights

[00:01:26] The Summit and a Missing Public Agenda
[00:05:17] Vulnerability as the Summit’s Secret Ingredient
[00:09:40] Disciplinary Identity and the AI Conversation
[00:18:02] Why Higher Ed Needs a Design Practice
[00:20:07] Moving Fast and Slow at the Same Time
[00:25:44] Unpacking the New Friction
[00:29:46] Engineering Productive Friction in Education
[00:51:34] Truth Over Authorship

Links | Resources

Jeff Grabill on LinkedIn

About the Guest

Dr. Jeffrey T. Grabill serves as Dean of the College of Arts and Sciences at the University at Buffalo, the university’s largest academic unit, a role he assumed in August 2025. Before UB, he spent four years as Deputy Vice-Chancellor for Student Education at the University of Leeds, and nearly two decades at Michigan State University — ultimately as Associate Provost for Teaching, Learning, and Technology, where he co-founded the Hub for Innovation in Learning and Technology. He developed and led a research center on written communication and technology and co-founded Drawbridge, an educational technology company that spun out of his research group. Grabill is the co-author of Design for Change in Higher Education, published by Johns Hopkins University Press, and his work focuses on how rhetoric supports citizenship, learning, and institutional change.

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 Jeff Grabill at the University of Buffalo, where he’s the dean of the College of Arts and Sciences. He’s also the author of Design for Change in Higher Education from the Johns Hopkins University Press. Welcome to the show, Jeff.

Jeff Grabill:
Douglas, thank you. It’s always a pleasure to talk with you. I learn a lot when we do, so thanks for the invitation.

Douglas Ferguson:
Oh yeah, it’s amazing. And the feeling is mutual. So let’s talk about the last two days. We just spent two days with 300 people drafting a public agenda for AI and higher ed. And if we strip away the panels and reflect on what was the single biggest thing that’s actually shifting right now, I’m curious what’s emerging for you, especially in the afterglow.

Jeff Grabill:
A couple of things. Yeah, so the conversation was, I thought, fantastic and exceeded my expectation. So let me back up a step and walk through your question. So the purpose of the meeting, we’d noticed, and I wasn’t the only one who’d noticed, but those of us at the University of Buffalo had noticed, not just that there was no public agenda for AI. There was an Ezra Klein podcast about that. I think lots of people have noticed it.
But also that there was no public universities in particular, but universities more broadly weren’t stepping into that space. And we’ve all been floundering a little bit. And as soon as we started socializing with people that the fact that there’s no public agenda for AI is a problem, and absent leadership in Washington, frankly, who’s going to step into that space and start to do more than wring our hands about it, but start to articulate how we might collectively and collaboratively proceed.
So the notion of having a meeting, a working meeting, not a conference, in which we put the lack of a public agenda on the table and put the question of what is the role of the university in relationship to that public agenda on the table, I was really pleased at how many people rallied to that. This is a great idea. So we had nearly twice as many people at that meeting than we thought. We tried to curate that meeting as best we could with expertise. It was a working meeting. We are going to produce the Buffalo Statement or some such thing which starts to sweep together the meeting.
So what surprised me about it? I was pleased, but not necessarily surprised at what I just said, that the reaction was immediate, the reaction was positive, and people have rallied to it. I was surprised in the meeting at how positive people were and how grounded people were. In other words, there wasn’t a lot of hand wringing and anxiety, and we’ve got to catch up in that room. And there was actually a sense of patience and confidence that universities have been around a very long time, and there’s a reason for that, and that there’s some durable value in what universities have to offer and we ought to lean into that because that will probably be durable.
But at the same time, there is a role for us. Universities are suffering a little bit right now. The public opinion of universities is as low as it’s been in a really long time. And so we also recognize that if we step in as a platform and a convener and a collaborator, we have a little bit of work to do to get people to trust us the way they used to trust us. So surprised at the confidence and the positivity, the patience, those were the things I took away, and I was pleased by those surprises.

Douglas Ferguson:
Absolutely. I was actually very impressed by just how the group showed up and collaborated, and especially in a moment in time where there’s not a lot of collaboration across disagreement. I found people bringing differing points of view, and actually taking the time to consider and listen and think about how those points of view might get integrated. I took it as a testament to your curation of who was in the room, but also still impressive, and it gave me a sense of hope.

Jeff Grabill:
Yeah. No, thank you for picking that up. I picked it up too because that meeting didn’t work if that didn’t happen. So if people came in and sat back on their hands, or looked at their phones for two days and refused to be a little bit vulnerable, it requires some vulnerability to sit at a table with some people you don’t know and dwell in that space. Let’s try to figure some things out together. I think that’s why the meeting worked. I’m really pleased you noticed it. I think you nailed it. That’s why we had a productive two days.

Douglas Ferguson:
Just to be real specific for the listeners, one great example of that is you had folks that were super optimistic about things and they were looking at the data center impact as a job creating event. And then you had folks that were looking at data center impact on the environment and were very concerned about it. But there’s room for both of those points of view, and it wasn’t argumentative. It was very curious. And people were creating space for the opposite points of view. And I think we need more spaces like that today, and especially in this AI conversation.

Jeff Grabill:
I completely agree with you. And some of the academics in the room that were most skeptical and oppositional are my colleagues in the College of Arts and Sciences here. And I was thrilled that they were there, but I rotated tables, I sat on a table for a while with some of them. I was even happier the way they showed up. They’re worried. This is their science. They understand things, they have expertise. But they did create space in the conversation, and I think in their own minds, for possibilities that are a little bit different than their defaults.
There was an economist in the room who kept talking about this moment with regard to the labor market, for example, another example of a really productive conversation is that we have to question all of our priors about how innovation cycles and disruption cycles work because this one doesn’t seem to be tracking with our priors. And so I thought that was a really, it’s a very economist way to speak, but I thought that that was something that happened across the room, and that everybody sort of checked their priors a little bit and opened the possibility that maybe those priors were wrong.

Douglas Ferguson:
There was a moment in one of the panels where, and I’m blinking on the individual’s name, but he offered a call to action to all the universities to tap their historians and maybe present to all the faculty and staff around these historic moments of what it was like to live through the printing press revolution, or any of these other technological revolutions that how can we draw from those moments and maybe imagine ourselves, and how it’s similar, how it’s different. I thought that was really awesome to think about, hey, we have these resources on campus. Let’s maybe share them with our peers, not just the students and the researchers.

Jeff Grabill:
No, I think it’s a key insight. I’ve also, to build on that, have a business school dean in my past whose favorite people on campus were historians. Because he not only read history, but he talked to them because the coffee conversations that he had with historians were better at grounding his sense of where the financial markets were going to go in the future. Because the things that seem sort of disruptive and new to us, you talk to a good historian, they’ll say, “Well, maybe we’ve been here before.” And they unpack it for you. And then in a way, we have been here before and in a way we haven’t. And I think that kind of wisdom, history’s useful in that regard. So not the first time I’ve heard it, but I thought I remember that. And that was a really useful contribution too. The historians in the room loved it.

Douglas Ferguson:
Yeah. It’s reminded me of Jeff from Worcester’s comment about how it’s not about using the AI tools, but it’s about how experts in a discipline will leverage it for the best use of that in that discipline. And so not only how are we leaning into our historians, but our economists, our librarians. They need to develop their use cases that are very idiosyncratic and how they bring their expertise into these new tools.

Jeff Grabill:
Yeah. He and I had a real meeting of the minds about that because he’s a new dean of Arts and Sciences. He’s four days in. I’m 10 months in as a new dean of Arts and Sciences. The University of Buffalo’s been an AI forward university for a long time. We intend to stay there. And I have a lot of skeptical, grumpy, worried academics across my college. And the only ask I’ve made of them with regard to AI is, I need you to engage. You can’t sit it out. So if you sit it out, I’m going to be frustrated with you. So please don’t. Engage. You can be grumpy, you can be skeptical, you can be yourself. Be yourself as an individual, be authentic, be yourself as a disciplinary creature, which is what Jeffrey was talking about. Be that person and we’re going to be fine.
But if you check out and disengage, that’s not who we’re supposed to be as leading public research universities. We don’t get the option to disengage. That’s not the job. And then to their credit, they roll their eyes sometimes at me, and the dean is opining again, but they’ve engaged. And there were people in that room the last two days who might not have been there had we not collectively worked on this in the college here at the University of Buffalo.

Douglas Ferguson:
Yeah. I’m thinking about that conversation more deeply now. And one of the things that really stuck with me listening to Jeffrey talk about that was this idea that it’s okay to be a cynic, but you need to be an informed cynic. If you just dislike it because you dislike it, well, that’s not helpful to developing thought and points of view.

Jeff Grabill:
Yeah. And I think that’s a really important challenge. I mean, I used to say this when I was mentoring graduate students, and it’s a real privilege to be a university professor. Yes, everybody who gets there works really hard, is also super lucky. Lots of people help you get there. You catch some breaks. But it’s a privilege and it’s a responsibility.
And one of the conversations I used to have with the graduate students that I mentored is really challenging them to own the responsibility. It means something to be a university professor at a leading research university, and there’s expectations for us. To say what I said earlier, we don’t get the option to sit it out. That’s not the job. The job is to push the edges, push the frontier, think the thoughts that are not supposed to be thought or that are challenging. This is why we have academic freedom.
Our job is to be on the edge and to support people in doing that work. We’re supposed to do hard things. And those are hard conversations to have with people. And they’re hard for me to own because sometimes I’m just tired. But that’s the work. And to get back to the meeting, that’s what I wanted to do with the meeting is give us a space to signal to each other that we’re not alone as a group of intellectuals, intellectuals in private industry and intellectuals in the university who know that this is the work that we have to do.

Douglas Ferguson:
And I want to come back to this idea of no public agenda. If I remember correctly, Armada pushed back and said there’s already one, and the danger is reacting our way out of it, I think was her position. And so basically not doing anything or abandoning it because they’re scared of looking slow.

Jeff Grabill:
Yeah. I thought that was a key moment. So this is one of the things where I changed my mind. Because I mentioned earlier, we’re going to write this Buffalo Statement, and hopefully it’s good and people pick it up and work with it and engage with it. I’ve written a draft of it before the meeting because I didn’t want to go in the meeting cold. And we’re going to write it together. The meeting was a writing workshop in many respects.
She changed my mind about that. And her point was there is no public agenda for AI in the United States. There’s no policy agenda, there’s no blueprints that a government would provide, for example, or a set of institutions might provide. What her argument was, universities have a public agenda for AI, and we don’t need another public agenda. We just need to be ourselves and do our thing.
And I’m not entirely sure I completely agree with her, but in another way, I think she’s really right. And I suspect that this Buffalo Statement’s going to reflect that in the sense we shouldn’t wait around for the federal government, for example, to fix itself. God knows how long that’s going to take. In the meantime, we need to proceed, and here’s what it might look like for us to proceed with public universities in particular leading.

Douglas Ferguson:
Yeah, that was something Eric and I were talking about a bit yesterday. He was referencing some research that’s in a book that I need to read, and I need to reach back out to him about this. But this idea that a big challenge in higher ed is this kind of layers and layers of purpose, and how those different purposes will conflict with each other often, or maybe not conflict, but it’s which one do you focus on? And this came up a bit at dinner, even not only multiple purposes, but how people define and personally define a purpose. What does student outcomes mean? So I’m curious how that… It seems like that was an idea that was kind of orbiting some of this stuff, and maybe even wrapped up in Armada’s kind of thinking there.

Jeff Grabill:
I think it was, and it did come up at dinner. So let me back up a step. So for a period of time, I was on a reasonably large writing committee for Michigan State’s strategic plan. I’m not sure whether it’s the one they still have, but it’s the one they wrote just before around the pandemic. Anyway, we would talk with external stakeholders about purpose. What is the purpose of Michigan State?
And external stakeholders were surprised at any purpose that wasn’t education or that didn’t foreground education. So most of the public doesn’t really see the research purpose, for example, of a research university because they didn’t necessarily experience it. But if you talk to academics at a research university, it is the primary purpose. They are primarily there to do that kind of intellectual work. They do the education work too, but they often see it as a zero sum game. The more time I spend on education, the less time I get to spend on my research.
And that’s a very real tension inside universities, and that’s just with those two purposes. And when you start to layer on all the ways in which universities have become social service institutions. We have students who are homeless. We are their home. We run giant food service operations. We have performing arts venues. We have community engagement programs. We provide a set of services in every community that we’re in. If we’re unfortunate enough to be in a big athletics conference, we run professional sports franchises on the side.
That’s the accumulation of purposes that tends to weigh down universities. One of the things that’s been really interesting about the pressure that the Trump administration has put on universities is it has caused universities to go back to basics, and say, look, we do research and we educate, and we’re going to try to focus our energies on those two things. And that’s not a bad return to focus and purpose.

Douglas Ferguson:
Yeah, that’s fascinating. You also mentioned this idea of blueprint, and maybe there isn’t a blueprint. We’ve been noticing a lot that industry folks are struggling with the fact that there’s no model to follow. And that is, I would say, at high levels of the organization, and all the way down to the individual level. We just haven’t developed these ways of working, these patterns. Folks have done agile for years, for example. But now AI is shifting things, and so they can’t reach out for the Spotify model or these examples. We can just run that play and do it again. And so I think everyone’s in this moment of redefining what it means to work, what it means to show up and exist in these systems.

Jeff Grabill:
Well, and this is why I’m hoping that, and this gets into your area of expertise, you’ve talked with Eric about this, I keep waiting for higher education, my business, to discover design and to discover facilitation and relationship to design because we just haven’t. This is a moment of real uncertainty. The patterns don’t work, our analogs don’t work particularly well. And so all of my instincts are that we design our way through them.
And it’s kind of what we tried to do in some… So we designed an interaction for two days to try to produce an outcome and a set of relationships and a set of conversations. I really do think that wise organizations and wise institutions are going to lean into those design practice. And if they don’t have a design practice, partner with people like you who can help them develop a design practice.
I keep waiting for higher education to… We did it at Leeds at scale. They’re still doing it at the University of Leeds at scale, but it’s really hard to develop design capacity inside a university organization and get people into that mindset that this is the way in which we’re going to come up with some provisional answers to who we think we are and where we think we need to go. Because as was said at the meeting the last two days, the only thing we can’t do is everything that we’ve done in the past just as we’ve done it in the past.

Douglas Ferguson:
Yeah. And you hit the nail on the head with the word mindset. And I would argue that it’s not just difficult in universities, it’s difficult anywhere where the mindset doesn’t exist or hasn’t taken root because then you’re talking about real behavioral change at a deep worldview perspective. We have to shift how people think about the world, or think about work, and we have to shift, and it’s happening fundamentally. They’re relearning, they’re reshaping things, and that takes time and commitment.

Jeff Grabill:
Yeah. And it gets back to something that was also true or said in the meeting. And I used to say this at the University of Leeds all the time, and it drove people nuts until they experienced it over a couple of years, that you have to move fast and slow at the same time. And it’s possible to move fast and slow at the same time. And some of that means sprinting to get some activation energy, but nobody can sprint all the time. And so there’s a fast moment. And then getting it right is something that we can do slowly if we’ve started and we have some rhythm and some pace in the work that we do.
So I’m a big believer in designing ways of working inside universities that allow us to move fast and slow with really intentional different modalities. Let the virtues of university slowness work its way out. But within those long, loopy cycles, let’s use some fast moments to have some activation energy, some pace, some rhythm to get us through the moments where we get stuck because in an institution that tends to move slowly, when we get stuck, that quickly becomes sort of catastrophic inertia. We just never move again.
And so developing some ways of working which are different for higher education, not different for some organizations, that allow us to leverage the virtues of slowness, but be able to move at a different speed when we need to. For us at Leeds, that was the key. And I’m really curious to see whether we use that as a way of thinking our way through this AI moment because we’re making it up as we go along, and that’s not the worst thing in the world if we’re intentional about it.

Douglas Ferguson:
Yeah. I had already kind of bookmarked the word intention because you mentioned that earlier, so I love that you came back to it. And that points to the fact that this is a design challenge. Design is just being intentional about what we do. It’s taking a step back and looking at it. And I would argue good design also includes it’s human centered and brings everyone into the conversation so that we can be thinking about the broader impacts and how systemic things might be.
And the other thing that came to mind for me when you were talking about the slow versus fast is often people think of them as just opposites. I’m either slow or fast. But thinking about how we intentionally design slow moments versus fast moments, and also taking, I love the martial arts mantra of slow is smooth, smooth is fast. And so sometimes we need to do slow things so that then other things become fast. And I think that’s where, you look at a design sprint, there are moments specifically designed into that protocol where we’re going to slow down with each other so that then the follow on work, we can move very rapidly on because we have high degree of a confidence in it.

Jeff Grabill:
Yeah. And that also accommodates… One thing that’s true about a university is, and it’s true probably of most organizations, but universities have, well, I don’t know, we just have a broad spectrum of cognitive styles and dispositions. And that’s also a strength of how people think together. Let’s stay with the sprint. Some of what happens in the sprint is just too fast for people. They need time to disconnect, they need time to think, they need time to process.
And so there’s the moment where you try to slow down within a sprint, but I also think we need some post-sprint space as well for us to not over-engineer what comes out of that sprint and be intentional as well about the reversibility about where we landed in that sprint. And then give some people some time, but not too much time, to think and to dwell and to walk around with it. There’s a long bit of intellectual history of discovery which includes walking. Newton and many others. The relationship between a long walk and a scientific breakthrough is a long one.

Douglas Ferguson:
Absolutely. Yeah. And the other thing that came to mind when you were talking about taking time to think is the fact that whenever we’re working visually together, as we go off and diverge and think about things, the visual prototypes give us an anchor so that we know that we’re at least in the same vicinity, our vectors are aligned, so that then when we start to diverge, we know we’re diverging from the same place. And there’s a lot of power in that, our ability to move more swiftly later because then we’re not way off track when we try to reintegrate later.

Jeff Grabill:
Yeah, that makes perfect sense. Can I ask you a question?

Douglas Ferguson:
Oh, please do.

Jeff Grabill:
Yeah. So I’m interested. We haven’t had a chance to talk about this notion of the new friction. This is the podcast container. And you talked about the friction moving a little bit. It once was here and it’s moved there. Could you unpack what that means? Because I’m also trying to listen to you in relationship to where that friction might be moving in higher education, and whether it’s the same or different, but I wanted you to unpack that a little bit more so that I could listen to you a little bit. Is that fair?

Douglas Ferguson:
Yeah, that’s totally fair. And in fact, it’s funny, that was the next question I was leading up to, just waiting to see when the conversation naturally got there. So perfect. Yeah. So our argument lately, or we kind of developed a thesis around this idea of the new friction. And on the surface, you might look at how AI is making things so easy to create and build and make things that it’s eliminated that friction or it’s eliminated friction in general. Because that was kind of the main friction people would run into, especially in industry. It was like, oh, we need to make a strategic plan. We need to make a blog post. We need to write some software. The LLM is very powerful at helping us do those things, draft them, refine them, bring new thoughts to the table, et cetera.
And so even though it eliminated that friction, or definitely smoothed out a lot of that friction, it sort of reallocated the friction across the org. It introduced new frictions, or it highlighted old frictions that have always been there. We often talk about friction or dysfunction in an org that was kind of just existing on the sidelines, or we could hide it in the margins, but now we can’t ignore it anymore because literally we can make things so fast that now all this dysfunction around decision making, alignment, actually discernment, coming together and actually disagreeing, like creating space so we can disagree, a lot of organizations fail at that.
What we were remarking around the success of your meeting, a lot of organizations are horrible at creating disagreement in a healthy way, that healthy conflict that’s so important. And so my vantage point and stance is that we should be attending and taking note and inventory of the frictions that matter now. It could be old frictions that we kind of ignored. Which those are the hardest ones to diagnose because we’ve lived with them forever. We kind of accepted them as normal. And so it’s easy to discount them.
But we should be noticing new frictions that are emerging that were never there before. And an example of that is it’s so easy to go generate, let’s say, a strategy doc or a new design brief. And once you create it, it comes out looking finished. It is so polished. It is so done. It is immaculate and beautiful and gorgeous. And it’s using turns of phrase, or just really like, I would say intoxicating, right? And then folks see that and they go, “Oh my gosh, this is like, okay, dusting off my hands, job done.” And they tend to throw it over the fence or put it in the repository. And things are stacking up and stacking up and piling up and piling up. And there’s no time for disagreement. There’s no time for discernment and is it the right thing? Are we headed in the right direction?
And so it comes back to your point around intentional slowness. Even though the speed is, I’m going to use the word intoxicating again, we shouldn’t do speed at all costs. That shouldn’t be the posture that LLMs can just make us fast. Well, how can we direct it towards something that’s of more value? And so it’s somewhat diagnosing the frictions that have always held us back, but are now getting amplified by this AI amplifier, and new frictions that it’s creating. My hypothesis is that it would also be heavily prevalent in universities too because I think it’s maybe a principle of how this technology is going to just impact humans.

Jeff Grabill:
No, that makes perfect sense. Yeah. Because it made me think a little bit about some of the relatively, well now very early research on AI and productivity, so year, 18 months ago, which measured productivity mostly in terms of the frictionless way of making things. It made a certain employee more productive because they were faster. They could make product, but it wasn’t necessarily better product. And I think that that’s where it shows up.
So the best example, and this also came up in the meeting, and I think this is the primary friction point right now in education with regard to AI is what will this do to learning? And to put it on the back of an envelope, there’s no learning without effort. And so effortless productivity, for example, effortless productivity is not going to produce learning. It’s just not going to happen. And so when you have students who can effortly produce a beautiful document, they might have produced a beautiful document, but they haven’t learned anything because it’s frictionless.
So I think one of the things that’s very true about education is that there has to be friction. There has to be failure. Students have to fall down and skin their knees. A good teacher is going to engineer friction. And a good teacher’s also going to pick students up when they fall down, give them a chance to reflect on… I used to write assignments that students couldn’t do. And the students who were doing a bad job with the assignment just sprinted off and started doing it. And the students who did well with the assignment came back to me a day later and asked me questions like, “What? What? I don’t think we can do this.” And I would say, “Thank you.”
And the whole point was to get them to ask the right questions when they’re given an ambiguous ask, as opposed to running forward and trying to do it. And eventually everybody would get really frustrated and everybody would fail and everybody would fall down. And we’d pick them up and they would learn a lot from that. And so that was exceptionally useful.
So that’s the friction now in education is where’s the friction located? Because friction isn’t bad. It’s actually quite productive. And so the friction used to be here in education, and in most educational contexts, the friction is now somewhere. And I think educators are really struggling about where to design friction in the educational environment. The irony of all of this to me, who spent 20 years, 20, almost 30 years thinking about education as well as my research, is that the thing that’s going to pull us through it is the thing that we know how to do really well.
We know how to design really effective high impact learning experiences for students. We know how to do friction well. The problem is that in the worst of our learning environments, and if we admit it to ourselves as educators and universities, we have a lot of frictionless learning environments right now, and they’re being destroyed by AI.
And so this was a theme in the meeting. We don’t have to invent new ways to solve this problem in higher education. We know what to do. We just have to do it in a different place than we used to do it. So there’s both a really interesting, there’s hope there, but it is also, for people like me, there’s real frustration because the answers to the AI friction problem, if you will, are in front of us. We’ve known them for a very long time. We just have to get educators to spend the time and energy to engage in them.
And that’s the problem. Because what’s happening right now in education, on the education side of higher education, is that AI is causing us to spend more time and energy on education than we’re used to spending and that most faculty would like to spend on teaching. And so this will be the tension for higher education is do we get people to spend the time and energy for the next couple of years to sort this out? Because we can and we will. The faster we do that, the better and happier we’re going to be as faculty and the more productive and happier our students are going to be, which is another design problem.
So how do we focus the intention of the organization with intention to get in a room or two and solve the problem and iterate on the solutions over the next couple of years? That’s the right way to do it. The wrong way to do it is to get on social media and moan and wring our hands and try to do the things in the future that we’ve done in the past because AI has eaten homework and we’re going to have to sort that out. Does that make any sense?

Douglas Ferguson:
Absolutely. And you’re making me think about how there’s this conversation around the importance of critical thinking as being a really important skill of the future as it relates to leveraging AI and making sure we’re preparing people just to be good stewards of this technology and preparing them for just living in the future.
And then there’s debate of what is critical thinking? And it’s like, how do you define it? And as you were talking about your professors being gifted and skilled at creating friction, specifically friction that creates the best learning moments. And I started to think about how, in a way, if you could define critical thinking as individuals starting to internalize this idea of the friction that helps me learn and how do I intentionally introduce the friction that helps me learn? And so if you develop as an individual those skills of being able to inject that at any moment.
And so I wonder if there is a… Well, I personally find it fascinating to use LLMs to help me create friction. And the research world of AI, they refer to that as adversarial. You could use an agent to be an adversarial agent to critique and break down the work that was generated by another agent. And there can be layers and layers of adversaries looking at things from different vantage points.
But at the same time, when we’re talking about bringing it into AI Team moments or even Copilot moments, we can ask the LLM to bring in friction rather than to generate things. How is it helping us slow down and think and inject some perspectives or just some skepticism around what we’re trying to accomplish? But the thing I don’t know, and probably would require more research to prove out, is if the LLM is doing that, does individuals witnessing that and receiving those questions and that pushback help them internalize that behavior more, or do they just become reliant on that?

Jeff Grabill:
Well, I mean, there’s so much in there. So one of the areas in which I’ve worked for a long time, and we’ve spun some technology out of the research center that my colleagues and I had at Michigan State. So we had a company for roughly 15 years. We have a software service that scaffolds a feedback intensive pedagogy. And it’s really simple. And one of the principles though is that human beings learn as much, in some cases maybe perhaps more, from giving feedback than from receiving it. But they do learn from receiving feedback. But nobody learns anything unless they, on the receiving side, get some instruction in how to process feedback.
Because this gets to the growth mindset whole there is an emotion and a cognition component of receiving feedback. And so helping students learn how to receive feedback is an instructional need and an instructional task for professors in any discipline. Critiques in art and in creative writing programs can be brutal. And if you don’t help students emotionally and cognitively learn how to receive that feedback and put it to productive use, it could be the best feedback in the world, but it’s not going to make a difference.
Conversely, you have to teach students how to give feedback. And when you do that, you teach students to read in particularly intentional ways. And to put whatever they’re looking at, whether it’s a schematic or a poem or a report or a piece of art, to put that performance, that object, in relationship to some criteria. And when they do that thoughtfully with some intention, they learn something about what they’re also trying to do because they’re trying to do the same thing.
And then when they have to formulate that into feedback that is also useful, it’s criterion referenced, it has some connection to what their colleague is trying to make or do or perform, and to then to craft it in such a way that that other human being can accept it from them, that’s real work. That’s friction. And those two learning modes can happen at the same time in a human intensive feedback moment. Now, these machines can give us feedback too, and that’s useful, but we still have to help human beings understand how to receive that agent provided feedback, how to engage with that agent provided feedback. There’s some metacognitive work in there.
So I think a really rich learning environment in the relatively new future is going to be a mix of agent interactions and human interactions and human to human interactions. All these ratios we can play out. I think that can work. I think I’m getting a little bit tired of the human in the loop metaphor, but we’ll use it, but not asking humans to do that work and just relying on agents to do that work, I think, again, is one of those instances in which that’s frictionless and we probably don’t want that.
To add another layer, and then I’ll stop talking, you’re good at designing agents. I’m not. But I want to get good at designing agents. And we’re going to have to teach our students, as we move from chat to agents, one of the places in which some friction is going to be located is the design of agents themselves, and the kind of intentionality and thoughtfulness that we put into that and how we learn from that.

Douglas Ferguson:
Yeah. And I think that’ll get easier the more abstraction layers that get added there. And when people build harnesses that allow people to conceptualize these things more easily, or that are aligned with models that they have already existing in their worldview. Because if you think about in the world of agents, it’s sort of like managing a small team. And so once the harnesses are starting to take on some of those perspectives, or maybe others adjacent perspectives that make it easier to understand and easier to approach, but if I had to guess today, taking the hiring metaphor, and this came up at dinner too, it’s like, how do you hire agents? So it comes down to like what’s the job description? And then how do you think about what’s required of them to do great work, and then how do you measure that great work and how do you delegate tasks in an efficient way? If those problems are well-defined and solved within the harness, I think it becomes a lot easier for people to understand how to employ an agent.

Jeff Grabill:
Yeah. How important for you is it to understand what’s going on with that agent or to understand something about the construction of a harness for you to understand what the agent’s really doing and not doing? Because sometimes it’s what the agent’s not doing that’s as interesting as what an agent does. Does that make sense as a question?

Douglas Ferguson:
Yeah. I think as someone who’s just eternally curious, it does fascinate me how the LLMs come to their conclusions and whatnot. But when I put on my business hat, and I’m CEO of Voltage Control Douglas, some of that doesn’t matter. It’s like, did I get the result that I needed? Did I learn something critical? Did it make me realize something new, a gap that I was missing?
I have a chief of staff agent, and one of the things the chief of staff agent does is it looks over everything that happened in the prior week. So all of our meetings, everything in the calendar. We do our strategic meetings in a Miro board. So that Miro board is consumed as well as all the Slack messages that we’re sending back and forth. And it builds up a list of all the important themes, as well as any potential gaps we might be missing, to make sure that when I go into the strategic meeting with the team, I’ve got a list of things that I need to be concerned with.
And the interesting thing about that is I don’t just use that as the agenda, but it often surfaces things that it’s fallen off my radar. Much like a great chief of staff would say, “Hey Douglas, don’t forget about X, Y, and Z client.” And then it’s like, “Yeah, we need to make sure we resurface that.” And so that’s, as far as how it’s functioning, and I’ve even run into some issues with that. And I had another LLM actually fix the issues. So rather than me going in and updating the prompts, I had my developer agent go in and correct that routine that the chief of staff is running.
And so I care less about the prose that’s in that prompt and I care more about the outcomes that we’re driving for the organization when I’m purely in the CEO hat. But of course, my computer scientist, like internally curious Douglas, often looks under the hood because I’m like, “Hey, how’s this working?” I want to tinker with it for sure.

Jeff Grabill:
Yeah. So this tension sort of came up in the meeting here at Buffalo for the last two days about the alignment of incentives in an organization like yours and the alignment of incentives in an organization like mine. And if it works, and this is not a criticism, but if it works, you’re really happy with it because it helps you with the bottom line incentives. And then for me, we might care less about whether it works and more about peering under the hood and making sure that we’re curious.
And I think that’s a really, this another thing that I learned yesterday listening to my colleagues talk about why it’s so important to build these things, and that we would build them differently for different purposes and different organizations. And peering under the hood is a really good idea. But also the fact that we can peer under the hood is a really important, that has to be true, that there has to be some traceability and visibility in terms of data and operations. And we have to be able to see under the hood.
Anyway, I’m rambling a little bit, but it’s interesting. I’m glad you’re curious. But some of our students are not curious and they need to be. And so another place in which we need to engineer some friction is we need to say, “No, I need you to peer under the hood and tell me what’s inside and tell me what you understand about it.”

Douglas Ferguson:
Yeah. It’s sort of like coming back to the age old show me your work. If you can’t justify it, you need to understand some of the underpinnings here. And I think the thing where it comes up the most for me is if I’m using it to help me draft things, then it surfaces up some new thought that I haven’t seen before, especially on content side of things, then I’m really digging in and going, okay, where did that come from? Where’d you come up with this? Because I want to, A, make sure it didn’t hallucinate, but also I want to understand the sources. And I think that’s not a technical under the hood. That’s more of a under the hood of the where’s this coming from and where’s the real knowledge?

Jeff Grabill:
And it’s a really important displacement. So at the end of the day, I’m a writing teacher. And one of the ways in which effort in activity is going to be displaced in how we teach people to write, which I hope we still do, is, for example, writing teachers used to spend a fair amount of time with certain writers in their classroom at the sentence level, just helping them understand why these sentences are not grammatical English or don’t work particularly well. And that’s valuable work. You don’t have to do that with all writers, but we would always have to do that with some writers. We shouldn’t have to do that anymore.
And writing teachers are noticing this in universities that they’re getting writing now, this came up also in the last two days in our meeting, they’re getting writing that at the sentence level is lovely. There’s nothing for them to do. And in fact, just as there’s no reason for a student to turn anything in for the last 15 years with a spelling error, there’s probably no reason for a student to ever turn anything in from this point forward with a syntax problem. But this writing can also be completely devoid of ideas and wrong.
So that’s where the effort is. And that’s an okay place to have effort. And that’s how you develop expertise. And it’s also a reason why knowing something about something is really important. I was talking to somebody at the meeting about the advice I gave to my kids when they went away to college. And the primary bit of advice was study something you love, period, full stop. That’s the most important thing to do. I don’t really care about anything else, but you have to study about something you love.
The secondary bit of advice was it’s a good idea to know something about something. So my preference was that they chose something that had some intellectual depth and history to it. So none of them were philosophy majors, but I would’ve been thrilled. I got an anthropology major, and politics, philosophy, and economics majors and thrilled. I mean, they know something about something. And that’s a durable good. And that was a big thing that came out of our meaning as well.

Douglas Ferguson:
I was thinking about this not that long ago, this idea of like, I wonder where the anthropologists will go in this world of AI, where they’ll take their thinking and research. Because I think there’s a lot to be done there. I’m waiting for it. But we’re kind of running up on time here.
I’ve got two things I wanted to end with. One was you quoted Punya Mishra, the technology’s impact on education has been modest, but its impact on society has been profound. And you argued that education has a mandate, a remit to prepare people for society and understand society and reflect it back. And so I’m curious, just any thoughts you have for our listeners just around that idea, and how AI is definitely going to reshape society.

Jeff Grabill:
Yeah. No, I was reading some… Punya’s at Arizona State. He’s clever, he’s engaging. If people are interested in education and technology, they should find Punya. So I was looking at an article that Punya and a couple of his colleagues have written. And this is true. Those of us who pay attention to technology and education know that Silicon Valley’s been trying to disrupt education for the last 20 years. And they never really do because the impact of technology has been modest on education. The television was supposed to disrupt everything. The computer was supposed to disrupt everything. The internet was supposed to disrupt everything. We’ve absorbed them and made them useful.
What has disrupted education is society. Society moves, and education has to adjust to it. Punya and his colleagues made the argument that the impact of technology on society is more profound than it is on education. And it is. It’s society that we respond to, not precisely the technology that we respond to. That seems right to me.
And I think that for those who are interested in technology and education, it’s something to think about. I mean, I’ve been rolling my eyes for a long time about technology disrupting higher education. And most of the Silicon Valley people who are trying to do this don’t understand education as a business and they don’t understand it as a cognitive and emotional activity, and therefore they always miss the mark. But I think Punya and his colleagues have it about right.

Douglas Ferguson:
Yeah. I think we’re on the precipice of seeing big societal change, especially I mean, next week there’s the big Apple event, and my speculation is that we’ll see an announcement around Gemini and Apple. And if Gemini truly replaces this… I mean, if Siri goes from being a third grader to being a PhD student that you’re talking to, that experience of actually transcribing your voice correctly, and being able to actually do things right there on the phone, people’s access to this stuff is going to just explode astronomically, and that’s going to have a huge societal impact.

Jeff Grabill:
I think so.

Douglas Ferguson:
Overnight, I think.

Jeff Grabill:
Yeah. No, and that’s how it works. Remember the camera on the phone? I thought that was the most ridiculous thing in the world. It wasn’t.

Douglas Ferguson:
Yep. Changed the course. So I want to leave you with one final one. You’re talking about AI doing the writing. And certainly there’s lots of universities. I think this even came up in the meeting. It’s like, you have to use AI, but don’t use it for your coursework or you’ll be subject to a review board. And I love this one. I think one of the panels, or one of the breakout working sessions when they were doing readouts at their tables had shared out this idea of I don’t care if AI created it. I care if it’s true. And it just hit me across… It was like slapped across the phase. I was like, “Oh my gosh, I love that they said that.” And to me, it was just undeniable. You hear it and you go, yep, that is such a good perspective and I hope that more people adopt it.

Jeff Grabill:
Yeah. I was at that table, and the woman who said it is a librarian. And it’s exactly what she said. She said, “At the end of the day, as a librarian, it has to be true. It doesn’t necessarily have to come from a human being.” And that’s going to be a big shift for us because we’re very deeply human people in libraries, but I think that that’s where we need to land. I was struck by it too. And for our table, that sentence, we wrapped in lights and sprinklers and confetti because we thought it was a winner as well. It’s a really interesting insight, isn’t it?

Douglas Ferguson:
Yeah. And it’s so simple. And I think that some of the best insights are profound in their simplicity.

Jeff Grabill:
No, I agree. They cut through it, don’t they?

Douglas Ferguson:
Yeah. Amazing. Well, as we leave our listeners, is there anything that you would like to offer them up as a final thought?

Jeff Grabill:
Yeah. I mean, your listeners, you have some educators in your audience, but mostly not. And so I guess my ask is sort of the ask of the meeting, and that is wherever you dwell, there’s probably a university or two around. If it makes sense for your business, or if it makes sense for how you choose to spend your time as a human being, your universities, trust me, they want your partnership. We’re trying to sort this out. We’re trying to do the right thing with your children and your grandchildren, the students in your community. For you, we’re trying to do the right thing for you.
And so if the universities aren’t smart enough to ask you to help them, if you want an act of generosity on your part, knock on their door. Particularly if you have something to offer in this space that we’ve been talking about. And see if there’s an opportunity for you to partner with the universities in your community so that together we can think our way through where the friction ought to be and how the friction has moved around, because I think it’s a really important question.

Douglas Ferguson:
Yeah, I love that invitation. And if folks aren’t familiar with how universities are structured, is there a role or individual or title that would be the best target for industry to reach out to?

Jeff Grabill:
That’s a really great question. We are completely impenetrable organizations.

Douglas Ferguson:
The fortress.

Jeff Grabill:
We are a fortress. We’re like a Hydra. Who knows? So it’s not obvious. So I might start with a creature called the provost. If you have a relationship with your university where you give some money, you probably have a development officer. You can always ask your development officers, “Hey, can you connect me to this person or that person?” And if you don’t have a dean of Arts and Sciences, find the creature at that university who’s the closest thing to a dean of Arts and Sciences and write them and say, “Hey, I heard this dean of Arts and Sciences saying that I should write my dean of Arts and Sciences if I wanted a conversation.” And hopefully one of those people in the Hydra will respond to you. But the development people might be the best ways because they certainly want to nurture that relationship and they will make the connections for you.

Douglas Ferguson:
Amazing. Well, Jeff, as always, it was a pleasure chatting. I learned a lot, and I think our listeners will really appreciate the time. I would just say, really impressed with all the great work and please keep it up.

Jeff Grabill:
Douglas, it’s always a pleasure to talk with you. You and your organization do really special work. So thanks for the invitation. It was fun.

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 Engineering Friction: What Higher Education Knows About AI That Industry Doesn’t appeared first on Voltage Control.

How AI Is Quietly Breaking Your Senior Bench

“We’re worried because there are fewer entry-level jobs right now, and in five years, there will be fewer intermediate or senior-level designers. There’s going to be a gap.” That is a working landscape architect, one of 722 interviewed for a new Cornell study presented at the BIG.AI@MIT conference last month. The quote is not about a dystopian future. It is about what the practitioner is watching happen, month by month, in her own firm. The headline narrative on AI and work is about entry-level job loss. That is real, and it matters. But the more consequential story, the one that is almost invisible in quarterly earnings calls, is quieter and slower: the people who would have been senior in five years are not getting trained now. The junior did not lose the job. The junior lost the reps.

What the study actually found

Jose Antonio Guridi and Cristobal Cheyre, researchers at Cornell, spent the last eighteen months studying how landscape architecture firms across North America are adopting generative AI. They did 25 semi-structured interviews, spent time observing operations at a prominent firm, and ran a survey of 722 practitioners. That is one of the largest datasets on AI adoption in a real profession that has been published. Three findings stand out. First, the adoption is uneven in a specific pattern. Juniors are driving it. Seniors are holding the judgment that decides whether the AI output is right. In firms that have not designed for this reversal, the junior uses AI to produce something the senior reviews. The senior edits the output. The original work the junior would have done, the intermediate steps where skill used to form, quietly disappears. Second, most of the adoption is hidden. 73% of the practitioners who use AI at work do not disclose that use to their firm. They use personal devices. They treat restrictive firm policies as an obstacle to route around rather than a signal to stop. The work gets done. The firm does not know how. Third, the firms that are handling this well have all done the same thing: they have made the adoption explicit. Structured workshops. Shared documents. Senior oversight built into the workflow, not as policing, but as a design feature. The distinction between the three patterns is where the story is.

Passive, hidden, explicit

Guridi and Cheyre name three adoption patterns. Each one produces a different organization five years from now. Passive adoption. AI arrives through software updates. The design tool adds a new button. The email client starts suggesting full paragraphs. The research database surfaces AI-generated summaries above the actual sources. Nobody decided. The practitioners absorb the change as background noise. Skill formation is whatever it would have been, minus the steps the software now does automatically. Passive adoption is the modal case. Most organizations are in it right now and do not realize it. Hidden adoption. The firm has a restrictive AI policy. The practitioners need to produce the work anyway. They open ChatGPT on their phones, paste the brief, and keep the output in their personal notes. They know they are not supposed to. They do it because the alternative is not doing the job. The 73% disclosure-gap statistic is this pattern, captured at scale. Hidden adoption looks like conformity from the outside. From the inside, it is an underground apprenticeship running in parallel with the firm’s official one, except the underground one is entirely unsupervised and invisible to every senior person who might intervene. Explicit adoption. The firm has decided, out loud, how AI fits into the work. There are designated workflows where AI is expected. There are designated workflows where AI is not welcome. There are senior reviews built into the AI-assisted paths, not as gates, but as teaching moments. Juniors get exposure to the AI-generated output. They also get exposure to the senior’s reasoning about why the output is right or wrong. This is the only one of the three patterns that preserves apprenticeship.

The mechanism: where the learning moments go

A team of economists at MIT, Yale, and Microsoft, led by Mert Demirer, gave this phenomenon a structural name. They call it AI chains.

An AI chain is a sequence of production steps in which each automated step flows into the next without a human in the middle. Verification happens once, at the end of the chain. The economics are obvious: verification is expensive, so fewer verifications are better. Organizations will push toward longer chains whenever the AI is good enough.

The consequence is that jobs where AI-suitable steps sit next to each other are the jobs where chains form fastest. Research, drafting, and rendering are adjacent. So are summarization, synthesis, and first-pass review. Chain the three together and you have converted what used to be a six-hour junior assignment into a thirty-second prompt and a five-minute senior review. The efficiency gain is real. So is the apprenticeship cost, which does not show up anywhere on the quarterly report.

In landscape architecture, Guridi and Cheyre watched this happen inside the firm they observed. Rendering production used to be the junior’s job. It was slow, iterative, and humbling. You started something, showed it to a senior, received criticism, started again. After two years, you had internalized the senior’s taste. After five years, you had your own.

The rendering step is now in a chain. The junior writes a prompt. The AI produces four variations. The senior picks one and edits it. The junior has watched, but has not done. The internalization does not happen the same way. The taste does not form. One practitioner put it to the researchers this way: “If you’re using something to generate everything, you miss all of these moments to be iterative and review your own work.”

The pattern is not unique to design. In May 2025, Moderna’s Chief People and Digital Technology Officer Tracey Franklin described to the Wall Street Journal a system of more than 3,000 internal GPTs, including a broad HR GPT that routes employee questions to specialized GPTs for performance management, equity, and benefits. Her own description of the workflow: “It’s like your virtual HR, AI agent. It’s what would normally be a junior-level HR analyst type, we’ve now converted into a GPT.” Same chain. Different industry. The intermediate work that an HR analyst would have done on the way to becoming a senior HR partner is gone.

Why executives don’t see it

The reason this pattern is so hard to see at the executive level is structural. It is not a failure of leadership attention. It is a failure of legibility. The metrics you have are the metrics that matter. Revenue per employee. Project cycle time. Client satisfaction. None of these show apprenticeship. All of them might actually improve in the short term when AI chains form, because the outputs ship faster and the staff count drops. The disclosure gap compounds the invisibility. 73% of AI users are hiding the use from the firm. Senior leaders cannot see what they cannot see. The firm’s governance layer is responding to a world where AI use is still occasional. The actual daily reality has moved past that. And the time horizon is precisely the wrong length. Five years is long enough that the consequence is somebody else’s problem, probably the problem of whoever succeeds today’s CEO. Five years is short enough that the seniors who exist today will still exist and can still cover the gap, right up until they retire. We name this pattern “Experience Starvation,” after the term coined by Gartner’s Tori Paulman at last year’s Digital Workplace Summit. Experience starvation is what you get when the workflow around the AI strips out the intermediate work the junior used to do on the way to becoming the senior. The organization continues to function. The talent pipeline quietly thins. Paulman’s framing has a sharp corollary: AI is not taking entry-level jobs. Senior people are.

What the firms getting it right are doing

The explicit-adoption firms in the Guridi study are not slower. They are not abstaining from AI. They have just designed the adoption so that apprenticeship survives. The most teachable pattern in the research is one Paulman calls the Option 3 workflow. It has three moves. The expert builds the template. The senior practitioner, who has the taste, captures her reasoning in a reusable form. The template is the artifact. It encodes the judgment. The rookie executes with AI. The junior runs the template, feeds it the project context, and gets the output. They see the template working. They see where it breaks. They do the adaptation work the template did not cover. The expert reviews the insights. The senior does not edit the output. The senior reviews the judgment the junior exercised when the template was not sufficient. The feedback is on reasoning, not on rendering. The workflow preserves three things at once. The firm gets AI leverage on the routine work. The junior gets exposure to the senior’s reasoning, not just the senior’s output. The senior spends her scarce time on the decisions that only she can make. This is what Guridi and Cheyre observed in the firms that were explicit about their AI adoption. It is not a program. It is a set of working conventions that the senior partners enforced because they had decided, out loud, that training the next generation was part of the firm’s product. The firms that had not made that decision were not using any of this. They were using AI chains that removed the work and the learning together.

What to do this month

Three moves that do not require a transformation program. Make disclosure safe. The 73% who hide AI use are not malicious. They are responding to incentives you set. If the penalty for disclosing AI use is higher than the penalty for hiding it, you will get hiding. Change the incentive. A one-line policy update (“we encourage AI use in designated workflows; here is how to propose a new one”) can move the whole distribution. You cannot design around a pattern you cannot see. Route some work through juniors even when AI could do it. Not all of it. Some. The criterion is whether the work teaches something the junior needs to know in five years. If the answer is yes, the junior does it. The efficiency loss is the training budget, reclassified. You are already paying for training; now you are spending it on practice instead of on certificates. Audit your senior bench replacement rate. Not headcount. Replacement rate. For every senior who will retire or exit in the next five years, who is on track to replace them? If the answer is “unclear,” you have the gap already. The only question is whether you find out now, when you can still do something, or in three years, when your best seniors are announcing and the bench is empty. None of these require new hires. None require new tools. They require the decision to design for apprenticeship at a moment when every incentive is telling you to optimize it away.

What is at stake

The five-year gap is not a forecast. It is a trajectory measurement. The apprenticeship loss is happening now. The consequence is scheduled to arrive in 2030\. The organizations that will have the senior bench they need in 2030 are the ones that decided, in 2026, that apprenticeship was a design problem. They built Option 3 workflows. They made disclosure safe. They kept routing work through the junior even when the AI was right there and faster. The organizations that will have the gap in 2030 are not doing anything wrong, exactly. They are optimizing for the metrics they have. The metrics they have do not measure apprenticeship. Apprenticeship erodes silently. By the time it shows up as a capability gap, the people who could have been trained have moved on to firms that trained them. The juniors are not losing their jobs. They are losing the work that would have made them senior. That is a different problem, and it hides better, and it bills later.

Ready to close the gap?

If your organization is watching AI chains form and is not sure whether apprenticeship is surviving, three places to go deeper. Talk to us. We help leadership teams design the workflows that keep AI leverage without losing the learning cycles. Learn more Our pillar page lays out why apprenticeship loss is one of the new frictions AI has relocated into the center of your organization. Build the capability. Our facilitation certification teaches the skills senior leaders need to run Option 3 workflows at scale.

Frequently Asked Questions

Is AI taking entry-level jobs?

The headline narrative says yes, but the more consequential pattern is different. AI is enabling senior workers to do entry-level work themselves, which removes the on-ramps for skill development. The junior role often still exists; the work that used to fill it has been compressed into AI chains. The Cornell study of 722 practitioners shows this pattern clearly. The junior did not lose the job. The junior lost the reps.

What is experience starvation in AI adoption?

Experience starvation is a term coined by Gartner’s Tori Paulman to describe the systematic removal of the low-stakes, high-repetition work that builds professional judgment. When AI handles the steps where skill used to form, the junior misses the iterative cycles that produce taste. The organization keeps shipping. The talent pipeline quietly thins. By the time the gap shows up, the people who could have been trained are five years past the moment when training mattered.

How does AI break the apprenticeship model?

AI chains the production steps where junior workers used to learn. Research, drafting, rendering, review: each one used to be a discrete moment where a junior practiced and a senior critiqued. When those steps chain together, the junior writes a prompt and the senior edits the final output. The intermediate work, where taste forms, disappears. Most organizations have not noticed because their metrics do not measure apprenticeship. Cycle time and revenue per employee actually improve in the short term.

What is the Option 3 workflow for AI in the workplace?

The Option 3 workflow, also from Paulman’s research, has three moves: the expert builds a reusable template that encodes her judgment, the rookie executes the template with AI on real project context, and the expert reviews not the rendered output but the reasoning the rookie applied when the template was insufficient. It preserves AI leverage on routine work while giving juniors exposure to senior reasoning. It is the only workflow pattern in the Cornell research that survives apprenticeship.

How do you protect your talent pipeline from AI-driven erosion?

Three moves: make AI disclosure safe so you can see what is actually happening (the Cornell data shows 73% of users hide their AI use from their employers); route some work through juniors even when AI could do it, with the criterion being whether the work teaches something the junior needs in five years; and audit your senior bench replacement rate, not headcount but replacement rate, so you know where the pipeline is actually broken before it shows up as a capability gap.

The post The Five-Year Gap appeared first on Voltage Control.