Operational Excellence in Design + Leadership + Design Ops with Jon Fukuda - DT101 E144

Speaker A: Welcome to the Design Thinking 101 podcast. We help people think and solve like a designer. Our guests share stories, lessons, ideas, experience and insights developed while practicing, leading and teaching design thinking. They come to design thinking 101 from business, social innovation, education, design, government, uh, healthcare and other fields to offer you what they've discovered about thinking and solving like a designer. I'm Dejuan, Stanford. Your Design Thinking 101 host, John Fukuda is co founder of Limina co with over 20 years as a user experience specialist with a focus on UX strategy, design thinking and UI design. John has experience leading human centered requirements, strategy, interaction, design, testing and evaluation. Most recently, John has dedicated his efforts to research and design operations facilitation for scalable, sustainable, human centered systems. Today on the Design Thinking 101 podcast, my guest is John Fukuda. John, welcome to the show. Now John, I'm excited about talking to you for several different reasons. One, just, just the fact that you're an accomplished designer and leader and have all of the insights from practice, but also the deep knowledge you've amassed about design ops and the design ops community and uh, the way you are bringing people together to exchange ideas, build ideas, build practices. And so I want people to understand how you arrived at this point in your career where you have the uh, opportunity to participate and contribute like that.

Speaker B: Sure. I think a lot of people in this field, and I'll just say that broadly because design operations itself is a part of a larger field. Right. Which is design and design management in either digital product or service organizations. And if you're not even considering yourself a digital product or service organization, there's some digital presence that you have either through digital marketing or other online aspects of your business. My background is that I started doing user experience work in the late 90s, 1998 at a large systems integration and management consultancy. And I was very fortunate at the time that they were actually calling it user experience. At that point we hadn't really defined what all the roles were and what they needed to be. Some of those things were still being formulated when I joined that organization, but they had the sense that this aspect of technical and business integration had to have some focus on user centricity. Our user experience professionals were working alongside business analysts and we were gathering requirements, so doing the discovery upfront work and then translating that into workflows and screens and then ultimately high fidelity mockups that we can hand over to technologists to start building and tying into the backend of all the projects that we're doing. So that was like my early exposure to where does user experience work fit, how is it optimally organized for enterprise software initiatives? And how do you orchestrate all the tasks that have to be coordinated with your business and technology stakeholders for, for optimal outcomes? Even my early days where I was more focused as a uh, production designer, somebody who was doing some of the more surface level design management, I still had that sense of what's the operational excellence that we can achieve so that we're not stepping on each other's toes, that we're partnering well and that we're all focused on some better outcome that is more than my own contribution and that it's a collective sense of success that we're geared toward. That instilled some early sense of that operations mindset that it takes to not just look at the work that you're doing as a designer and am I being an excellent designer? But where are my necessary inputs so that I can help those who are contributing to my success be better at what they're doing and that those who are the benefactors or beneficiaries of the design work so that they can optimally sort of engineer things, just uh, always thinking about it in a continuous improvement mindset. So as we do things, if we make mistakes, we learn from them, we get better. And all of that I think contributed to my sort of early passion for design operations. We weren't even calling it at that time operations. It was just like what's the best process and practice model that we can put together? You know that was my first job, but then uh, my second job was more of an offshoot, a startup of a systems integration team. We were still defining the practice. So we actually uh, started doing a better job of breaking out information architects from interaction designers from visual designers and collaborating and coordinating our focus area. And even user research was broken out separately and we had designers who would work with user researchers, but their core focus was to understand what do you need to learn from research to translate that to great workflows and great screen designs and how do you translate mental models into interaction models. Right. Um, but yeah, we had the sense that this is a complex set of tasks and activities that had to happen. So the job descriptions were being broken out into a spectrum of people who contribute to the human centered process, um, all the way through to even front end engineering and UX development work. And that was my second job. We're outlining those roles, but then we were also talking about what is the practice model, so what's our methodology how do we, what's the workflow from pairing business analysts with user researchers through doing ux, uh, strategy work, interaction model and things along those lines down to what, what's the detailed design, wireframe slash design work to get to the point where we have front end developers partnered with our technologists and stuff. That process model and all that stuff, that was all really good work. That organization was purchased, it went through a mergers and acquisition and they decided at that point that user experience was a redundant set of tasks. So they jettisoned the UX group and I found myself with a bunch of my, my peers. We were still taking contract work outside of having been furloughed or whatever and we started to work together as a team and ultimately felt the need to build a practice around what we had already been working on. And that was the genesis of what I've been doing ever since, which is limina. So while we are focused on delivering user experience, work research, strategy design as a service, we're also internally focused on what, what are those optimal delivery patterns that we can do, discovery, do strategy, deploy, design work and how can we do that with the best level of operational excellence possible so that we're building a great team that's well healed, that when we work our customers that they feel we're empowering them, that we're giving them models that they can replicate. And in order to do that you have to think systematically. Like operations just has to be a part of the mindset, otherwise we're just a cog and you're throwing things over the wall and you're hoping that you deliver value but when you're more of a team player and you're working, you're trying to understand their operating model and where does it fit best with yours and how can you maybe buoy up some of their practices or uh, maybe even learn from and have their process models lift us up a little bit just so that our gears click properly. There's so much more opportunity to learn along the way and be adaptive and adjust uh, so that we are truly delivering with a sense of value, uh, not just in the deliverables, but how we build relationship and how we talk about design as a practice. I think that very much leads me to 2019 and I think I'll talk a little bit more about where I lean do a hard lean into design ops. Because even as I tell you about all these things I care about that it brought me to that point. I still wasn't calling it design operations. I didn't know the term was necessary at that point. I think that, yeah, so I'll just start at 2019. My team had already started to go out and collect a lot of stories of well, what are ways that we can help to advance the practice. And uh, I'll just some background on that was if you're in a consulting group that does user experience work, or if you have an agency, you work with a lot of different organizations and ultimately over time you get exposed to so many different varied perceptions of what user experience is. You get exposed to a lot of different maturity stage states of maturity where some teams think of design as just the surface level stuff and they do all the business and technical, uh, architecture work and then they say, hey, make this look good. And that's what if you're in the field of design, that's called a low level of maturity where you're just at the surface level. Uh, the higher levels of maturity are more inclusive of human centered researchers paired at the business buses and user discovery work that informs some of those strategic business innovations that may inform what technical stacks need to be in place in order for that user experience to be optimal. So those upfront discovery pieces are being done with a human centered mindset and then being translated into systems architectures to use uh, interaction models, experience models and designs that can better serve their customers and their users. And that's the more the higher level maturity. I think when you go to the highest level you have operational excellence in terms of where design integrates best, not just horizontally across the software development lifecycle, but maybe even vertically into partnerships with your marketing and your sales and other parts of the organization that can benefit from what are we learning about our customers and how can that impact us to do better for them? Those are higher levels of maturity. And so our team was getting exposed to a lot of different ways that teams look at design and how they integrate them or don't. And what we ultimately came to was there needs to be a conversation or a, uh, systems framework for leveling up or setting a new baseline for how design should be perceived, how it can be practiced. And that's when I learned about the Rosenfeld Media Design Ops Summit. It had been going on, I think for several years by the time I heard about it. And that was 2019. I ended up in Brooklyn at the 2019 Design Ops Summit. And it was three days of listening to people in the practice who had been serving that role. And I finally got was like, this is the work that I've been doing and caring about all these years. I just didn't have a word for it. And I didn't even know this tribe of people existed. And I felt like that was my community. And it's just for me it's been captivating and has stolen my sort of heart, soul and mind. And it's been a hard lean into that ever since.

