73: Charting an Adaptive Path toward AI Transformation

May 16, 2026

73: Charting an Adaptive Path toward AI Transformation

Show Notes

In this episode, Peter and Jesse compare notes from on how AI is reshaping design teams. The conversation moves through the operational chaos of proliferating tools, the urgent need to articulate a value proposition, why design operations got cut right before they were needed most, and the window of expertise power that won’t stay open.
For more about Peter Merholz, his consulting, thought partnership, and teaching offerings: https://petermerholz.com/
For more about Jesse James Garrett, and his AI transformation and leadership coaching offerings: https://jessejamesgarrett.com/

Transcript

Jesse: I’m Jesse James Garrett,

Peter: and I’m Peter Merholz.

Jesse: And we’re finding our way,

Peter: navigating the opportunities

Jesse: and challenges

Peter: of design and design leadership.

Jesse: On today’s show, Peter and I explore the emergent challenges of AI transformation for digital design teams. I’ll share insights from my seminar of the same name and compare notes with Peter on the larger trends we’re seeing. We’ll get into issues like renegotiating your cross-functional relationships and your value proposition, the cultural implications of running a team where everyone has their own custom tools, and just how long to hang on to people on your team who don’t want things to change.

Peter: Hello, Jesse.

Jesse: Hello, Peter.

Peter: What’s up?

Jesse: I thought it would be useful for us to get together and reflect a little bit on this last series of conversations that we’ve been having because for better or worse, there is one topic that is front and center in the minds of design leaders these days, and that is AI. How AI plays out in their products, how AI plays out on their teams, and how it impacts how design interfaces with the entire larger organization that it’s a part of.

The Burger is Real

Jesse: On this show, it has now been the better part of a year since this started dominating our conversations, going back to our conversation with Andrew Hogan back last August, talking about what he was finding out about AI adoption through his work leading research for Figma. Since then, we’ve talked with bunch of folks that are people who have been well-known to you and I for a long time.

People like Christian Crumlish, Christina Wodtke, Jorge Arango, Paul Ford, Dan Saffer. People who’ve been really immersed in this work for a while and who have seen this cycle turn a few times. And we have been talking with them about the ways in which this current cycle evokes and reminds them of the cycles of change that we’ve seen in the last 30 years or so.

And we’re also talking about how this time is different. And I’m curious where your thoughts have landed about those questions and what really genuinely is different this time? You know, Jorge brought up the idea that a lot of people are looking at this and questioning whether there’s a there there, you know.

And it has been reinforced through the conversations we’ve been having that, as Jorge put it, this is not a nothingburger. This is a burger.

Peter: Aha!

Jesse: And that has implications. And I’m wondering, reflecting on the last several months of these conversations for you what are the patterns that you think leaders need to be paying attention to as they are trying to guide their teams through this change?

Peter: You and I were part of a conversation last week that Jeffrey Veen instituted called the Design Futures Assembly, a half-day set of conversations and presentations on the intersection of AI and design, with some very heavy hitters in the room: OpenAI, Anthropic, Google, Microsoft, Figma, Adobe.

Also, I’m doing what I’m calling a listening tour of design executives trying to get a pulse check of what they’re thinking and feeling in this moment. And so I’m bringing that to bear. And it’s not a nothingburger. Definitely a burger.

And even if it was a nothingburger, the way people are acting, you can’t ignore it, right?

There’s something there. You have to, engage the…

Jesse: perception, if not the reality, right?

Peter: The perception and just the overwhelm or something, right? There’s just so much about it. You can’t ignore it. The thing is, what is it? I think it’s an interesting question.

And what I’m making of it, what we’re gonna definitely see, is how design operates will change. That is becoming truer, at least. That is changing.

I just had a conversation with a VP, we’ve heard variants of this story recently, where they have their own Git repo’s. They’re committing to prod, right? We’re collapsing the distance between the work of design and the work of development.

But there’s a potential risk when this happens, where when design gets associated with production, which has been the overwhelming mode for the last 15 years, the next step is to think you can automate design away because it’s more straightforward to automate production.

Three kinds of designers

Peter: The conversation I had with this particular design leader was interesting to me because she has, well, three types of designers in her team.

Design strategists who were loving this. They’re able to imagine futures, visiontype, but do it in ways that feel more real. Quickly build things that you can put in front of users, get that user input, iterate. It’s just this unlock for these more strategic designers who are quite generalist in terms of strategy, research, content, design, to, with just one, maybe two of them, just do a lot more than they could have ever done before. So that’s at one end of the spectrum.

On the other end of the spectrum were designers on her team that also wanted to play with code, but maybe in the past couldn’t quite get there. They probably built their own prototypes and stuff in code. But now, with these tools and technology, they’re in code, they’re partnering directly with engineers. They’re able to kind of bleed into that realm. So it’s a different kind of generalism, right?

You have design strategy as more of this, let’s call it first diamond generalism, and I don’t know if she had a term for it, but let’s say the kind of design technologist as the second diamond design generalism.

And what she pointed out is, there is a population in the middle that’s getting lost. Like she wanted to make it clear that it’s not all wine and roses, that there is a population getting lost.

But something else that she did, actually, that I think you would appreciate based on the talk you gave last week about AI transformation. As it was becoming clear that AI was going to be important, she took two people on her team and turned them into a AI enablement squad. They got removed from their product work and their job was to figure out how this team was going to embrace AI, figure out the tooling, figure out matters of process, figure out how do you get repos, be the bridge to engineering, talk to them, understand what all those things are.

And that ended up spurring the creation, essentially, of this platform design team that’s dedicated to UX excellence. So if it’s not AI, it’s design systems. If it’s not design systems, it’s defining quality, right? She’s realized there’s a role there for this team, even beyond AI, to help set standards for how the team operates.

And I say that as a story. You know, it’s clear that the edges of design practice are blurring, and there’s a lot of opportunity for design to evolve and blur into those edges. And that is the part that, I think, is the burger, is navigating these adjacencies.

At least– It’s a big part of the burger for me.

