Want this content delivered right to your inbox?

Subscribe to the Newsletter

A conversation with Peter Bell, founder of Gather.dev and author of Scaling AI Adoption in Engineering

“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.” – Peter Bell

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.

Listen on Apple Podcasts
Listen on Spotify
Watch on Youtube

This episode is part of the Facilitation Lab Podcast. See all episodes

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

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.