Speaker A: That moment of, oh, this is where I'm supposed to play. That feeling is a wonderful thing to either search and find or trip over. And uh, I think it causes kind of um, a shift in uh, thinking when you suddenly realize like, wait a minute, I don't have to think about this alone. And tell me a little bit more just about the, the community that you've discovered over the years.

Speaker B: Sure. Those three days I spent, the uh, keynote speaker was from Shopify. I'm uh, having trouble recalling her name at the moment, but she gave a talk about the space between ambiguity and process. And the metaphor she gave at that time was that there's the North Pacific gyre, which, which is full of garbage from all the different places around the world that have ended up in the ocean and it's swirling around in a mass. She called that the tragedy of the commons. And it was a great sort of way of nutshelling that problem. And she used it as a metaphor for all the work that design ops managers do. And um, what she meant by that was when you're managing a design team, you are doing a lot of things. You're making sure that their process on the day to day is optimized so that people know what they're doing if uh, they're feeling overburdened, that you can do a certain level load balancing across your design and research resources, you can do better scheduling of their meetings and expectation setting of their partners. That's the surface level. But beneath it all, there are licensing all the different software packages that are supporting your research and design teams. Designers have a lot of different baggage. They come with some love Adobe, some love uh, Sketch and Figma, and they have different tools and preferences. But when you're running a team and you're trying to scale, you can't just have the willy nilly ness of all that. You have to standardize your process, your practice around your infrastructure. So somebody has to pick up all those pieces. And that's what she was referring to as that tragedy of the commons, because nobody feels like that's their job. Well, design operators or design ops managers picked up that mantle. So they do, yes, some of the design, program management, they do licensing and uh, infrastructure on the IT partnership side of things, they also work with HR and help do role definition and career modeling. What's our learning and development program? And just for the internal sort of health of the team, they work on managing team dynamics, squashing any issues that are coming up that come out of any toxicity that might arise out of issues and friction with their, uh, processes or certain behavior types, things like that. So it's all the things that, like, you wouldn't think is necessary for design to happen and be optimal, but once they're in place, everybody says, huh, now this is so much easier. So when I went to that talk and that was the keynote, those are the people I was running into. They were like, yeah, we've been doing all this stuff and it's because nobody else was doing it. And so we picked up that charge and we've been running with it. And what you learn, you know, from those people is that they don't just care about, you know, whether your infrastructure and your practice model is optimal. They really do care about the people and whether or not they're comfortable in their skin at your organization so that they can be the best researcher and best designer, that they have that sort of sense of self worth and they don't feel like they're being taken advantage of. All that stuff that team health and optimal performance comes out of that sense of belonging, whether you're being taken care of or not. And when you have all those little things that could be nagging little things, but they all add up. If you don't have those in place, it does end up becoming a sense of a toxic workplace. Negativity and negative sensibilities can arise. People burn out quickly. Um, all those things, it's a real sort of, I don't want to say nurturing community in terms of mothering, but it's a community that cares about excellence and where that comes from. All the different pieces that make up excellence. And that's just, I don't know, for me, that's my tribe. Those are the people who I feel like are driving a lot of value in what does it mean to advance a practice. You don't want to just be a team that is churning and burning and not maturing. You want to be a team that understands what it means to do it excellently and always be focused on improving and making it better for yourself and for those you partner with. And that's just been a sensibility of mine. And I feel like when you find people like that, you just want to have those great conversations with them, you want to learn from them. And if you have things to offer them, you want to mentor where you can or share and build community around that conversation.