Jesse: Yeah, I would say there are two things that stood out in what you talked about. Last week I did this online seminar that I called AI Transformation for Digital Design Teams, where I talk about the patterns and the strategies that I’ve been employing in my work as I’ve been helping teams and supporting leaders in developing strategies for tackling all of this stuff.

And you touched on a couple of things that I think are really key from what I’ve seen. First of all is, like you gotta clear the decks for somebody, whether that is leadership within your team, whether those are, again, like maybe the principal IC level might actually be a sweet spot where you can really offer an opportunity to people in the organization to leverage their hands-on skills in ways that can benefit a larger organization.

But if you don’t have the ability to clear the decks for people and get them engaged with a team like you’re describing, then to bring in a fractional leader from the outside, somebody like me, who can take a view of all of it and get it all organized for you, can really help to accelerate things.

The second piece of it, though, which I think is really key, is that the opportunity is not just to do what you’re already doing better. The opportunity is to take a step back and look at what design is and means for an organization and how this tooling can support that.

Articulate a value proposition

Jesse: And I think that the challenge and the opportunity for leaders is to apply a bit of a quality filter to all of this technology that’s being thrown at them and to ask themselves, “How is this supporting the value proposition that my team already has in place and/or How does this support the extension of my team’s value proposition towards something new, towards something bigger, and towards something that is maybe having more impact than we’ve ever had before?

Peter: You said the words value proposition. You said the phrase, “How do I use this to act upon the value proposition I already have in place?” It turns out, I would argue, most design teams haven’t articulated their value proposition…

Jesse: oh, sure. right?

Peter: I suspect it’s those teams that are having some of the biggest struggles right now, ’cause they don’t know to what end they would be adopting this.

It’s just whatever they’re doing, keep doing more of that faster, as opposed to this one leader that I was talking to, you know, there had been some strategic mandate, there had been desires for vision, there had been a recognition of how this group can be maybe more horizontal, looking across an end-to-end experience, while, you know, product and engineering is more vertical, focused on specific applications.

I was surprised how energized this leader was when I was talking to them about AI, but I think it was because they had conditions, right? They had the conditions in place to enable flourishing with these new tools and approaches.

Whereas I suspect most design organizations lack those conditions to enable that flourishing.

Perhaps an… adaptive path?

Jesse: Yeah. So one of the things that I called out in the talk that I did was just the fact that every company is gonna have its own unique path toward how this new tooling gets implemented, because every company is bringing its own legacy into it. The ways that things have been done in the past, the expectations have been placed on design teams in the past, the data structures, the decision-making structures, the organizational structures that constrain what’s possible within any given context.

And I think that’s a big piece of the task for leaders, is to figure out what’s actually gonna work here, as opposed to what works at the big companies in Silicon Valley or what works at the little startups in Silicon Valley or, you know, what’s working for our competitors or what is the standard that’s been set within our particular product category or industry segment.

But to ask ourselves based on what we have in place, because I think your point is right on. If you don’t know what your processes are It’s gonna be really hard to upgrade those processes in any kind of consistent way to incorporate this tooling. If you don’t know what your value proposition is, if you don’t know what the expectations are that your cross-functional partners are bringing to the table, you might be investing a whole bunch of energy in AI initiatives that have nothing to do with what is actually being asked of your teams.

And so for the leaders, the responsibility then becomes, again, to be this filter, to be the evaluator of where these investments make the most sense and deliver the most value and deliver the most impact both within the teams and cross-functionally.

Peter: You said something along the lines of every team charting their own unique path. You might call it an adaptive path.

Jesse: You might call it that, yes.

Peter: But, one of the risks, I think, of the direction that you’re suggesting, is that every organization starts building digital product differently.

In some ways, it sounds great. Purpose-built, totally bespoke, this process for this context, this company, this time, dial it right in and boom, they can just flow.

And that sounds good in some theory, but it doesn’t allow for mobility, interoperability, translation. And so if I’m a designer who’s working in a team that’s operating in its own unique way, and then I get reorged, and we know this happens all the time, and I’m now reorged into a team that operates totally differently, they charted their own unique path, now I have to spend a lot of time figuring out how I work there.

Whereas a year ago, by and large, design worked the same in most contexts. Used the same tools in roughly the same order.

One of the things we’re hearing now is not just the proliferation of AI-empowered tools that are out in the world, Figma with Figma Make, or Lovables and Cursors and Replits and v0s and Claudes and all that kind of stuff.

But I’m talking to design leaders who are like, “Oh, yeah, and we’re building tons of custom internal tools to solve problems that we have.” Which sure, ’cause of Claude, it’s relatively cheap and easy to build internal tools. But then you leave your company and you go to work for someone else, and they have a totally different internal tool suite that has nothing to do with the kind of internal tool suite you learned…

Jesse: right.

Peter: are you spending three months before you’re useful in this new context?

That doesn’t make sense to me, right?

And so I foresee some shaking out of some patterns, some stable patterns of ways of working, and input and output of tooling.

Jesse: I can see that. At the very least, I think that you have to have two things. You have to have consistent internal expectations just to be able to compare the work of different designers across the team and be able to evaluate who’s actually delivering and who is bringing a sophistication of craft to their work.

And then secondarily, there are those external expectations, your cross-functional expectations, your expectations at the executive and leadership levels, your expectations with your business owners that also have to be managed in here.

And you’ve touched on one of the big open questions, which is, like, how standard can it get while still embracing the inherent flexibility of the new tooling itself, which is literally a world where software costs nothing, a world where you don’t need to figure out how to build the custom tool.

You don’t have to get a developer’s time to build the custom tool. All you have to do is describe the outcome that you want, and a robot will make it for you. I think that fundamentally changes the role that software itself plays in people’s workflow.

Peter: We are in a very active period of discovery about exactly this, right? The more I think about it, the more I talk to folks about it, it’s not just about design when we’re talking about digital product.

It’s design connecting with product, connecting with engineering, possibly other teams, right? The workflow is not just one function, it’s a cross-functional workflow. And if, the design team has some combination of seven to 10 externally created tools plus 10 to 20 internally created tools that they’ve got going on, you could multiply that by all the other teams, and it starts getting out of hand.

