Finding Our Way

Show Notes

Peter and Jesse are joined by Chengying “Z” Zheng, who shares her experience migrating a design team to be AI-first — off Figma and into code. She discusses how design leadership and operations divide the work, what happens to roles and titles when everyone becomes a builder, and how to make good design easier than bad design.

Z on LinkedIn: https://www.linkedin.com/in/changyingz/
Z’s Substack: https://changying.substack.com/
Jesse James Garrett: https://jessejamesgarrett.com/
Peter Merholz: https://petermerholz.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.

On today’s show, Jesse and I are joined by Chengying Zheng, better known as Z, the design operations, or should I say experience operations leader with extensive experience in tech. She shares with us how she guided a design team through an AI transformation, setting aside Figma and building right in code, her thoughts on the evolution of roles and teams, how to maintain quality, and the new work of operations.

Hi, Zee. Thank you for joining us

Z: Thanks for having me

Getting the team off Figma

Peter: The conversation we’re having with you, for me at least, started, I wanna say, six to eight months ago, when you and I were in the offices of Figma at a gathering. There was a lot of folks there, but you and I had peeled ourself away from the crowd, and you looked at me, you looked around, you looked at me, and you said, ” It’s a little weird for me to be here because I just spent the last three months or so getting my team off of Figma and into AI tools.”

And we talked a fair bit about that. You’ve been writing about it in your newsletter, but I’d love for you to share the, the highlights of that experience. Yeah, the highlights of that experience. Explain a little bit about where you were and what that journey was like and how you did evolve a team out of Figma and into more kind of AI-native practices.

Z: Yeah, absolutely. It was a really interesting moment. I remember that conversation

A lot of folks at the time were talking about AI transformation. Everyone was thinking about it. This was still last year, still a little bit early in this curve about AI transformation, so a lot of people were thinking about it, and people were doing it, and some, of course, AI-native companies were way ahead compared to the rest. They were already out there.

And our team was interesting because we had this mandate, like any other tech company, right? So you will start to do AI transformation, to incorporate AI into your workflow.

So for designers, the first thing that we looked at was how designers prototype. We weren’t even thinking about how designers ship, we were talking about prototyping.

And of course Figma has been the de facto tool for product designers for many years by now, but in this new workflow, we were thinking about getting designers to prototype with the new capabilities, with all the vibe-coding capabilities.

And a lot of our designers started to see that Figma, instead of a prototyping tool, which is what we used it for before, had now become a wireframing tool. Basically, you come up with ideas and then draw them out in Figma, but then you- the prototyping is actually happening in the coding part, in the vibe coding, whatever the tool was back then, whether it’s Claude or OpenAI, whatever.

So I wrote about it. I audited our Figma. Of course, as the operations person, we look at our Figma usage and everything. I audited it one time, just on a random day, I looked at it. Out of our hundreds of licenses, there were 50-some people using it that day, and only five of them were from our product design team.

Most of the others were marketers, PMs, everything. So that was a very interesting moment for us to look at tooling and at the designers’ tool stack. But that was months ago, actually, compared to right now. Everything moves so fast, and that feels like so long ago.

Telling engineering what changed

Jesse: I wonder about the cross-functional aspect of making this happen, because there is always this sort of ripple effect whenever one team changes the way it does things, on how that team then interfaces with the teams around it. How did you manage the cross-functional conversations as you were transitioning the team out of Figma as their primary way of doing things and into vibe coding?

Z: Yeah, that’s definitely a lot of challenge and work. So I actually proposed it back in October last year, to our design managers, to design leadership. I said, “Let’s get our UX designers out of Figma.” Of course, everyone was like, “No freaking way. You are crazy. Designers are in Figma, that’s our tool,” and everything.

But the reason I proposed it is that it wasn’t just a random proposal, like let’s get rid of tools or anything. At the time, we had a new design system that was entirely in code, and we were fortunate in a way, because instead of trying to continue building multiple design systems and trying to move them along, to modernize all those design systems, from the top down there was a mandate. This is the design system we’re going to use. That design system is in code.

And that’s really what prompted this proposal. That didn’t happen, so by the time I talked with Peter, that was already three months after. I think we talked at the end of last year, and it was October when I was proposing it.

But by then, just de facto, no push or anything, designers were already out of it. But there was a lot of conversation. If I could have done this all over again, I would do it differently. I would be reaching out to the engineering team immediately and talking about this transformation. At the time, this just organically happened, and then by the time I talked to Peter, this is… That’s when we started to realize, oh gosh, we need to talk to engineering a lot more. Some engineering teams still required our designers to give them a Figma file. Some other teams were more open, and you could do other ways of prototyping. And there was a lot of discussion about what designers were doing in code, and we also had to go out and talk about it.

There are levels to “designers shipping code”

There are different levels of designers in code. So there’s the- One, the basic thing about getting designers into code is engineering empathy, right? So engineers now, instead of just coding, they do a lot of reviewing code as well. So what it takes to- for an engineer to build something, that’s something designers should understand as well.