Speaker A: When you think about someone who is perhaps mid career and has had experience leading design teams and is then either, let's say move to another organization in a design, um, ops role now there are many teams there, larger organization. What would be some of the things you would suggest they do early on, just in the early days as they're getting their feet under them as a new design ops leader?

Speaker B: Yeah, I mean there are some of these playbooks that are out there. I don't feel like the design ops community has done a great job as coalescing around a standard set of playbooks and a book I just read recently by uh, Melissa Perry and Denise, Product Operations. They do a pretty good job of defining what that first sort of 30, 60, 90 for product operations is. And I'd love to see a model for design operations pick up that mantle and say, hey, this is what it looks like. But if you talk to a lot of design ops leaders, they'll tell you very similar sort of stepwise sequence. So I'll just mention it here. The most important thing, I think, and this is, uh, a point of entry for a lot of design, um, managers, is to do a listening tour. So you want to sit down with your immediate team, who are your researchers, your designers, your design program managers, or anyone who has a hand in the discovery and delivery of user centered outcomes. And you want to learn what are the things that are working well, what are the things you're doing, how many meetings are you having? Are those effective? You want to learn everything, the ins and outs of what their days in their lives look like and find all the points of excellence and all the points of pain and friction. You want to get a really good handle on that and that helps you learn who are your people and how can you best serve them. Because then ultimately design operations is what I like to think of as a servant leader role. You're there to make sure that those people are feeling well taken care of. After you get through that internal sort of assessment, then you go to their stakeholders, uh, so who are the people that are delivering stuff in terms of inputs, outputs to design and how do they work and what is it, what is their need, what do they, and don't they understand about how human centered work is being delivered at the organization? Um, you do that up front and upstream of the design work and you do that downstream. So for your engineering stakeholders, and the people who are doing the delivery work, or even sandwiched between. Right. So if user experience ends up doing validation work on the back end of, uh, your engineering work, how are all those pieces fitting together? And you really go across that horizontal set of stakeholders to make sure that from a workflow perspective, that everyone is copacetic or has aired the dirty laundry on what's not working well and where can we make improvements. So you do that part of your listening tour, and then finally you do your vertically integrated stakeholders. So who are the managers, who is the leadership, your other departmental stakeholders from sales and marketing and where they need to either benefit better from or provide better inputs to your user research group and your design group. And after you've done that, it's a massive sort of endeavor to get that assessment. You can start to plot out, these are our biggest points of friction. These are the things that we're doing well today and we don't want to disrupt. We want sort of encourage and put spotlights on these bright points. And then these are the things that we need to really highlight as problems so that we can look at who are the people who can start to affect change, who are the people we need to invite into shaping what that change might look like and build basically a roadmap or a strategy or a plan for doing some change leadership or change management, change cultivation towards a better operating model. And along the way, when you're doing that listening tour, you're also listening for things like what are our problems with our infrastructure, what kind of tooling could we use, uh, what are the unmet needs? And where are points of transition between some upfront, uh, discovery work to our strategy and design modeling, to our design delivery. All those points of handoff are points where there's ultimately failure along the software development life cycle. And you need to look for where can we make those improvements. So you're listening for all those things along the way. And sometimes you need to influence change that is not directly impacting the design group. It might be a change to engineering, might be a change to marketing processes. So you have to find partners and allies who are going to, you know, you have to sit down and have some maybe difficult conversations. There might be territorial grievances around whether that process needs to change or not. And you just have to be prepared for that. All the while, this is a lot of time passing while you're doing assessment and sort of strategic modeling and you're not showing results. So the other thing you need is somebody who's going to have your back or buy you the Runway. You need some executive cover, essentially. So somebody who's going to be your sponsor and say, hey, don't worry about that guy. They're doing what they need to do. Um, you'll see the results when they're done kind of thing that should buy you enough time to. Then once you have your plan, you've shared it with the organization and you have maybe, uh, on your roadmap. These are the priorities for this quarter. These are the things we're going to do that you can start to formulate. Here's the outcomes we're going to achieve by doing this, and here's how we're going to measure it. And here's how you all know we're succeeding when we have these outcomes. And those are all for us from a design thinking perspective. Those are hypotheses. You're there to prove out the models and do experiments and run tests and treat it like a design experiment at an org modeling and operation modeling level. And of course you should expect failure and you should expect to capitalize on your successes. And it's going to be iterative and it takes understanding from others. If you're unable to articulate the plan, the roadmap, uh, the sense of shared destiny and how we'll know when we've succeeded, it's going to be hard for you. So in that first 30, 60, 90, you should be shaping not just your understanding of what the issues are and how you're going to resolve them, but how you're going to tell that story and get buy in and build partnership from those who are going to be around and orbiting your success and ultimately invite them into that success story so that success for you equals success for them. The more you can do that and articulate what operational excellence in design will do for operational excellence for the organization at large and ultimately lead to better customer and business outcomes, the better you're going to position yourself as a leader in the org.