But it’s a bit like that university landscape that was part of the inspiration for the name Adaptive Path, where, like, we’re seeing the paths people are laying down, and the ones that work are the ones that people continue to lay down, work on, and then we’re gonna pave those, right?

Those are probably the, some of the next big product opportunities.

Jesse: Mm-hmm.

Peter: There will probably be some shakeout where it’s not as rigid or as constrained as it had been a couple years ago where workflow processes were broadly assumed.

But I don’t foresee a chaotic future of ways of working ’cause that… I think there’ll just be too much organizational resistance to allow that to happen.

Jesse: Yeah. It’s not scalable in a couple of ways. It’s not scalable from an orchestration perspective, and it’s not scalable from an operational perspective. You know, this was the big question that I brought to the floor at the Design Futures Assembly last week. I was asking, what are the operational implications when every designer is creating their own flavor of prompt chain that helps them to get to a particular result?

How do you operationally assume or assure any kind of consistency across, especially across a very large team, where you’re potentially looking at, you know, there are teams out there of more than 1,000 people now, right? Design teams.

We cut operations just as we needed them most

Peter: Yeah and for me, this is something I literally just wrote about earlier this week in a newsletter titled “The Overlooked Solution to AI Confusion.” That overlooked solution is design operations, right?

Jesse: Yeah.

Peter: I think a lot of teams wound down design operations,. I mean, I’ve literally had a conversation with a different company where I was talking to the lone remaining design operations person, whereas a few years ago there were four, now there’s one.

And I think that’s a pattern that happens in a lot of places, because starting in 2023, belt-tightening, do more with less, layoffs, whatever, it’s easy to let go of your operations people because they’re not builders. They’re not delivering direct value.

It turns out, though, that they are exactly… You know, your whole talk on AI transformation, which suggests in part a transformation team that sees the organization through, that transformation team is, you could call it an operational team. It’s not 100% operational, but 50% to 75% operational.

Jesse: It has a significant operational function, for sure. Yeah.

Peter: Yeah, when you talk about communication, coordination, planning, ways of working, those are all operational matters. Process improvement, tooling, those are all operational matters.

And it’s like we got rid of operations right before we needed them most.

Good work, everybody.

But, you never want operations to run things, and my ops friends might object to me saying that, but I believe it to be true.

And that becomes a problem, right? In agile transformations, you know, you bring in all the agile coaches, you bring on scrum masters, you bring on some flavor of program manager or whatever that assists with agile.

And now all of a sudden, no team can do anything until those operations folks have allowed it to happen, right?

That’s not what I’m talking about here, and I think that’s where a lot of antipathy towards operations comes, is what sometimes happens is operations shifts from being an enablement to a…

Jesse: compliance.

Peter: It becomes governance in and of itself, right? It’s not enabling governance across, it’s “We are the government.” Yeah, and that’s no go.

But any organization that’s going to effectively embrace these ways of working is either going to have to bring on operations folks or, to your point, retask individuals and give them an operations mandate for some period of time.

We were talking about prior models and there was this whole industry set up to support agile transformations, with, again, agile coaches and scrum masters and all this kind of stuff.

Which was good for a while, but then we kind of lost the plot, which was that those jobs were always meant to be temporary, until the teams could do it themselves. But, “temporary,” like, that’s just not a word that lands in most organizational contexts. And so you had these folks sticking around long past their due date.

And so, my thought here is, like, you need to set an expiration date.

Jesse: Yeah, I can’t remember which organizational thinker said that bureaucracies exist to sustain themselves, but that is basically the idea. That once you have roles in place they’re gonna seek ways to continue to make themselves relevant or prove that they should be relevant regardless of as you put it, their expiration date.

I think the challenge with that when it comes to AI is nobody can see the top of the mountain yet, you know? Nobody can actually see at what point we get to the other side. It is just climbing and climbing. And as the mandate for this foreseeable future is climbing, you’ve got to optimize for climbing the hill, moving into the unknown collectively as an organization, as a skill set for yourself as a leader and for your team as a collective.

Peter: So do we need AI sherpas?

Jesse: There is an element of that, for sure.

Peter: You were, you know, talking about one of the challenges with AI is we don’t know how high the mountain is. You could imagine there was a similar challenge… Like with agile transformation pretty soon we knew how high that mountain was. Turns out it was pretty fucking low.

But I could imagine, you know, if we had applied our way of thinking in the mid-’90s, we wouldn’t have known how high that original UX design mountain was, right? It took actually a number of years. In fact, we helped start a company in part to do the survey of the mountain, right? To figure out the shape of that.

And when we started Adaptive Path in 2001, user experience was already a thing for about five or six years, not broadly, but it existed. Now clearly AI has spread like wildfire in a way that UX did not back then. It can take a while to understand the shape of something.

Gardeners and head coaches

Peter: I’m finding metaphors interesting right now, more interesting than I have in a while because I think they can give us some frames of reference, the blind men and the elephant, what is the shape of this thing, right? We’re all kind of picking at our part, but we’re having trouble seeing the whole.

I’m preparing a talk for an internal session right now, thinking about leadership in this moment. And I’ve got two metaphors that I’m currently playing with and both of which are about the act of setting conditions, right?

So I said earlier that setting conditions is kind of my frame of mode, right? I think we, when we think of design leadership, we tend to think of it as an active role of setting direction. This is what good looks like. This is quality. This is the vision. Let’s move toward that.

I’ve always believed design leadership has been more about setting conditions than delivering direction. I think that’s become irrefutable right now.

And I think what we’re seeing with AI is there’s just too much going on for any individual to set direction of.

So then if the challenge is to set conditions, create conditions, I’ve got two metaphors I’m working with.

One is that of a gardener, right? As a gardener, you are understanding your soil, understanding your sunlight, understanding your climate, so that’s the context setting. You are planting seeds. You have a vision for what you want in your garden. Is it gonna be a pretty flower garden? Is it gonna be a vegetable garden? Is it gonna be a bit of both? Is it gonna be landscape? So you have some vision of what you want.