And then another level is where we got our team to prototype, but then by the time February this year came around, our designers were actually shipping production-level code. It sounds so grand, production-level code or whatever, right? But by then we had worked with the engineering team, put a lot of guardrails in place, about what designers should not be touching in terms of code. If it’s an API, if it’s infrastructure, if it’s, say, if it touches a flow, these are things designers should not be doing.

And what we’re actually talking about when we say shipping production-level code is paper-cut-level shipping of code, right? So change a piece of copy, change a wrong component, small changes.

And so these are things people sometimes talk about, “Oh, designers shipping code.” They put it under a blanket umbrella that says, “Designers shipping code.” But there are actually really different levels of designers even touching code. People are not getting there because, “Oh, designers shipping code. Are we turning designers into engineers?” No, absolutely not, right?

So same thing, we opened up Figma for other cross-functional teams to use. PMs using it, engineers using it. Are we turning engineers into designers? Probably not. Are we turning PMs into designers? No. But we’re turning everyone into a product builder, a contributor, in a way they’re passionate about, wherever they see a fit with the tool.

Now we’re basically just giving everyone all the tools, not just keeping Git for engineering, Figma for design, or whatever the PM tooling is, but we’re actually giving the entire tool stack to everyone who is touching product and building, and they use the same tools we have. And so that’s where it is. But it takes a lot of talking, coordination, and it really does hit some nerves because everyone is jumpy, and designers say, “Oh gosh, engineers designing, PMs designing,” and the engineers say, “Oh gosh, designers coding, PMs coding.”

So I wouldn’t say it was all smooth, but at least that’s something we put a lot of effort into, and we saw results from doing that.

Standardization doesn’t scale anymore

Jesse: One aspect of your story that I think really resonates with what I’m hearing more and more, and what I’m seeing in AI transformation efforts broadly, is the notion that you have to meet people where they are inside the organization. And imposing a kind of one-size-fits-all policy for this technology is not actually going to get you there, that you need to be able to find ways to leverage potentially a broad range of different skills across your team in a way that you haven’t before, and to be able to accommodate a diverse range of different kinds of workflows, and setting different kinds of expectations accordingly, cross-functionally, with how product and engineering interface with and interact with design.

I wonder for you as an ops leader where your mind goes when you think about managing operations across a diverse, distributed set of work processes that no longer fall in line with a single paradigm anymore?

Z: Absolutely. So I come from a very strong operator’s perspective, right? So in the past, as operators, you were the process wranglers, basically. That’s what it is. You want to… The word we used for the longest time was standardization. Standardize the process, and that will actually scale, right?

So but right now we’re pitting speed versus quality. There are a lot of discussions in there, whatever. Like you just said, standardizing everything won’t work anymore because different teams move at different speeds, and different teams have probably started to adopt slightly different workflows. And some teams might… Some companies, some teams, might even allow them to use slightly different tools or whatever.

So I wrote about it, and to talk about it now from an operator’s perspective, I push a lot for shared principles, and then giving people the agency to work out the details, how to execute it, and to have a little more flexibility instead of standardizing across the board.

But shared principles are something every team needs to spend a lot of time aligning on, and also educating everyone and talking about, because if you think about shared principles, for designers, there are certain things, right?

Accessibility is a, for us, something we care a lot about, and engineers care about that as well. And engineers probably care a lot about their code quality as well. So their APIs, nobody touches, and as long as we’re clear about what everyone can contribute and that everyone should reach out to the experts to contribute, that helps the team move in different formations, but still moving in the same direction.

Should ops be leading the AI transformation?

Peter: I’m, so, I’m gonna continue on this thread because when we spoke about this at that Figma meetup, the light bulb that went off for me is that this type of AI transformation might be better led by operations folks than design leaders.

Whereas my kind of working assumption in the conversations I’d been having with clients and whatnot, design leadership was responsible for that. And, if they had an operations person, maybe would be leaning on them to help.

But something that’s also happened over the last couple years is a lot of ops teams have evaporated. And so the, the irony being we’re in now in this moment that is so operationally heavy, and many teams don’t have operations folks to help them through it.

And I’m wondering what is your relationship with design leadership through this type of experience? What are you responsible for? What are they still responsible for? How do you distribute authority? Who’s making what decisions? That kind of thing.

Z: Yeah. So if you think about design operations in general, with your leader, it’s always a balance. It is always challenging to divide that responsibility and accountability. It’s just because different teams work slightly differently.

So in my specific situation, it worked out really well because at the time, I reported to the head of design, and her mandate from the top down was AI transformation. And then my part of the work was actually getting that done.

And then the design leader coming in down to the team, this AI transformation, you think about it as a gr- grassroots effort. Everyone wants to use something, build something.

But to do it right, you absolutely need top-down support, to give people the time to do it and to give people the direction, where to go and what we want them to do. Do we want them to stop at prototyping? Do we want them to ship code? We do need to know what the end stage is that we need to get the team to.

