Want this content delivered right to your inbox?

Subscribe to the Newsletter

A conversation with Alyssa Coughlin, Director, Chief of Staff for the Data, AI & ML Platform organization at Autodesk

“AI will not take your job, an engineer who’s better at using it will.” – Alyssa Coughlin

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

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

Alyssa Coughlin on LinkedIn
Voltage Control

About the Guest

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

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free. So why are organizations still stuck? Because the friction didn’t disappear, it moved and it multiplied. It’s no longer in building, it’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore, the conversation before the work is. That’s the work this show is about. Today, I’m with Alyssa Coughlin at Autodesk, where she is the chief of staff for the organization that builds the data and ML platforms and agentic AI infrastructure. Welcome to the show, Alyssa.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Douglas Ferguson: Right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alyssa Coughlin: Way less sweaty.

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

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

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

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

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