You plant the seeds. You water or pray for rain. As things grow you encourage, you clip here, and you prune there, and you put up a trellis to get it to grow in that way, right?

But you’re never telling that one flower, “Be like this.” The flower knows what it’s going to be, but you’re creating the conditions to enable that garden to emerge in some way that you imagine… though possibly not, right? You know, there’s, I’m sure some improvisation in gardening. So that’s one metaphor.

The other is being an NBA head coach. And I think about this because it’s an analogy I used in the org design book, ’cause we talked about Steve Kerr. So before Steve Kerr joined the Warriors, good team, playoff team, but they never got past the second round. Steve Kerr joins the Warriors, pretty much the exact same players, and his first year, they win the championship.

He set a different set of conditions than the prior coach. He created a different operating model in terms of literally how they played on the court, but also how they worked behind the scenes. He brought joy. This is one of his kind of prevailing values, is joyfulness in work. And, you know, by changing the conditions for the same set of people, got a different and better outcome.

And the reason I think about head coaches, though, is, like, they’re not players. They’re not on the court. They’re not doing the thing. They’re trying to set it up, but then at some point you kind of have to step back and let the team make its way there.

The other reason I like the head coach analogy, is that we often tend to think that our design leaders have to be the best designer in the room. The head coach, Steve Kerr, was never better than the eighth or ninth best player on any team he ever played on. He was never the best player. He had played with Michael Jordan. He was far from being the best player, right?

And I think there’s something to remember that leaders don’t have to be the best practitioners. They have to be the best at getting the most out of those practitioners, and we lose sight of that, particularly in design.

Jesse: I think one thing that you touched on within this that I think is really important, and I think honestly cascades from the highest level decision-making all the way down to individual designers trying to deliver against individual requirements, which is that the introduction of this technology introduces an essential role of probability management on everybody involved.

That it’s no longer about perfect replicability and getting your systems so dialed in that you are getting exactly the same product off the assembly line every time, because that doesn’t play to the strengths of the technology. Playing to the strengths of the technology means creating space for variation.

It means creating the opportunity to pursue directions that might not actually ultimately work out. Which means that in a lot of cases, folks who came out of general assembly 10 years ago who were like, “Okay, here’s your tech stack and here’s your process, and now you can go get a job, and you can have this same set of expectations no matter where you land.” That stuff just straight up doesn’t apply anymore.

And the varying levels of maturity that you’re gonna see across these organizations are, in a lot of ways, going to be driven by the maturity of their leaders and the maturity of their expert-level practitioners who are going to provide that perspective that the leaders can’t get on their own.

Because to your point, they shouldn’t be knee-deep in the tools because they’ve got to be going to bat for the teams and what the teams need.

Peter: It’s funny though because… when you said that leaders shouldn’t be knee-deep in the tools, something I’m hearing from these design executives, not uniformly but mostly, is all of them feel like they do need to get into the tools in a way that they haven’t for the last, even, 10 years.

I talked to one leader who’s “Yeah, I never used Figma. I, you know, would go in there and make comments, but I couldn’t auto layout my way out of a paper bag. The last tool I used was Sketch or even Photoshop in terms of making designs, right?”

VPs who’ve had that mentality now are like, ” Oh, I gotta open up Claude Code. I gotta play with Lovable. I gotta build now in a way that I haven’t.” Which I find interesting, and I’m actually still coming to terms with that as someone who hasn’t been in the tools for a very long time.

Jesse: I think it’s necessary to be conversant with the technology in order to make informed judgments about how to deploy it. So as I talked about in the AI transformation talk, as I talk about with my clients, I think it is important for leaders to come to the table with a point of view on how this technology is best applied, where it really makes an impact, where it really makes a difference, and what we want to preserve of the human influence within these processes.

But I don’t think you can get there if you haven’t been at least a bit hands-on with it.

I guess that the thing is that I wouldn’t want leaders to think that their role is now kind of orchestrating this multi-variant operational condition-setting machine, because you can’t direct the design to the same degree that you used to be able to.

But you still have to provide for some variation and some context specificity within these design processes to enable designers to go their own way here and there, you know?

And that becomes a part of the organizational culture, that becomes a part of how people think about design.

Return to the Wild West

Peter: Some of the people who are navigating this best are folks who’ve been around a while and who came up in early web, 1.0 in the mid to late ’90s. And I think it’s in part because that was also a bit of a Wild West. There was no, I heard the phrase for the first time last week, “go-to tech stack.”

There was no go-to tech stack. We didn’t really have a process. We were making it up as we went along. The technologies were variable. There was an explosion of tools. There was something similar in terms of that environment, but also from specifically a design standpoint, what’s interesting to me about this is there were those of us who were web native who recognized you could not lock down the presentation layer in a web browser.

But then I worked with many trained designers who all they wanted to do were put up giant GIFs because they wanted to maintain the typography and the color scheme and the brand and all that. And that’s not this medium. That’s a different medium, right?

And we got away from that, right? You know, by the early 2000s, those designers with their giant GIFs let go a bit. There were things like Flash that allowed maybe some tighter controls, but we were in a fluid area for a while.

And then I think essentially with probably these frameworks, your React- type frameworks, as well as just mobile design and development, for the last 15 or so years, we’ve gone back to, you know what, I, as the designer, can actually specify the pixel perfect experience that every customer is going to have in an identical fashion. I can lock that down.

And now to your point with AI, all that’s taken away if you wanna lean into this material, right?

One of the talks at the Design Futures Assembly was from Josh Clark and Veronica Kindred. They have a book called “Sentient Design,” and the mindset behind it is what does it mean when AI is the material?

And to your point, when AI is the material, it’s not something you lock down, right, going back to the gardening metaphor. It’s this thing that you’re like shaping some conditions and seeing what happens, and what happens might be better than what you could have predicted.

The last 10 to 15 years where as you said, you know, you could learn in a boot camp how to do this work. That was for a material and a mindset that we’re not in any more. in

Jesse: Doesn’t exist anymore. Yeah.

Peter: But the other thing that you said, you used the word orchestration, and that’s a word that I’ve been coming back to.