And as an operator, then we can actually help the team achieve that and figure out the logistics, scaffolding the team step by step, how do we get there, get the designers into code.

I came from a very technical company. It’s extremely hard to get into our production code base, rightfully, and it should be. It shouldn’t be turnkey, where everyone can ship code. So there’s a lot of coordination. It’s my role and my team’s role to go out, reach out to our engineering partners, “Come on in, help us do it right, because you do want us to do it right. You don’t want to review crappy code. You want to teach us to do the right thing.”

And then so in return it helps them as well. And also a lot of explanation as well, “Hey, we’re not trying to be engineers. We’re actually trying to take care of the design debt that engineers never have the bandwidth to take care of, and they are very small paper-cut things.”

Leadership owns the what, ops owns the how

So my goal is really to focus on the how. How do we get the team there? But design leadership is the what. Coming in with the what, and giving the team the mandate. That’s really important.

With these things, if you just say, “whoever wants to get on the bandwagon, let’s do it,” it is really hard to move that fleet in the same direction. Those would just be sailboats, right? Everyone’s like, “I want to go. I want to go really fast. I want to do something.” And then someone else wants to do something else. “I want to use this tool.” “I want to use that tool.”

So the design leader needs to come in and say, “This is where we’re going to get people,” the what, and then the operators come in with, how do we get there?

And that worked out really well. And then also because we’re… We say it’s design operations, but on the other hand, nowadays my perspective on operations is that maybe we’re not design operations, we’re just operations, in a way. Experience operations, whatever. Reaching out to more teams outside the design team.

And after our transformation for the design team, I ended up going out, because of our training, we had everything in place, documentation, recordings, process, all the things in place.

Now other teams, these non-technical teams, came to ask us and say, “Can you train our team? Can you train our team?” So our team members, our operators, actually went out and thought more about how to leverage our knowledge to up-level the cross-functional, cross-board, company-wide AI transformation, everything.

So I’m thinking and trying to figure out, do we still use this term design operations, and does it still have a meaning? There might be, but there might be more. Maybe design operations needs to be more of just a higher-level operation. Experience operations.

Nobody should be design-led

Peter: I like the phrasing of experience operations. I’m, I’ve always had issue with the phrase design-led. A lot of companies, 10, 15 years ago were gonna be like, “Let’s be design led.” And that always, even as a design executive, that made me uncomfortable because it was elevating one function over the others.

I don’t want to be engineering led, I don’t want to be product led, I don’t want to be design led. Those are disciplines. N-no discipline should lead. I have always actually liked “experience-led” ’cause that’s an outcome. How are we all working together to achieve an outcome? And so this idea of experience operations resonates well with me.

But I’m curious, we might be getting a bit in the weeds here, but let’s go on that journey. How did your experience in design operations change? Because…

So when I think of design operations, I see two pillars to it. There’s the team operations pillar, right? The internally oriented pillar, career frameworks, and recruiting, hiring practices, and culture stuff that’s really specific to design.

But there’s also always been this program management pillar. When we wrote Org Design for Design Orgs and we wrote about design operations, it was pr- mostly around program management, which was how do designers work with other functions to deliver better experiences, to get back to that word.

And I’m wondering, did, has there been an, a meaningful change in design program management? I understood that role to already have a cross-functional mandate and set of relationships. Maybe I was either wrong and primarily, at least in, in your experience, DPMs were still primarily internally focused, just helping designers do their work.

Or maybe I was right, but there’s still something interestingly different about what it means to be a design program manager in a pre-AI world and now in a, I wouldn’t call it post-AI, but as we’re moving through this transformation.

Z: And AI transformation. Yeah, so I wouldn’t say it’s wrong, but also it was right for the time. What– And also it’s a different perspective.

You’re looking at practically how to structure our organization, right? But if I think about it, I like how this is also… I didn’t invent it, you know, that we sometimes frame design operations as a focus on how we work together, how we get work done, how we articulate impact.

And so if we look from that perspective, then it doesn’t really have to be divided into a people program and a DPM program. It doesn’t have to develop that way.

Say, on our team at the time, I had a small team. I had people focused more on people, and I had people focused a little bit more on maybe just research operations or something like that.

But then they don’t have to be in that vertical anymore. They can come out to help the operator, the operations team, think about how we work together. That’s how we’re changing our tools, changing our ways, changing our process, changing our workflow, all that.

And how we get work done, that’s where we can actually do more of the training, teach people, scaffold people to get these things, to use the new workflow, to use all the new tools.

How we articulate impact, that’s when we transform our team using the new way of working with AI tools. What did we do? And how does that move the needle, how does that impact the customer’s experience? Is it because we’re fixing a bunch of the paper cuts, the retention is better, the call tickets, the, the customer support tickets go down, whatever.

We haven’t gotten that far, but that’s where the measurement will be, how do we articulate impact. So then we don’t have to separate the organization so specifically, that as a TPM, you can only help the program. But as a TPM, you can, oh, or as a DPM, TM, whatever, you can come out and help the transformation as well.

So that’s how I see it.