Speaker A: And you can't see me smiling because I started thinking about story and storytelling right before you said the word story. So I've just been m sitting here smiling. Oh, okay. John's just going to read my mind. I don't really have to do my side of things. You're making it easy for me.

Speaker B: What are you doing?

Speaker A: Some of the, uh, either misconceptions or misunderstandings that can trip up someone in those first 30, 60, 90.

Speaker B: Yeah, sometimes, and this is a problem. I think that as a design operations community of practice, we need to do a Better job of doing. Sometimes there's a misperception of the role. Right? So depending on your level of maturity and where you are in your design operations maturity arc, you might think design systems is all that design operations is. If we just had a design system, we'll be serving the need for design operations. Or you might think if we've hired a, uh, design program manager, that it's all about product delivery and if we have that person, we'll have served the need for design operations. It's really part of when you're doing that listening tour and especially when you're doing the vertical integration by speaking with the executive leadership team and their expectations of design, you have to start setting that boundary line. Where is it? Is it just in the design system? Is it just in design program managing? Or is it all the mechanics that make design operational excellence a contributing factor to your strategic business innovation? And if that's the case, you can start to build those defining boundaries. I think the challenges that design ops runs into is, and sometimes this is very much a culture thing that if you're, you know, product led organization, you might think design is relegated to product teams. So hierarchically you might put design ops under product. And that makes sense. And in a lot of ways design delivery is in primary service of product delivery. But ultimately there are things that user researchers and designers can learn and experiment with that might fall outside of the product line. Let's say you're a large organization, you have several products, those products interoperate. Think of Microsoft when you're doing PowerPoint, but then you want to embed some Excel spreadsheets or whatever, some charts and stuff. You can see how, like you might learn something as a user researcher within the PowerPoint product team that might yield some innovative discovery for the Excel product team. And that's where it doesn't make sense to relegate the whole design team under one product and then replicate that in another team and potentially silo those two. Right. If you're serious about how can we buoy up all our products by having research from different product lines serving each other and yielding insights not just to other products, but maybe services and different parts of your organization that fall outside of those product lines, those insights might serve those things. You might have to have an externally organized group of people who are paying attention to insights that come out of those product lines that serve things more in an R and D perspective, to potentially new products, or to other business innovation that might be yielded out of their insight. So in that way, that hierarchical model doesn't always work. And sometimes it works against a Design Ops person. They feel like they're being boxed in. I can't influence how design is being practiced on that product team because there's a different design ops manager dealing with that. Right. And that's where I feel like those are things that might be challenging our work against the true value of where having an ops man can happen. I mentioned the book to you earlier about product operations and they take that same approach. Like how do you maintain a level of ambidexterity? And by that I mean one hand is sort of dedicated to maintenance and management of existing product lines that are there and serving those needs. The other hand is what are we learning that might shape new business strategies, new product strategies or new things that are escalating out of those and emerging out of those. And that allows the organization itself to stay competitive, innovative and that. So it takes a certain level of yes, dealing with it within those product and service line silos. But then having a model or some escalation framework that is more serving at the org level and looking at things more strategically. And I feel like design operations has to take a similar mindset where there are these pods that are serving on those dedicated product teams. But then you have this org model that sort of they ladder up to some more strategic R and D framework that can serve the organization at large.