You gave a talk at an UX Week or something in 2008 or ’09, where you defined UX design as orchestration, right? Not detailed delivery, but how do I bring together all this stuff?

And I think design leadership is once again going to have to adopt an orchestrative mindset, not like a conductor necessarily, “You, that violin need to play that note in exactly that way,” but that there is this altitude that we’re operating at, a higher altitude of coordination of elements that are meant to work together, and the job of the designer is to influence that, shape it.

Not shape it like a sculptor, but nudge it. And also this is where the gardening metaphor comes back. There’s feedback loops, right? And you see something, and then you do a thing. You prune it here, you nudge it there, you do a thing. So it’s not always on shaping, it’s responding to the system as it evolves.

Jesse: You know, I have to say I am hearing the voice of one of our listeners, I don’t know who, but somebody out there who is thinking right now all of that is well and good, but I have no authority. The shape of my team’s work is basically constrained by the expectations of our cross-functional partners.

And all anybody is asking me about or looking for or talking about with regard to my team is delivery. And I think the question for somebody like that in that position is: How do you start to evolve both your team and the expectations around your team toward a different value proposition?

‘Cause it seems to me that’s what you’re suggesting, right? That a delivery-oriented team is going to have to find new ways to deliver value. Is that– Do I have that right?

Peter: Yes, either a delivery-oriented team is going to have to articulate a new value proposition or maybe, as we said earlier, articulate a value proposition. I think…

Jesse: to begin with, yeah.

Peter: many delivery-oriented teams have inherited their value proposition from their product leader or engineering leader or whomever they report to, as that’s the value they are delivering.

They’re gonna have to get out in front of and be intentional and mindful in the creation of a new value proposition.

You were asking earlier what’s new, what’s not. This is one of those what’s not, right? Like basics of leadership, and one of the basics of leadership is having a vision, having an agenda, having an idea of what is the change that you seek and articulating that, right?

And that doesn’t change just because it’s AI. You just need to apply that leadership practice to this moment.

What is the change you seek? If you’re a delivery-oriented org and you realize that you have two paths ahead of you.

Getting much smaller because much of that delivery can be handled by the robots. I was talking to someone who, their design systems team is turning into a UI infrastructure team, which is just gonna be in engineering. That’s just an engineering function now. It’s not even a design function. Maybe there’s some designers on the team, but they’re approaching it with an engineering mindset.

So that’s one path, and if you’re fine with that path, great. But if you’re not, then you need to articulate what change you seek, what potential you believe that you have in terms of positive impact within the organization you’re in that aligns with desired value as articulated by your leadership, and start doing the work of your team is delivering on that desired value.

Who’s not on the bus?

Jesse: You know, one thing that has come up in my AI transformation work that I have heard from other folks as well that I think is a really important theme to consider in here is that everything that you’re describing assumes that the team is ready and willing to come right along with you and support that vision, you know?

And for a lot of designers, and honestly, I think it in some ways this afflicts the more junior designers more than the senior designers, although there are maybe different flavors of it, they don’t want this change. They don’t want different tools. They don’t want different processes. They don’t want to rethink their value proposition. They have the job that they wanted, you know?

And now you’re telling them that they don’t get to have it anymore. And so another thing that I think we’re gonna see, especially within design organizations, although we might see this more broadly beyond design, is a bit of a cultural schism between the people who are ready to embrace new tooling and the people who are pretty comfortable where they are and feel like they’re delivering plenty of value doing exactly what they’ve been doing.

And for leaders both from an operational as well as from a cultural perspective, they have to set a tone that is inclusive enough to cover that whole spectrum.

Peter: It has to be inclusive enough to cover the whole spectrum, but do you believe it is acceptable for some designers to remain intransigent?

Jesse: I think every organization is gonna reach that point by its own path. In some organizations, there’s gonna be a lot of tolerance for continuing to do things in old ways, you know? And it’s like that print shop that has that one computer back in the corner that still has the CRT because it’s the one that the guy who runs the shop trusts and knows how to use and doesn’t need anything different. And maybe everybody else around him is using some other kind of tooling to do their jobs.

But, I think you’re gonna see… kind of a long tail to this, where you’ll have a few organizations that are at the very front of the pack that are very aggressively in with the new, out with the old, churning their processes to arrive at some new patterns and some new paradigms and some new form of consistency.

Because I agree with you, It feels like we’ve gained too much, in the last 25 years, operational wisdom to just throw it all out because we’ve got new tools now.

But then I think, further down the tail, you’re gonna have a lot of organizations that are gonna live in this kind of hybrid space for a while, where there’ll be a few people who are embracing certain kinds of processes, and maybe other people in other parts of the organization for whom, you know, we only see an incremental gain from you taking up new tooling, and you’re doing perfectly fine as you are, and so we don’t need a new anything here.

And there are a lot of organizations that’ll be making that call probably for years to come, you know?

Peter: I find myself wondering about that if only because the conversations I’m having. So with this listening tour, when I talk to these VPs or chief design officers, if they’ve got, let’s say, 100 or fewer designers, all of them are expecting their entire teams to become IA-enabled. AI-enabled.

And in fact, one of the conversations I had today was with a design leader who’s like, “Yeah when it became clear that there were some folks who weren’t on the bus, they were shown the door.” Yep.

Jesse: I’m not saying that won’t happen and isn’t already happening, but based on the conversations I’ve been having, I’m not aware of a lot of organizations that have seen enough gain from new tooling, new processes to actually justify those kinds of cuts.

Usually, those kinds of cuts are coming about because they had other reasons. They had already overreached in their hiring in some meaningful way, and people are looking to this as almost like a preemptive strike to cut the team before it gets to a place where you’ve got a lot of extra people hanging around that you’re trying to figure out what to do with.

Peter: Yeah and as I say that, I’m not saying it because it’s what I want or necessarily what I think is right.

I’m just, thinking about these conversations, and I’m realizing that most of the design leaders I’m talking to are like, “Yeah, not only should my teams be AI-enabled, resistance to AI enablement is an indication that that person is probably not right for my org.”

Not even because they won’t use AI, but because it’s suggesting some incuriosity or intransigence or just some other kind of personality characteristic.