Let it get chaotic, then rein it in

Jesse: One of the things that I think makes ops such an interesting leverage point for AI transformation is the holistic view that you have, in a way that even design leadership, they can only kind of– they can only see in certain corners at certain depths and so forth.

And this, as a process, it’s become increasingly clear that this is a process of learning as you go, that that every organization has to take this journey of taking stock of themselves and more deeply understanding what’s going on with their processes than maybe they ever have had to do before.

And I think about the feedback loop that is required to keep an AI strategy on track, right? You need to be able to do all the things that you’re saying about get the tools in people’s hands, get the knowledge in people’s hands, continue to educate, bang the drum for the right principles, et cetera.

And then you have to figure out what worked, to your point about articulating impact. But there’s a thing in the middle there which has to do with just taking stock of all of your experiments and understanding where those experiments are going and how that’s actually adding up to something.

So there is almost a a kind of a grassroots strategy element required here, where I’m imagining that you’re the one who is really setting the criteria by which things get bubbled up to the leadership and things become, new ideas become strategic recommendations.

Z: And ideally, yes. And in the past, a lot of that was reactive, right? Because it’s so new. Our– At the time, the org I worked for was pretty much on the far end. We weren’t an AI-native company building AI, but we were pretty close, one step behind, right?

And one thing is that you have to… I almost think you have to let it be a little chaotic first and then see where things land, and then try to rein them in to figure out how we can actually organize the buckets and everything.

So at first, the biggest challenge, again, back in October last year or whatever, was the fear. A lot of the discussion back then, if you think about it, was that it’s replacing our jobs. Are we actually going to, because of that, right? So that was the biggest d- discussion in October.

And the majority of people… I know, Peter, you just did a survey, everything. A lot of people now are moving to… If you look at a bell curve, they’re moving to the middle now. Actually, you see the whole industry is moving just from October to now. But if we were to do a benchmark back in October, the majority of people were in that, “Oh, stay back and let’s see what happens,” and I’m a little afraid, stage.

So when that happens, the biggest challenge for us is to get over that hurdle. So the way that we started was actually letting people just build whatever the heck they want, really, and just build, and then we’ll deal with it. And so we had… The first thing, we didn’t even talk about prototyping or anything, just build.

You can vibe code. And designers loved it because, “Oh, I have a problem. I could never get an engineer to build it. I’ll build something for myself.” And then so we did it, and everyone built that… I did a, a series of vibe-coding trainings. And then in four months, we had 30-some apps spin up within our team. Given that we were a 40-person team at the time, right?

And it was a little bit Wild West, and then people started to find out, oh, we’re building similar things. We’re building contradictory things, maybe, to what other people are building.

And but that’s good, actually, because then we see that, and then we start to think about what’s actually worth building upstream and everything.

And so I think it has two sides, grassroots, and also you need to let it grow a little bit and then see where it lands, and then start to put in some kind of principles to get people back together to keep moving. And I don’t know, I, I just started with a new team, whatever. But that’s the learning I’ve taken, and then go to- getting to a new team and they say, “Okay,” so I start to see we’re definitely far over that curve now, so people are not in that reluctant stage anymore.

Everyone’s getting a little bit more towards the accepting side of everything. But I still see the same thing. Everyone’s building. Everyone’s building their own, and there are really amazing tools now, some really good tools. However, these tools still don’t talk to each other, and there’s no really good function to govern any of these tools that get built, that every individual builds.

And yeah, so that’s a new challenge for me right now.

Roles, labels, and what’s worth keeping

Peter: I wanna rewind a bit and get back to the conversation we had. Something that you wrote about on, in your newsletter that I drew from based on your experience doing the kind of AI transformation work, was on people’s relationship to their roles and who does what in a team.

And I’m bringing this up because I was just in a conversation… Oh, with one of my clients. I, one of my thought partnership clients, and they’re actually going through… It’s funny. They’re go- They’re not even going through the AI transformation yet. They’re going through a simple product operating model transformation. They are that far behind that they’re only now adopting things like product discovery, and how do we work three in a box, and what does it mean to have a product designer as opposed to a separate UX designer and UI designer?

So that’s where they’re at. But obviously, they’re going through this transformation during a time of AI, so there’s going to be a lot of turbulence. And the question they asked me, and I’m… want to ask you, is around roles and role definition and who’s doing design and how many people are doing design.

And let’s say not just design. Design, research, content, that full suite of kind of classic UX practices. And what you witnessed in terms of how practice is done, who’s doing… what’s worth maintaining, if anything, and what’s worth throwing out and trying something new. What was… What have you seen in, in this shift?

Z: That’s a loaded question, isn’t it? To me, and this could be a very radical perspective, and I’m always a little bit on that edge. So to me, the only thing really worth preserving is the agency for people to do what they love to do, and the role specifically, and it could be design, could be engineering, could be PM, the traditional EPD model, and those are just labels.