Speaker A: Mhm.

Speaker B: Those are models that they don't exist. There's no like diagram that shows the best practice around this. And it'll ultimately depend on are you a single product team? Are you multi product team things along those lines. Right. You have to have a level of flexibility in how you look at these things, uh, how you might shape the way Design Ops is implemented to deliver the most value. And it's hard to dictate. Right. Which is I think why there aren't those standard sort of playbooks out there. Because it might take a uh, bespoke approach here or there, depending.

Speaker A: And if someone uh, found themselves saying okay, we're oh, uh, we're about right here with our level of maturity with the Zynops, but we need some external help to get where we're going. How might someone go about finding that? What are the things to look for in a good partner if you are trying to sort of move to the next level with your Design Ops game?

Speaker B: That's one of the primary reasons why I was so stoked when I discovered the summit was that one. I knew there were these people out there. Something that emerged out of the summit or might have hatched in parallel is a group run by Meredith Black. It's the Design Ops assembly, which is essentially a Slack community. It's global. So we have Design Ops practitioners from around the world who are participating in that community. And I think, I would say first, uh, and foremost, join the Design Ops assembly because a lot of questions you might have may have already been answered. If you just go back through the threads, you can, you know, once you're in the Slack, you can do run searches and things around your queries and if you don't see answers you're looking for, there are, there's a great sort of stratification of channels in there. So it might be a question about tooling is a dedicated Slack channel for tooling. It might be around, I don't know, any number culture or whatever. So you can find those channels, you can put in a query. And for the most part that community is extremely responsive. People have lots of stories to share and maybe times those stories are escalated not just as a Slack chat, but they become a presentation at the Design Ops Summit. So I encourage you to look to Rosenfeld Media's Design Ops Summit, which I have the pleasure of curating and have for the past couple of years. And they're not the only ones. Right. So there are other Design Ops events happening globally. Henry Stewart does a really interesting one which is Creative Operations Design Operation Mashup. And those are great, uh, events to go to. And I would say on a regular basis there's monthly, some sort of Design Ops something happening somewhere. If you check out like meetup, uh, various meetups and whatever, and you've mentioned