Jesse: Attachment to an identity, attachment to a kind of a craft.

Peter: Whereas I do think what you were talking about will likely persist in some organizations, but I suspect that in much the same way that every design team adopted Figma, were more than happy to get the hell out, first out of Photoshop and then out of Sketch, and they adopted Figma because they saw the value in it.

It probably them a little while. I’m sure there were teams that were like, “Wait, I don’t want PMs all up in my business.” In fact, I actually, as I’m saying that, I remember hearing designers saying, “I don’t want PMs all up in my business” right?

And that was the risk of Figma. “They’re gonna comment on my files.” But now it’s just an assumption and it’s fine. It’s fine.

And in fact, design was the entity that drove that adoption. Even now in organizations, you know, we have a shared friend, Z, the design ops leader, who’s like, “Yeah, my design team uses Figma less than product and marketing.” We drove the adoption, but now other teams actually see more value out of it.

I suspect that AI enablement will eventually be adopted in a similar way by design orgs. I don’t know exactly of what, but it will be seen as an absolute good. I’m sure there’ll be benefits and drawbacks, but in the calculus more benefits to drawbacks, and that any resistance to AI will be organizational, right?

So at the Design Futures Assembly, we had an old friend there who works at a giant bank, and he’s like, “In no way on planet Earth or throughout the galaxy will they ever let designers commit to prod at this bank. That is just not a thing that’s gonna happen.” Cybersecurity, info security, compliance, regulatory issues, et cetera, et cetera. The amount of effort it would take to get designers up to snuff for code- committing like that’s not worthwhile, right? That’s where it’s more likely for the constraints and barriers to be, than inborn of design practice.

Jesse: Yeah. And I think that’s part of the long tail effect that I was talking about. You know, each organization’s legacy and constraints are going to dictate where you fall on that tail in terms of how far toward new tooling you have permission to move, how much latitude you have cross-functionally as well as with your business stakeholders and people like policy and compliance and regulatory and all those kinds of things.

Different organizations are gonna find themselves in different places, and that’s why I think that this adaptivity ultimately ends up being not just a core skill for leaders to thrive, but a core skill for their entire teams to thrive as well.

And I can see, to your point about if they’re not curious about how to evolve their practices, let them go, right? This suggests that the culture of design teams going forward has to be one that is more experimental, that is more driven by individual inspiration and vision, that is more exploratory in finding new tooling, finding new techniques, finding their way to do this work.

Peter: It’s funny as you say that ’cause again, this feels like a throwback to me. I’m like, “Oh, 2003 called and wants its design profile back.” And I don’t disagree. The responsibility of the leader is to then make the space to allow that to happen, right?

‘Cause right now, I think a big reason for burnout and for anxiety and for whatever problems you see bleeding through spaces like LinkedIn or various design meetups is, even before AI, designers were overtaxed, spread too thin, supporting too many PMs, given too much to do, and as a result of a lot of that, found their value narrowed to a production or delivery mode, ’cause that’s the one kind of touchpoint between their work and the rest of the organization that people recognized as worthwhile.

And now, all of that is still true, and we’ve just layered on, “By the way, figure out this AI stuff. Peace be with you.” And they’re overwhelmed with which of these 15 tools do I use and in what combination? And this is your argument for AI transformation teams and practices and processes.

But like even when we get kind of over that hump, you know, this is a drum I’ve been beating for probably 25 years, which is how do we make work sane? When I was young and I worked in what I would now probably think of as moderately insane organizations, I was young and so I didn’t know any better, and I was willing to be insane.

And then, I was 28 when we started Adaptive Path, and one of the core operating principles of Adaptive Path was a sane working environment, right? That’s not necessarily what people outside the company understood. They thought it was about great user experience and…

Jesse: I’m not sure that’s what all our, people would agree that we created.

It was definitely an ambition.

Peter: You posted about the 25th anniversary. There were comments from Adaptive Pathers of days of yore who were like, “That was the best work environment I was ever in.” And that was something we were very explicit about creating, which was you can do great work without running yourself ragged, right?

And that, for some reason, is some revelation. It shouldn’t be. There’s no reason for most of these organizations that they operate the way they do, except that they don’t know any better or they just think in order to work, people have to be working 50, 60-hour weeks now.

They have to be always on. They have to be willing to respond to emails you know, nights and weekends and all this kind of stuff. And it’s like that doesn’t…

Jesse: 9-9-6, baby.

There’s

Peter: no evidence that 996 delivers better work, and in fact there’s evidence that it doesn’t. Evidence that, like, 35 to 40 hours a week turns out to be an optimal amount of effort. And when you ask people to work more than that, the quality of the work beyond that suffers such that then they have to work more to undo the bad work they did when they were overtaxed, right?

And so when you talk about experimentation and exploration, that requires leadership to fight for a sane working context that enables folks to do that kind of exploratory and experimental work.

Jesse: Yes. Yeah, I completely agree with you. In the talk, I refer to this as air cover.

Basically, this is the leader setting the context, both within their teams and again, cross-functionally and with the leadership about the ways in which their processes might not look like what they used to look like, and letting everybody know that you’re embracing a culture of adaptivity, and that’s gonna have consequences for how the team shows up.

One of the main reasons that I am advocating for design leaders to spin up these transformation teams and transformation initiatives is that by giving it this dedicated focus, by clearing the decks for a few people to really focus on driving these things, you can give it that extra level of attention that is not just about technology policy and not just about process, but about culture, about how the humans in the organization engage with the work, and what keeps those people engaged with the value that is actually being delivered by the larger team.

And in a lot of ways, what this is, is it’s not just about a culture of experimentation. It’s not just about a culture of exploration. It’s also about a culture of reflection and prioritization and a kind of ruthless evaluation of what’s working and what isn’t, so that you can scale those methods in meaningful ways.

And I don’t see how you can do that given the mandate of the leaders that most organizations already have in play, right? There’s just not enough space if you don’t dedicate somebody to it.