And so people have their passions. I’m more passionate about designing and about… I also code. I love coding and all that, right? I want to see if there is a way that, instead of thinking, everyone has expertise, but they don’t have to be labeled as a designer, an engineer, or a PM, and their expertise is customer-focused experience.

Their focus can be something like that. And I want to see a world where people have more agency to assemble organically. And so it doesn’t have to be strictly a proportional EPD ratio. You’ve got one designer, one PM, two engineers to build something. What if I have a designer who is an excellent coder, so I could have a design coder, a design engineer, work with the PM on it?

Or it could be something like, I have an engineer, I have, some engineers have an excellent design eye, but their passion is coding, so they can actually lead that maybe with the PM. And then we also have a lot of designers who have excellent business sense. They have been founders, they have run their own agencies, they understand the business so well.

But maybe it’s a designer and engineer formation, so I want to see that organically formed, whatever you call it, squad, po- pod, whatever, to actually focus on the product to build. And but everyone still has expertise. So if I go in with the engineering team, I don’t even try to pretend I’m, that I can code, engineer, anything, but I understand where they’re coming from.

That’s why I see the AI era as excellent, because it gives people certain abilities that they didn’t have before. They always wanted to do it. Maybe there was no time, maybe it wasn’t their top passion or anything. And now designers can come in, do a prototype, code something, and then do it, and then maybe if we train everyone right, maybe that code is good enough to even… for engineers to just take it, polish it up, and then ship it and everything.

We talk a lot about AI-native companies, and they’re shipping so fast. Designers’ code, a lot of the time, gets into the engineering product anyway. I’m less precious about labeling.

And I am a designer. If you ask me, I’ll say, “Okay, I’m rooted as a designer,” or I put that down as my passion. I am always biased towards the design team. That’s my root and everything.

But where I came from, I also saw a lot of the engineering perspective and everything. I worked for a company way back. We did a lot of pairing. I would sit down with my engineer every Friday, just watch them code and everything. So I want to see that more organic way.

And I know that there are a lot of people who said, “No way. How can you take out the discipline, the designer discipline?” And that’s been their whole identity for the past couple of decades and everything. But for me, myself, it’s not… I’m not that precious about that particular label, but I’m more precious about what I’m passionate about, what I can do, and I’m an operator now.

I can label myself an operator, but I’m also a builder. I also could be a strategist or whatever. I’m working on the strategy level or whatever, but it’s about capability.

Battleships, not sailboats

Jesse: Peter and I once ran a company where we didn’t believe in titles and role definition and things like that, and we basically treated our entire group of consultants as a kind of one category in our systems. One thing that came out of that experience was that it made things like performance reviews really challenging because it made it a lot harder to make apples to apples comparisons against some sort of rubric, against some sort of standard of performance or quality.

So everybody’s performance review ended up being tailored to their bespoke set of strengths and accomplishments, and I wonder about the scalability of that. Ob- obviously there’s more than one way to approach this kind of a situation, but I think the, the challenge still remains of having just way too many distinct ways of doing things in order to be able to, again, evaluate what’s even working effectively anymore.

And I wonder how you scale that.

Z: I wish I had it o-on hand. So I was heavily influenced by Corporate Rebels, their way of thinking about a very progressive organization. And then part of the thing is talking about this flat organization style, whatever, right? So you think about designers or engineers or PMs, if you put them all in one bucket, how do we really evaluate performance and everything?

Because what we’ve been trying to label as the craft or whatever, that is one thing we’re being evaluated on, right? So that’s a thing. But it could potentially be more two-dimensional, right? So everyone, you have your strengths, that craft, what… It’s your strengths, whatever, and then you can be evaluated against that.

But there are just other dimensions, how you work with other people, how you push product, how you impact the business, and all the other dimensions. Everyone’s the same. I’m contributing from a design perspective. You might be contributing from an engineering, more engineering, perspective, whatever.

And so we have that little sliver. And then, but the other dimension is everything else, how we actually move the product forward, it could be.

And I don’t think you have one size fits all, but that’s why I’m interested in the organ- in the more progressive organization style to think about.

The team can decide. My pod can decide this is how we’re going to… This is our goal, and this is how we’re going to evaluate at the end, do we, how do we achieve that goal? And the team can decide a little bit. But of course, from a larger organization, you’ve got to think about, again, you’ve got to set the team goal, and then the team can actually organically evaluate themselves in order to reach it.

And it’s hard. I think I wrote that this is the best time for ICs to build stuff. Excellent. This is the hardest time for leaders to lead because it’s really hard to figure out the how now, because there are so many different ways. But I think the most important thing, I don’t remember who talked about this, is that as a leader, you’re the commander of a fleet of battleships. You’re not a commander of little sailboats. So if you let the team build as sailboats, then it’s super challenging. However, if you can run the team as a commander leading a fleet of battleships going in the same direction, they’ll have a better chance of getting everyone moving in the same direction.

But each battleship, they… Their own commander has a lot of decision-making agency.

Peter: So many thoughts.

Z: Yeah.

Ego death, 18 months later