Speaker A: lots of people doing great work in the Design Ops community. Are there other people or resources or books that say, hey, check this out, this was useful, or is this a

Speaker B: good reference to have handy as a primer? Nielsen Norman's Design Ops 101 article is a good place to start. Back in the day, there's, uh, the Design Ops Handbook, which included entries from Dave Maliff and a number of other core contributors. Meredith Black, who I've already mentioned, and I know that this year or either at the tail end of this year or next year early, there'll be a book being released by Rachel Posman, uh, and John Calhoun of Salesforce. They're on the Design Ops team over there and they're publishing a book called the Design Conductors and that's going to be a great resource. Unfortunately, there aren't a lot of other books that have been written about the synopsis to my Knowledge going to be one of the first. So I'm looking forward to that. The other thing that happens is annually the Design Ops assembly runs what they call their Design Ops learning labs. And those are actually stratified at a bunch of different levels of learning. So if you're beginning in Design Ops, they have an entry level. Um, if you're sort of in the middle of your Design Ops career, they have one fit for that. And then they have, I think they call it Emerging Leaders and Established Leaders is the third one. Those are great eight weeks, uh, where you meet once a week and you're given sort of levels of homework or you're engaged in seminar of sorts around a bunch of topics that are helpful to you at that stage in your Design Ops maturity. So that's a great way to get in also. Yeah. And then there's a handful of people you might want to follow on LinkedIn or Medium. Somebody I'm extremely fond of is Patrizia Bertini. She does a lot of great writing on Medium. She has her own sort of Medium set of articles. What I love about Patrizia's work is that she is always not. She doesn't just look inwardly at what's the. What are the mechanics for operational excellence within design, but she's always looking at how can design be the most valuable operating cog within a larger growing organization, so how can we continuously deliver value? And, uh, so she looks for those markers of where we can become more strategically, uh, integrated for business value. And she does a lot of writing there, so I would encourage that as well.

Speaker A: And when you look at the future of Design Ops, and this is not saying, hey, John, predict the future, but this is thinking about trends that you're seeing and developments that you're seeing. What are some of the things you are just expecting or anticipating or hopeful about in the next 5, 10 years for design Ops?

Speaker B: If you had this conversation with me, I was a lot more hopeful. You know, I was seeing this community growing around this practice and I was immediately on the hype cycle. Like, I. I was on the high end of that hype cycle thinking, this is going to change everything. We're at a massive inflection point, you know, and then the pandemic hit. Of course, that had its own challenges. Everyone went remote and, you know, for design to happen remotely, it meant a lot of change in process. And we're digital anyway, so a lot of that wasn't deeply impacting, but it did have to change our tools and how we collaborate. Figma just had its rise at the right point in time to support that. But other challenges came with that as well. Right. So skepticism around, are people being productive as they're working from home? And how do we truly know? And then, because everything had gone digital during that pandemic time, a lot of organizations went and hired a bunch of designers. Right. So there was a massive sort of push to hiring researchers and designers to make sure that every organization's digital presence was well healed, as, uh, you might expect. That created bloat in terms of staffing. And yes, they were getting good work out of their research and design. And I think it was very necessary. Uh, that was an inflection point that I think helped to push many organizations to think more critically about their digital presence and how they serve or don't serve their customers well digitally. And we learned a lot from seeing which organizations rose to the top during that time and those which suffered a little bit through that time. So with that bloat and coming out of the pandemic and heading into inflation and a sense or a specter of recession, organizations started looking for, where can we tighten our belt? And ultimately felt that researchers and designers and maybe a percentage of their engineers could be let go. And so if you've looked on LinkedIn at anyone who practices research and design, a great majority have these green badges of, uh, open to hire, open to work. And it's been tough. Some folks who I've known for years, and, uh, we're serving at a very senior capacity, are still having trouble finding, finding roles. M. So those are some of the challenges. And so you, if you're standing on the sidelines and you're really paying attention to this, you're trying to figure out what is it that makes an organization feel like a, ah, research and design contributor is expendable, um, because you'd think you're looking for ways to, I don't know. I said tightening our belts. But you might look at it the other way. What are ways we could innovate and drive new revenue and better serve our customers? So we're winning in the marketplace during this hard time. You might want some of those researchers, like, letting them go may not be the best idea. So there's still this work, I feel, that needs to be done in design leadership, but also for design operations to say, here's the right percentage of, you know, if you're looking at ratios of researchers to designers to engineers, maybe don't make these cuts so severe across this one particular group because they're driving some strategic business Innovation for you. It's hard conversation to have because sometimes those things aren't being appreciated in the right way. Design debt is a thing. So there's a backlog of things that became key insights that were driving design roadmaps that were never implemented in product teams. And then you jettison those designers and those researchers and what becomes of that. And so that's what I meant by like it's. There might have been some things you let go of there that would have been key institutional knowledge to have held onto. And that's a fight we to have just to talk about resilience anyway, around what? Well, demonstrates the value of research and design to the point where if we're making hard decisions, maybe it's not just calling research and design bloat, but it's about putting it to use and applying its pressure point to different aspects of your business. Uh, that you can drive new revenue streams, that value perception conversation is hard. And part of that is we just need to show the stories. We need to showcase those stories of where research and design is yielding business outcomes. Uh, we need to show how that's done repeatably with efficiency and at scale. And I think design operations are really good part of that story. So where we're heading from a futures perspective is one making that conversation out loud. Not just a private one within the walled gardens of our design ops community, but with our business stakeholders, with our horizontal stakeholders and getting them on board with, yeah, let's find our operating model, our collective operating model where you guys are uh, delivering value. And then the biggest part of that, I think that will help with resilience is better integration. And that's from a process and practice perspective. But it's also from a tooling perspective because if you look at research and design tools, they really serve as research and designers and the and design Org within uh, any organization. But they're not well integrated. They're getting there. There are plugins and open integration models between jira, uh, and figma, for instance. They're workarounds. There are workarounds. And a lot of them yeah, and a lot of them take custom development work work. Sometimes that custom development work is falling in the hands of design ops managers. So you can see from a futures perspective if organizations are investing more in this, that better tooling and better integration models and better workflow from learning, uh, as an organization to responding at scale as an organization, include a research and design ops story, that that's where I see the future going, is that we're more deeply integrated from process practice and from an infrastructure standpoint.