Peter: I was thinking about something Marty Cagan said at an internal presentation he gave at a company that was one of my clients. And this is a company that was trying to embrace a kind of product transformation, agile transformation. Not scrum transformation, but, let’s embrace dual track agile, let’s embrace product discovery, let’s build product the right way. What has kind of been conceived as the right way.

And the thing that Marty pointed out is that the single biggest constraint to that transformation does not come from product, design, and engineering. They do have to change how they work and there’s gonna be some resistance ’cause there’s always resistance to change.

But by and large, those teams get it. They’re like, “Yeah, we want to work this way ’cause we know what it unlocks.”

The biggest constraint to their ability to succeed is everyone else. And it’s how does finance think about funding models for teams? How does HR think about career pathing and performance evaluation and compensation for teams? How does sales and marketing engage with those teams from a, say, a requirements perspective? It’s all the other functions.

And what Marty pointed out is he had never seen a truly successful agile transformation or product transformation that didn’t involve the CEO. It needed the toppest down mandate of the CEO because the CEO could tell the non-product functions, ” Hey, you’re gonna have to change.”

But if the agile transformation was only being done from the CPO down, they’re gonna continue to behave as they have, and what’s gonna happen is kinda like a kudzu. You’re gonna clear the field briefly, and then over time, the practices of those other functions are gonna push back on product development.

And it might look agile. They’ll adopt agile rituals, but they’re gonna be behaving as they always have because of the larger forces at play. And so that’s to the point we were just making about experimentation and exploration. That’s the risk for AI transformations, is how are the rest of the organization reshaping their ways of working to enable that productively?

Jesse: And the leader’s gotta be managing those expectations, right? The leader has got to be the bridge between functions that helps those on both sides understand what each is bringing to the table, and what each can reasonably expect of the other so the politics doesn’t go away, you know?

Peter: No, the politics are as, if not more, politicky.

Though, it was funny, I had a conversation again today with a leader whose team is embracing AI and has AI enablement and there had been a top-down mandate. It wasn’t like metrics-driven. Like it wasn’t every team needs to use 20% AI or somewhat… You know, you hear about some of these arbitrary numbers in terms of AI application.

But there was a top-down mandate from the C-suite that teams need to be AI-enabled. And this leader’s like, “Okay, let’s figure that out,” and tasked folks to make that happen. One of the things that ended up happening is, because the way this leader approached it within their organization, they got out ahead of product. Design and engineering both took a similar approach in their realms and then partnered with one another.

And design got out ahead of product such that he who controls the prompt controls the product. Yeah, where design is starting to lead product strategy because they had demonstrated expertise in this area that was considered important right now and were able to leverage that for a kind of political gain.

That wasn’t the motivation, but that ended up being the byproduct. And as part of that, at least in my conversation with this leader, this is someone who used to have a seat at the table, and then that seat was taken away because of layering that occurred a year or two ago. And now they’re slowly creeping back to the table because of the team’s ability to do good work.

Jesse: Yes.

Peter: It’s delicate because you and I encourage leaders to recognize the politics in the organization they’re in. But the reason for this person’s success is they doubled down on, “My team is gonna work really well.” So it wasn’t political. It’s “How do I set them up to, make the most of this moment?”

And it turned out others recognized that and saw the value in it, and they didn’t have to manage up. They could just do the work really well. And I wonder if there’s something about this moment right now that you might not have to be as political if you can demonstrate capability. It’s a thought.

Jesse: Yeah, I think there’s potentially a lot less political legwork involved. But I will say that the political calculus for the leader is exactly the same, which is to understand the needs and the perspective of your various cross-functional partners as well as your business stakeholders and influencers, and make sure that stuff is represented in the choices that you’re making.

But yes, what you’re describing is exactly as it was foretold in days of yore. When I gave that talk last year, it was the pattern that I was seeing, if you got there first, you were gonna get that seat at the table.

The window of expertise power

Peter: I think about power dynamics and usually what’s considered the most powerful type of power within an organization is relational power, and that’s still largely true. But there are times where expertise power matters and we’re at one of those times. That if you can demonstrate expertise, people will listen to you.

That was not true three or four years ago. If your expertise was better Figma-ing or better knowledge of your users or whatever you were an expert in, that wasn’t interesting to the people around you, and so having that expertise did not really grant you influence. But…

Jesse: right.

Yeah.

Peter: If your expertise now is AI enablement and AI ability, people will lean in and go, “Oh, really? How are you doing it? How did you do that? Let’s talk. That’s interesting.” But this will be a window. At some point, it won’t be interesting that you’re an AI expert anymore.

Jesse: That’s true. Right.

Peter: Right?

But there’s an opportunity for design leaders to leverage this moment to get a bit ahead.

Jesse: Yeah. Time to take action.

Honestly, just in the six, eight months since we started having these conversations about this topic on this show in earnest, I think the conversation has significantly shifted and it’s time to go.

It’s time for leaders to really start to figure this out because they’re gonna get lapped if they don’t.

Peter: Yeah, and as I say that, I fear for further burnout on the part of our design leaders. Take care of yourselves too.

Jesse: Yeah, absolutely. Peter, thank you so much.

Peter: My pleasure, Jesse. Thank you for spurring this discussion.

Jesse: All right, see you soon.

For more Finding Our Way, visit findingourway.design for past episodes and transcripts, or follow the show on LinkedIn. Visit petermerholz.com to find Peter’s newsletter, The Merholz Agenda, as well as Design Org Dimensions featuring his latest thinking and the actual tools he uses with clients.

If you’re looking for help with AI transformation or you just need a private advisor to help you solve your hardest leadership problems, visit my website at jessejamesgarrett.com to book your free one hour consultation.

If you’ve found value in something you’ve heard today, we hope you’ll pass this episode along to someone else who can use it. Thanks for everything you do for others, and thanks so much for listening.

Jesse: On today’s show, Peter and I explore the emergent challenges of AI transformation for digital design teams. I’ll share insights from my seminar of the same name and compare notes with Peter on the larger trends we’re seeing. We’ll get into issues like renegotiating your cross-functional relationships and your value proposition, the cultural implications of running a team where everyone has their own custom tools, and just how long to hang on to people on your team who don’t want things to change.