Peter: This, this role conversation and how roles are defined, touches on identity. You mentioned that earlier, right? I am a designer. I went to a design school. I have had the title… I’ve had the word designer in my job title for 15 years. That defines me.

And so I’m curious, so that’s one thing, though. Like, how have you handled the soft, squishy, human kind of aspect of this and helped people through that?

Jesse and I, a year and a half, almost two years ago now it feels like, but at least a year and a half ago, when we first started talking about the phase shift, one of the things, one of the themes was ego death, right?

We’re gonna have to let go of our identities as whatever, designers, because it’s getting in the way of our ability to have impact.

But 18 months later or whatever, people are still attached to those identities.

I’m curious. I’ll limit myself to two questions. I’ve got five, but I’m gonna limit myself to two questions.

I’m curious how you’ve helped people navigate that identity shift, but then, and it’s related how do you recruit and hire, right? What is the title on the job posting when a designer could also be a developer or p- maybe a PM, or it’s one flavor of designer versus another or whatever, right?

One of the benefits of clearly defined roles is you can signal, ” Hey, we need to hire someone with this set of skills,” and this title equals that set of skills. Now, though, when titles and skills are becoming decoupled to some degree, or at least not as tightly bound there’s a very practical challenge of how do I recruit and hire.

So on one side, how are you… how have you brought people along throughout that identity challenge? And on the other side, how are you making sure that the people you’re bringing in are the right folks for the work to be done?

Hiring in the Wild West

Z: Yeah. So let’s talk about the recruiting side first, because that’s the Wild West right now. You can go out and do a search. There are a lot of designer-labeled jobs, sure, but you also see a lot of companies that start with things like member of technical staff, whatever those labels are, right?

And then you have people s- tell… putting out titles I have no clue about now. So it’s challenging for people to look for a job, it’s challenging for companies to hire, and it is really challenging right now, but that is also the Wild West right now.

We are eventually going to figure it out. Honestly, I think for operators, I’m a little bit used to this scene, because for the longest time, design operations had no title, and there were all kinds of descriptions and then trying to figure out what it is. We’re finally just about to have some kind of titles, DPM, design operations, research, finally.

But now that I’m talking about, let’s move this out of order. Let’s talk about other capabilities, right? So I’m a little bit used to this. It is challenging, I have to admit, and a lot of the time even the job description is very challenging. People are going to just throw… It’s a kitchen sink. You gotta be this, you gotta be a designer, you gotta be able to code, you gotta understand design systems, you gotta lead, do strategy, and all these kinds of things. It is a kitchen sink sometimes because they don’t want to forget something, because they don’t know what they really want.

So that being said. But hopefully when people come in to interview, it’s also challenging when people come in to interview if the company doesn’t know what they want and then they go back and forth, it’s super, super draining for the people who are interviewing as well. So these are definitely… I’m not gonna get in depth about the hiring side of the problem.

There are a lot of discussions out there, but the thing is, I talk to the designers. You can still call yourself a designer, you can still call yourself a builder, however you want to call yourself. What is super important on the talent side is that you’ve got to be extremely clear about what you want to be, and then go talk to the company and find out if that’s what they’re really hiring for.

And when I look for jobs, I always look at three things. Whether the company’s values align, the company’s values, that’s like don’t be evil, right? So basic things, that’s something I care a lot about. Another thing is c- about the people on the team and the work that you’re doing. And then another thing is also trying to think about the technology side I want.

I want to be a little bit on the cutting-edge side of the technology. So that frames how I go look for a job. I can look for jobs in design strategy, design operations, business opera- whatever the title, I don’t know, but I’m super clear about what I want. So hopefully designers can form that, I want to work for A, B, C, and then go look for that job, on both sides, to help the company also form a little bit of what they’re hiring for.

And I get it. I really, I personally don’t care about titles, but I’ve been around for a long time, and for entry-level job seekers and everything, titles matter, whatever, right? So take whatever you’re happy with and then go with it. You can redefine it or not, or start to build on top of it, whatever.

And then, but I think, again, I’m always on the side that I care less about the labeling and more about the substance of what it actually is. So…

Peter: You and I care about that, but we’re weirdos.

Z: I agree. I agree. I am. So it… But that helped me and the—helped me a lot in looking for what kind of job I want. I always go into every… So far in the past three jobs I’ve had, I always go in looking for what that job is. Eventually we figure out whatever the title, you can call yourself whatever, right? So it’s figuring out that title.

But I care a lot more about the job I’m going into. And that helped me find jobs as well, because I’m super clear. I’m not… if you ask me, “Oh, what do you want?” And everything is like, “Oh, whatever you have, I will do it,” you will never get anywhere. So I’m super clear. This is what I want to do. Are we aligned?

It’s a, it’s like a marriage. You gotta be a match, right? So I want to match with my job. So this is what I want. Is that… We can go back and forth a little bit, but overall, do we match? If it’s a match, then we go forward, right? But that’s the hiring side. And then talking about how do we talk to the designers right now, right?