Speaker A: And John, as we've been talking, is there anything that you're thinking or feeling that you would like to say that we haven't touched on?

Speaker B: I mean we've covered a lot of ground. Um, of course I'm a huge fan of the summit myself. Like I said as a, both as an attendee in 2019 and as a curator these days, I'm still looking for great stories to showcase the value that Design Ops and Design Ops managers bring to any organization. We just finished uh, what we call the CFP or the call for proposals for the summit just wrapped on Sunday. So we're heading into a review period now and we're going to be building momentum towards the summit which is in going to be in September. And I would just encourage folks who are hearing about it for the first time here on your podcast to start getting psyched up for it. Look for announcements as a summit comes closer and closer. We'll be doing community video conferences, so keep an eye on Rosenfeld Media's website for those community video conferences. Those are open to the public for anyone to join and their conversations that sort of are on the themes and the building up towards the actual summit. So those are great ways to commune and learn and build thought leadership and yeah, that's, that's about it. I mean other than that I'm myself, I consider myself a very open and doors open policy. Uh, if you contacted me on LinkedIn with any questions, always happy to answer and connect with you. So feel free to find me and connect me with you there and we'll

Speaker A: put some, some links in the show notes so that people can, can find you and your company. And in preparing for our conversation I found uh, some great articles that you've written and co written and that was fantastic. So John, thank you so much for joining us on the show, but also for the way you are shaping and participating in this community and um, driving a lot of the choices and considerations and conversations that are going to shape that future for Design Ops.

Speaker B: Excellent. Thanks for having me. It's been a pleasure.

Speaker A: I hope you enjoyed this episode of the Design Thinking 101 podcast. This conversation was recorded in 2024 and it's coming out in 2025 and obviously a few things have changed since then. I didn't want you to leave the episode without realizing, yes, we may have talked about different things if we were recording this with everything that's happening here in the United States with the federal government. With that said, thank you very much for listening to this episode. You can find out more about the podcast and, uh, get more information about, uh, the ideas that we talk about and, uh, other things from me at Ask Like a Designer. It is the Ask Like A Designer studio. You can sign up@fluidhive.com podcast. That's fluidhive.com podcast. And I will send you podcast announcements, ideas, books, uh, all sorts of things. So I hope you'll join me there. And until next time, stay lucky and stay safe.