Peter: Hello, Jesse.

Jesse: Hello, Peter.

Peter: What’s up?

Jesse: I thought it would be useful for us to get together and reflect a little bit on this last series of conversations that we’ve been having because for better or worse, there is one topic that is front and center in the minds of design leaders these days, and that is AI. How AI plays out in their products, how AI plays out on their teams, and how it impacts how design interfaces with the entire larger organization that it’s a part of.

On this show, it has now been the better part of a year since this started dominating our conversations, going back to our conversation with Andrew Hogan back last August, talking about what he was finding out about AI adoption through his work leading research for Figma. Since then, we’ve talked with bunch of folks that are people who have been well-known to you and I for a long time.

People like Christian Crumlish, Christina Wodtke, Jorge Arango, Paul Ford, Dan Saffer. People who’ve been really immersed in this work for a while and who have seen this cycle turn a few times. And we have been talking with them about the ways in which this current cycle evokes and reminds them of the cycles of change that we’ve seen in the last 30 years or so.

And we’re also talking about how this time is different. And I’m curious where your thoughts have landed about those questions and what really genuinely is different this time? You know, Jorge brought up the idea that a lot of people are looking at this and questioning whether there’s a there there, you know.

And it has been reinforced through the conversations we’ve been having that, as Jorge put it, this is not a nothingburger. This is a burger.

Peter: Aha!

Jesse: And that has implications. And I’m wondering, reflecting on the last several months of these conversations for you what are the patterns that you think leaders need to be paying attention to as they are trying to guide their teams through this change?

Peter: You and I were part of a conversation last week that Jeffrey Veen instituted called the Design Futures Assembly, a half-day set of conversations and presentations on the intersection of AI and design, with some very heavy hitters in the room: OpenAI, Anthropic, Google, Microsoft, Figma, Adobe.

Also, I’m doing what I’m calling a listening tour of design executives trying to get a pulse check of what they’re thinking and feeling in this moment. And so I’m bringing that to bear. And it’s not a nothingburger. Definitely a burger.

And even if it was a nothingburger, the way people are acting, you can’t ignore it, right?

There’s something there. You have to, engage the…

Jesse: perception, if not the reality, right?

Peter: The perception and just the overwhelm or something, right? There’s just so much about it. You can’t ignore it. The thing is, what is it? I think it’s an interesting question.

And what I’m making of it, what we’re gonna definitely see, is how design operates will change. That is becoming truer, at least. That is changing.

I just had a conversation with a VP, we’ve heard variants of this story recently, where they have their own Git repo’s. They’re committing to prod, right? We’re collapsing the distance between the work of design and the work of development.

But there’s a potential risk when this happens, where when design gets associated with production, which has been the overwhelming mode for the last 15 years, the next step is to think you can automate design away because it’s more straightforward to automate production.

The conversation I had with this particular design leader was interesting to me because she has, well, three types of designers in her team.

Design strategists who were loving this. They’re able to imagine futures, visiontype, but do it in ways that feel more real. Quickly build things that you can put in front of users, get that user input, iterate. It’s just this unlock for these more strategic designers who are quite generalist in terms of strategy, research, content, design, to, with just one, maybe two of them, just do a lot more than they could have ever done before. So that’s at one end of the spectrum.

On the other end of the spectrum were designers on her team that also wanted to play with code, but maybe in the past couldn’t quite get there. They probably built their own prototypes and stuff in code. But now, with these tools and technology, they’re in code, they’re partnering directly with engineers. They’re able to kind of bleed into that realm. So it’s a different kind of generalism, right?

You have design strategy as more of this, let’s call it first diamond generalism, and I don’t know if she had a term for it, but let’s say the kind of design technologist as the second diamond design generalism.

And what she pointed out is, there is a population in the middle that’s getting lost. Like she wanted to make it clear that it’s not all wine and roses, that there is a population getting lost.

But something else that she did, actually, that I think you would appreciate based on the talk you gave last week about AI transformation. As it was becoming clear that AI was going to be important, she took two people on her team and turned them into a AI enablement squad. They got removed from their product work and their job was to figure out how this team was going to embrace AI, figure out the tooling, figure out matters of process, figure out how do you get repos, be the bridge to engineering, talk to them, understand what all those things are.

And that ended up spurring the creation, essentially, of this platform design team that’s dedicated to UX excellence. So if it’s not AI, it’s design systems. If it’s not design systems, it’s defining quality, right? She’s realized there’s a role there for this team, even beyond AI, to help set standards for how the team operates.

And I say that as a story. You know, it’s clear that the edges of design practice are blurring, and there’s a lot of opportunity for design to evolve and blur into those edges. And that is the part that, I think, is the burger, is navigating these adjacencies.

At least– It’s a big part of the burger for me.

Jesse: Yeah, I would say there are two things that stood out in what you talked about. Last week I did this online seminar that I called AI Transformation for Digital Design Teams, where I talk about the patterns and the strategies that I’ve been employing in my work as I’ve been helping teams and supporting leaders in developing strategies for tackling all of this stuff.

And you touched on a couple of things that I think are really key from what I’ve seen. First of all is, like you gotta clear the decks for somebody, whether that is leadership within your team, whether those are, again, like maybe the principal IC level might actually be a sweet spot where you can really offer an opportunity to people in the organization to leverage their hands-on skills in ways that can benefit a larger organization.

But if you don’t have the ability to clear the decks for people and get them engaged with a team like you’re describing, then to bring in a fractional leader from the outside, somebody like me, who can take a view of all of it and get it all organized for you, can really help to accelerate things.

The second piece of it, though, which I think is really key, is that the opportunity is not just to do what you’re already doing better. The opportunity is to take a step back and look at what design is and means for an organization and how this tooling can support that.

And I think that the challenge and the opportunity for leaders is to apply a bit of a quality filter to all of this technology that’s being thrown at them and to ask themselves, “How is this supporting the value proposition that my team already has in place and/or How does this support the extension of my team’s value proposition towards something new, towards something bigger, and towards something that is maybe having more impact than we’ve ever had before?