So most likely nobody’s gonna change the titles, changing them for the companies that have been around, say all of a sudden we’re gonna change the entire design org to staff of the tech- technical staff or member of technical staff or some… Not likely. But so the deal is, again, caring more about their capability, and you’re a designer, your expertise is customer experience if you’re a UX designer, right?

Your cu- your expertise might be customer experience, everything. But then also what else that designer has actually been really interested in. Some of our designers are more interested in the business perspective, so they actually transitioned themselves into a designer PM, whatever you call them, but they’re actually leading the product and everything.

And so some other designers might be more interested in the technical things. They’re moving to the… So design engineer is even a traditional title, right? It’s been around for a long time. However, they’re moving more towards the design engineer side. So I know I…

You two talked a lot about the design engineer or the strategist. These two ends are taken care of. It’s all the people in the middle. It’s a little bit harder to focus on. But the thing is that these are the people we can actually start to help understand where they want to be. And there might be even new possibilities. Instead of a design PM, a design engineer, could that be a design salesperson?

I don’t know. Go-to-market designer or s- I don’t know. And but it’s, again, going back to that organically formed idea. If this product needs something, can I be the right fit to push that? And I’m still a designer, but what I do might change slightly now.

Design ops as service design

Jesse: I notice that what that asks of the leader on sitting on the hiring side is for them to be, as you put it, much more aware of their own needs, but also to really take on the role of intentional curator of a team, and not just hiring resources because they fit in a box, but rather to be evaluating them.

Like you talked about looking at it as a two-dimensional problem. That it’s not just about craft and skill, but it’s also about organizational compatibility, collaboration, working together and how effectively they can do that. And the conclusion that I’m drawing from this is if I’m a manager, a leader engaged in an active hiring process, I need to be paying a lot more attention to that second dimension of how people work together and form trusting relationships than I’ve ever had to before really.

Z: That’s why design leaders benefit from operations support, because we are always looking at these things, right? So as operators, we’re always looking at the capabilities, how things work together, how do we scale things, how do we move everything together, and as a partner.

Jesse: That touches on something interesting that you said in your newsletter a while back that, that struck me, in which you compared design operations to the practice of service design. And I wonder if you can expand on that idea a little bit. What do you mean by that?

Z: So my thinking has also expanded a lot compared to when I wrote about it. So a lot of the time I say I’m biased, I believe operations is extremely valuable, important, and all that. And also, in reality, I know it’s also a, a luxury a lot of the time for a lot of teams, everything. But I am rooted as a designer, and coming from a service design perspective, maybe not UI.

I was trained as more of a graphic designer, but then evolved into all different things. I had my own business for a long time. And so I really evolved myself into looking at these things. What is the problem at hand, right? So when we started as a design operations discipline, we were trying to solve a problem, a challenge the design team had back then, right?

So that’s how this whole discipline started to form, to become a label and everything. Essentially, we were service designers to the design team at the time, right? So that’s more of our perspective. So w- we are looking at a service design approach to what is the challenge or what’s the problem on ha- on hand for the design leaders.

How can we come in to help the team solve these challenges and everything? That’s exactly service design, and it’s just service design for the design team. But now I even see it more as service design for the product or the org and everything. I’m trying to push really hard to start to lose that design operations label and to be more of an experience operations.

And I think that’s really important. And for us to think about what is the problem at hand now. It’s not… Now, especially with all the AI transformation, it’s no longer just the design team’s problem anymore. Everything the design team does will touch everything else now. And then with AI, it just comes faster.

And then you don’t have that luxury to think, I can go through a double diamond for a year and then figure something out. For many tech companies. So you’ve got to think about, when you move as a team, how that ripples out to all the different teams, everything. And I think the operator, the experience operator, is the best person to see that bigger picture and to service that service.

Peter: It’s a, it’s an analogy or a an alignment that I’ve also seen and experienced as someone who, when I was a more n- normal designer, I was more of a service, I was more of a service designer, right? At Adaptive Path, we were doing, we called it UX, but we realized pretty early on that our UX design approach was a service design approach.

We were looking at the broader organ- organizational systems of the, our clients and in order to better understand their ability to deliver these experiences, right? And so that required a service design mindset. And then when I became an executive and I needed to start thinking about shaping my team. Two things.

One, I would adopt a service design mindset in terms of thinking about, like, how do I, how can I use a journey model to organize design? ‘Cause I think that is m- more responsive to the needs of our users. But then to your point, when you start getting into a systems mindset, you’re looking at your team as an organism and how do you operate effectively?

Everyone says they care about quality

And this kind of starts to dovetail to something you’ve been writing about more recently, which is the relationship between operations, and I’m gonna continue to use your term experience operations, to the relationship between experience operations and quality. One of the biggest concerns that you hear from designers is that because of speed, because of ease of access, more stuff is being made and it’s broadly mediocre.

This is borne out in research, Figma’s research, Lenny’s research. They’re like, “Yes, people are going faster, but no one is happy with actually the quality of what is being produced.” Everyone feels supercharged, but then when they reflect on what they’ve made, everyone’s “Eh, this is crappy.” Or it’s not bad necessarily, but it’s it’s not getting any better.

I’m curious, you’ve been writing about this a bunch, so I, I’m not gonna ask you to repeat everything that you’ve written. But as you think about this responsibility, maybe that experience operations has in helping establish quality bars, quality rubrics, w- how do you approach that?

What do you make of it? Yeah.

Z: So speed and quality, a lot of the time we see them at two ends of that spectrum. But I don’t like to see it that way, actually. And part of things that… Ask a designer, “Do you care about the quality of the product?” Not just the design, just the product.

The answer is 100%, absolutely, right? So you go ask any CEO, “Do you care about the quality of your product?” You’re getting 100% the answer, “Absolutely. I care about the customer, I care about their experience, and of course, I care about the profit and the business as well, but I also care about the business and the quality of the product.”

So that’s actually aligned. As an engineer, do you care about the product? They care from the code perspective, about the product and everything. Everyone cares. So if I, as a designer, go out and say, “Hey, engineer, you just shipped something. This looks so crappy. It’s bad quality and design.” Is it true? Yes. But have we ever articulated to the engineer what is good? We probably never actually spent that time to go out and tell the engineer, “This is why we care, and this is what is not quite right, why it matters.” We never spent that time.

Peter: I know it while, when I feel it, Z. I, I it’s… I just feel it.

Z: Okay, so how do you feel it, why do you feel it that way, and is it because the color is wrong? Is it because the experience is jarring? Is it… I can ask you that, right? So it’s teaching people that you feel it, and how you feel it, and why you feel it, and that’s important, I think.

And same thing, an engineer can teach us about code, why my code is crappy code, they can tell me, right? So I will learn in that process and everything.

I also wrote a lot pushing on this, sp- speed is really not the enemy, but it’s really for us, if we can, not hold this design craft just to ourselves as a moat, but really think about it. The best thing is, 20 years ago, fewer businesses were talking about design thinking, and now you think about business, they understand, at least they understand the idea of design thinking, understand that focusing on the customer results in good business or whatever.

At least that is actually progress. We might say, oh, we’re rolling back or everything, but it’s a spiral. We’re actually moving towards a better position. So I talk about how I want to see design maybe as a discipline eventually dissolve or everything, but design thinking become more of a human nature. Everyone, whether you’re a PM, whether you’re a designer, whether you’re an engineer, business, or sales, you’ll care about this design thinking approach at least.

So that also, I think a designer… Now it’s the best time for designers because we understand, we can deal with ambiguity, and we understand the design thinking approach, we understand the customer, and if we can learn more, I think for designers to understand the business and everything, this is the best time for designers.

Peter: Let me just do a quick follow-up. My question might, is quick. Z’s answer might be long. So we need to articulate standards of quality. We have to go beyond feeling to what leads to that feeling. What is the role of experience operations in that conversation?

Z: Build in layers of quality control. One, what can be automated, what has to have a human involved? So from an operator’s perspective, and right now in my- in my new role I’m working closely with the folks who are talking about QA and everything, I ask a lot about what can actually be built into the system so that it makes, creates a condition where doing good design is actually easier than doing bad design.

And for non-designers, that’s one, from an operator’s per- perspective. Another thing is that if this layer didn’t catch all that, then that needs to come to the human, and then we designers can come in to do the human check, can do the human education to talk about it and everything. So that’s the operations perspective, to build this system to make doing good design easier than doing bad design.

Beyond the language model

Jesse: So as that perspective continues to evolve with new technology, I’m curious about what for you is the biggest unanswered question that you’re curious about the future of your own practices in design or experience operations?

Z: I, again, do not hold this particular label or anything that dear to my heart, in a way. I’m passionate about it, but on the other hand, if you look at my career trajectory, it’s always different, slightly different. It’s not a straight line. And I think all that experience coming in helped make me how I operate these days.

And so what I’m curious about is really, I honestly think this is the best time. AI gave us a lot of capability and everything, but right now we’re actually stuck in this language model. And I’m looking forward to seeing a spatial model and everything, other kinds of AI.

And I want to see all these new technologies, how that eventually will actually impact humans and human progress, and it doesn’t have to be about being an operator anymore, it’s just more the grand scheme of life, right? So how that can really absolutely enhance our experience to be more human and to do the– to make those decisions only humans can make, and come up with those ideas that actually progress the human race and everything.

I’m looking forward to that, and I’m curious where that goes, because I truly don’t believe we are going to be s- stuck with just language models forever.

Jesse: Z, thank you so much for being with us.

Z: Of course. Glad to be here.

Jesse: Where can people find you on the internet if they wanna learn more about you and your thinking?

Z: LinkedIn is the best place to find me, to get in touch at a high level, and I write a lot d- on my Substack and everything, so we can share the links. And those are the two places to find me easily.

Peter: Got it .

Jesse: All right, fantastic. Thank you so much.

Peter: Yes. Thank you.

Z: Thank you for having me.

Jesse: 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.