Deep-diving into the Design Ops role - with Pete Fossick Design Director, Coach & Trainer

Welcome everyone to another episode of the Product Bakery Podcast. I am here today with my dear co-host Christian and we have a special guest, Peter Hosek. Hi folks, how are you? Before we jump to the conversation, I just quickly want to share that if you have any questions, you can always drop them directly on the website. We have all the episodes uploaded there with a quick recap and all the live minutes, as well as a comment functionality that either myself or Christian will be reading or the speakers or our guests directly. And besides that, you can obviously also follow us on all our social media channels for the latest content and updates and all the new episodes. And with that said, I hand it over to Christian. Thanks. Hi, Peter. It's a pleasure having you. Well, thank you for inviting me. I'm looking forward to it. Yeah. So we talked recently to Schrutti from Number26 and we discussed the topic of accelerating design teams and development teams with an integrated design team. And we touched up on the topic of the DesignOps role. Unfortunately, we weren't able to fully discuss the role and the responsibility of it. And based on that, we get a couple of questions and feedback from our community if we can dive deeper. So Alex and I, we just thought you would be the great person to talk to as the co-founder of the DesignOps Network Global Conference. Maybe you can share as an introduction a little bit where you were coming from, as well as what made you so caught up on the topic of DesignOps? Sure, sure. I appreciate the question. So I think I'm like a lot of folks who find themselves in UX design and UI design and service designers. I had an education which was not actually directly related to that. I'm middle-aged now and I grew up in England and went to a polytechnic, which is like a university. And it was about design and technology coming together. And it was actually looking back at fantastic education. And I did my first degree in product design, industrial design, designing hardware products. And I was just lucky enough to be taught by some guys who were very into what was then, it wasn't called this, but it was human-centered design. And it was very much about putting the user or the customer at the center of the design endeavor. And then I graduated and I worked in 3D. I really liked making furniture. I did some work in that, had a business doing that. But I also was very interested in technology. And one of the projects or a number of projects that I did when I graduated were around the speculative design and the future of technology and interface. And I got into interface design probably 1988, 1989. It was the world of the Ignatian computer. Apple had brought out their kind of classic and their SE. They were using the iconographic interface. And I moved from product design, 3D product design, into interface design. And I went out to Silicon Valley about 92, 93, and was really blown away by the culture of design there. I touched base with Bill Moggridge from IDEO, got to know some of those people. Bill subsequently was an external advisor on a course I set up in America and was really excited to join that first nascent wave of digital tech and web. And then from there I moved into experience design and service design. I was using design thinking as a way of solving business challenges and business problems. Some people call it business thinking or business design. I think really it's strategic design. And that's a phrase I'm beginning to see resurface again. It was very popular in the early nineties. And my career is meandered here, there, and everywhere. It's taken me to all the different continents in China. I was in Hong Kong for six years. I was in America for three, four years. I've been in Australia. I've worked all over. I'm really gone where the kind of the interesting work is and made an effort to explore culturally these different areas. And I find myself about three, four years ago, IBM was leading the service design program there at GTS in Dublin, which is the Global Technology Services Group. And was working with the likes of Doug Pound to augment and look at their enterprise design thinking and look at it from a, with the service design lens. Because what they were doing was really good, but it was more kind of product focused and less transformationally focused. And we, yeah, we just were toying about with it for a year, looking at playbooks and toolkits and things like that. And I think that's where the whole ops thing's kicked off. And in terms of underselling language, I've always felt that actually back in the day, IDEO, when they developed the methods cards with, I think it was the Helen Hamm Institute. That was a long time ago. They were one of the first to productize along with Frog Design and Larry Keeley in Dublin to productize innovation and design and then operationalize it as a set of operators. And I think design thinking, although it's a phase gate approach originally, it was very much about how you have these processes and practices and particular roles. And really some of it is language shift and change, but that's what I was like three years ago. So that I started getting into ops as a way of articulating the approaches that I wanted to take. And I saw that we're being successful in the businesses I was working with and the clients I was working with. What is the design ops person doing? Yeah, good question. I ask that myself every day. What am I doing? I think a lot of it depends on the business sector they're in and the maturity of the team that they're with. But I always talk about the design ops person, the ops person is responsible for people, processes, practices, performance, and place. And design ops and research ops are the two stronger kind of communities that have emerged. But I think there's an emerging innovation ops community, there's a products ops community, there's a creative ops community. And also there is a studio ops community that's emerging. And actually that was studio ops was something that I tried to land at HSBC recently when I was engaged for a short period to do some consultancy work. And this idea that really it's those operations of who it is you need to hire, what competence and skill sets they need, what level, what kind of stagecraft do they need? And what sort of statecraft in terms of being able to reach out to the business and communicate and also around that what sort of stagecraft. So in terms of place, whether it be a digital environment, how do you facilitate workshops? How do you bring people together? How do you do critiques? And my feeling is that the design ops role or head of design ops or someone like that, whatever title you want to call them, they're responsible for making sure the right people are in place and have the right tool sets and right skills and competencies at the right level and experiences. They're about adopting processes that are proven to support flow and deliver at pace with velocity. I think it's about using a set of practices where there is a common alignment around language and ways of doing things. And I think performance is about measuring both the design team's performance, but other aspects of the way design is employed and delivers value within the wider business. So that might be about customer satisfaction and some of that qualitative metrics. And then place is about creating the environments where people can collaborate and innovate and work together, whether it be in a speculative approach where it's at the beginning of a project or the need to make change, or there's a crisis. So that might be about a physical environment where people come together and for support in digital environments, say Miro or Miro where using a tool to come together. But I do think it's about having a sense of place where you can not only work, but you can also find information where you can speak freely, where it's safe, where it's flat, and where it encourages people to be creative and productive. And I emphasize productivity. In our last episode, I was already critically asking, shouldn't these things you mentioned not be done by let's say the design lead VP design as well as the designers? I think that's a good point. I think when you look at the day to day business of running a project, there's enough to do in getting people to turn up at the stand up, doing the daily work, making sure they're resourced well, being creative, whether you're mapping out a customer journey, or you're ideating, or you're doing a workshop with your stakeholders and your product owner or whatever. And then there needs to be an organizational function outside of that, which looks at the bigger capabilities and how you scale those capabilities. And that's why I mentioned maturation. So when you look at, say, an organization like IBM, When I joined them, they were four years into a program of scaling design thinking, and they needed specific people who were responsible for that. They needed coaches and trainers who could train people in design thinking, and the tools and the guides and the approaches that IBM took. They needed somebody who could do the e-learning. They needed somebody who could sell politically the importance of design and socialize the successes. They needed someone who could govern that. And then when you see it like, that's kind of design management, what used to be called design management. And I think that ops is very much around the managing of design, but managing design has a connotation of top-down, whereas ops is more about how you can work in an agile cadence, where you have teams mandated, but they're given the resources and provided the resources in order that they can do what they're good at, which is creative problem solving, framing problems, using their tradecraft to visualize complexity and abstract complexity, to ideate, to storyboard, to wireframe, all these kinds of skills that designers bring to the table, and not to be tied down with, I need to set up this research meeting, or I need to go and do this hiring and so forth. And I think ops, I think somewhat, for ops to be effective, you need scale. And this is why I think larger businesses, large corporations, larger government agencies are adopting ops so quickly, because they see it as having a centralized, but distributed function. They see it as supporting an overhead and supporting the kind of the infrastructure that designers need, researchers need to do their jobs. But so where would you draw the line, if you would have to, between what design managers do, what design ops do, and what then the team does, especially like also in, let's say, classic day-to-day product design team? Sure. I think, first of all, management is something that everybody is responsible for, you know, managing their own time, or managing a team of people, whether if you're a design lead, but there is an emphasis there on kind of production, that you're in a cycle of delivering to those sprint outcomes. Typically, you might work in a six-week sprint cycle, or a 10-week sprint cycle, two weeks per sprint, and you're getting on with the business-as-usual stuff. And I think design leads, that what they're about is bringing their kind of experience and leadership around the creative direction. They're bringing in their experience around where there's value to be found. They're bringing in their experience about how they interact on a day-to-day basis with the different folks in the product team, or if they're designing a service, the service team, or whatever you want to call it. Ops, for me, is about that infrastructure which supports that. So I think it's about formalizing governance process of what constitutes good design. And that turns up in different ways. So the government in the UK, gov.uk, they've got a service manual, they've got a GDS, they've got a kind of discovery alpha, beta process based on the double diamond. Yeah, they did an amazing job. It is. To deal with something so complex as government, you need to have a rhythm, a banging of the drum, to align around a language, align around processes, and to formalize that. And I think that's the upside. Now, what interestingly, when I was there recently doing some work, is when I asked for where's the toolkit, there's no toolkit, right? They might have some examples of how a service blueprint's done, but everyone's doing it different, right? So I think the next level for that kind of organization is to formalize playbooks. Here's the research ops playbook in terms of this is how we do research, this is how we archive material, this is how we make our insights usable and actionable, and this is how we make them findable, this is how we socialize, this is how we set up user research. Here are the software tools that we use, and these are the methods that we use. And we might use something like, for example, I use a technique called Service Safari, someone else might do an empathy map, someone might do some contextual studies, somebody might do some user interviews or stakeholder interviews. These are methods that we use to gather information. And I think formalizing those as a set of methods in a methods cards deck, or putting it in a digital equivalency, which I've done in the past, in the recent past, is part of operationalizing. You're creating a product and you're operationalizing it. So it's something that can be used repeatedly. And governance is a big one. The projects I've worked on recently, whether I was out in the Middle East and last year before, I was working on a large scale project with one of the governments out there, and it was pitching with another company to land this big strategic vision and deliver. And a big part of that was governance and design governance. How do what good looks like? How do you, as a team, enable the people involved in delivery to meet that mark, that standard? Whether it be about accessibility and inclusivity, for example, WCAG level AA, is it an accessible service, government service? Does it deal with people with impairments and support them in their journeys? Those sorts of things need to be operationalized in a way that enables them to be repeated over and over without reinventing each time. And so I always think that Ops is about supporting flow and movement, and it's about an infrastructure which gives you the structure and the lines on which to run to enable you to create efficiencies and to deliver outcomes at greater speed. And I think that becomes all the more imperative when you're in an agile organization. So in terms of design management, I think there's an overlap. What we used to call design management might be a design Ops person now. The difference is this design management was probably in a phase gate world, and design Ops is much more to deal with an agile world. And because we're dealing with DevOps and we're dealing with tribes of people or teams, I call them core teams where you've got designers working with developers, working with business people in a team together day to day, and they need to go and say, look, there's the tools for that. There's the guide for that. Here's my tool chain that's already established. I can use that to collaboratively work together. It's having it at your fingertips, things like Figma and InVision and Mural. It's having the ability to work outside of the internal security of the intranet because I need to do research with, say, Zoom. And it's having those tools concatenated, working together so you can give your handoffs over to someone else. Typically, in a day to day, you might have a UI designer developing a design system with a developer, and they're creating a repository, which is an atomic set of components which is built on atomic principles. Now, in the past, in the not so distant past, there wasn't anything like that. And people were, it was hard-coded. There were seven different colors of green button. The buttons were all different sizes. Nothing worked together. There was no hierarchical or parental-child relationship between those components. Updates were really slow and laborious to make. And I think design ops has turned up as a kind of manifestation of design management to support that idea of design, deliver, drop, and measure, that kind of agile manifesto. So, yeah, to answer it in a sentence, I think there's a lot of similarities between design management and design ops, but there's also a lot of dissimilarity. And I think it's all to do with cadence of work, and it's to do with the maturity levels of the business. And it's to do with whether something is centralized like design management or decentralized like design ops. You still need a head of ops who can support and facilitate and manage your people and your resources, and that's design management. In the same way, on a lower level, you've got a design lead managing the day-to-day delivery of the team, and that's management, right? So I just think it's a more specialist set of skills and a slightly different way of seeing how people, practices, processes, performance, and place work together. And I do feel like from what you're saying that it also ties back to maturity and size of a team. If you work in a smaller team, maybe you have a head of design who covers both the ops side to one extent or not. Yeah. And in a bigger organization, you obviously specialize a little bit more. I think so. I think that's a good point is that somebody who's maybe a head of design is, it might be that they're responsible for hiring and firing. They might be responsible for doing the screening for the research and helping the researchers do that, or you give it to the researchers to do. They're also about making budget definitions for, say, resources. It's much more general, right? And I think really the thing about ops is it is about scale. It's about when you need to scale capability quickly. But I do think there's a bit of tautology here. I think when we spoke previously, what we used to call design management is now turning up and being posited as design ops in some respects. And I do think that sometimes each generation develops its own language and its own way of seeing the world. I think it's something to do with that. But when I was a younger fellow, more your age, a distant memory now, but the Design Management Institute, I think it's based in Boston, but they were doing a lot of work in this area about how you get design thinking into organizations. How do you measure the value of design? What sort of tooling you should be using? What types of design you should use? Speculative design, UX design, UI product design. What type of innovation approaches you use? So I do think that some of this has been covered off by other communities elsewhere, and perhaps we're not always aware of it. And I do think that part. this is about, this is the other thing now, when I go in and look at education now, which I think is in real crisis, the traditional model of higher education is in real crisis, and it's right for being disrupted, not least because of the situation we find ourselves in now with COVID and the way people work together, but you go into some schools and they don't really have a good understanding of what's required in the, let's call it the experience economy, and the type of tools and practices and processes that we need to understand, and the methodologies that students need to graduate with. I think the good schools do, but they're still banging the drunk design thinking, it's a phase gate process, and there's an awful lot of reliance on inspiration and lack of inspiration, and hoping that you'll have this amazing moment when you see the answer. And I'm a big believer, and this is part of the arts philosophy, is that you can work through a process with a set of practices that enable you to go from something very vague and unknown to something hyper-specific and surgical that solves the right problem in the right way at the right price, and that people want to use. And as we move forward, I think increasingly being equipped with a sense of where you are in terms of your capabilities, being equipped with a set of tools that you're able to use, and methods that you're able to use, and being able to improvise within the context of where you find yourself working in an agile environment, are key prerequisites to being an employable person in the world that we find ourselves now. And I do think that sometimes universities aren't delivering that. There's other places which are, I think you see it with schools like General Assembly, which has sprung up over the last five or six years. My own academy, IXD Academy, we take these processes and we teach these processes and these approaches to professionals, but also to younger people too, without relying on some of the, I guess, some of the old ways of doing things. I'd like to quickly make a sanity check on the role definition, because I was always under the impression that the whole responsibilities you mentioned in terms of making sure that you can scale, that you have the ability to do your work, to have decisions on the tooling, et cetera, should come out of the main responsibilities of the heads or design leads. What I took away now from your design management perspective is that it's more like a natural evolvement, or let's say a mitosis of the existing functions to be able to better scale and grow. Is that correct? I think the mitosis is a good way of describing it. I think you still, look, head of design might still be working in this way, but as you get more complexity and as you have the need to specialize more, there's a need for these roles. I think we're seeing that emerge in the marketplace. So you've seen banks like HSBC recently set up roles like head of design ops. You've still got head of UX and you've still maybe got director of UX and those sorts of roles. But I think their focus increasingly is about driving the creative delivery and supporting the teams in getting to the right solution. Whereas the ops is about governance of design. It's about quality. It's about tooling. It's about measuring the performance and feeding that back in. It's about socializing the successes and failures. And so I think there's a very different emphasis now. And design ops to me is what you might call, it's more like the traditional design manager's role. But again, you don't have like head of design management. You see less and less of those roles now. So I'm seeing that. And I think that's because the cadence of work has shifted. And in an agile world where it's permanent beta, where it's continual improvement, where you're continually releasing throughout the day, it needs a different type of way of managing design. And it's more about facilitating design and facilitating the practices and processes rather than trying to manage them. I think that nails it. Absolutely. My understanding. For today, it'll shift tomorrow. We're not sure. And again, other people might see it differently. And I think it's interesting. I was talking to somebody the other day about a head of customer experience operations. And I thought that's a new take on it. And I wanted to know more about that. And again, customer experience has come into the common parlance now. The common language we use has become more and more popular as a way of describing a particular set of approaches to designing for customers, which is about datafulness. It's about data-driven or data-informed strategies. It's about how you connect with customers. It's about how you deliver bespoke personalized experiences. And that's really only possible in the last five or six years plus where we've had so much data being collected and we can do things like attribution modeling to see where people started and finished their journey and how they transacted. And that requires a move on from user experience, which is so general and generic. And some people find it too impersonal. To me, whether you call it human-centered design or people-centered or user-centered, it got us to the point where we needed to start specializing that language because we're trying to be more specific. And I think where you have specificity coming out in terms of business value, like customer experience and customer experience ops, you adapt your language and you adapt your processes and you adapt your roles accordingly. Interestingly, I think CX, for example, customer experience, it's become adopted because I think the business people get it. They understand products and customers they get. When you talk about user experience, it's a little bit vague. It's a bit too abstract. It's maybe a bit, can't quite get a grip on it. But when you start talking about customer experiences and share of wallet and the metrics around that, then they get, ah, right, now I get it. You're talking my language, you're talking my business language. And likewise with operations, it's using the language that business understands. So when you talk about, look, we want to implement some processes here and we're calling this design ops. Yeah, I get it. I understand what an operation is. I understand what an operating model is. So yeah, I just think really it's lending a little bit, talking a little bit to those sorts of stakeholders a bit better, a bit more effectively perhaps. Yeah. But having said that, it is very new. And when you do turn up and have these conversations with people, they go, what? Is this the latest buzzword? Two years ago, I was talking to some very senior people in a global agency, one of the top eight, nine groups thinking Accenture, Deloitte, all that sort of level. And there was a real kind of resistance to accepting the language because there was only just getting used to design thinking and service design and experience. Now you're coming up with a whole new language. It's like this tissue rejection of like, ah, you know, what's this? You know? Yeah. I pointed out when your clients are using this language, your clients are using these processes, they're hiring for these roles. Shouldn't you start talking that language as well? Shouldn't you start thinking about how, because otherwise you're getting left behind. You're not as relevant. So yeah, I think it depends on the maturity level where people are and so forth. How much would you say, like, how much is simply new words, new language and buzzwords? How much is actually like the role developing and new to the market? Because I think like when you mentioned, even looking back in the past, it was called like a little bit design management. It was a similar role and indeed it is now adapting to agile, but is it really that new? And also to add to that, apart from the names, the whole exercises and the whole things they are doing on day to day basis haven't changed. Yes and no. I think some of it for sure is a bit of tautology and semantics. I think absolutely. But I think fundamentally the structure and frameworks around ops is quite different and distinct because it's relying less on individuals with a particular experience set. And it is about productizing and it is about putting in place particular steps and processes and having, for example, playbooks, methods, cards. The time was no one had anything like that was new. These days, everybody has playbooks or at least majority of decent companies will have some playbooks. They'll have some guides to how you do research. They'll have some methods. They'll have, they'll folk that they will have increasingly a research capability, which doesn't expect the researcher to be doing their recruitment. And I think this is where we move over from, yeah, it's not, we have had design management before and we have had people who've supported that into something that is much more formalized. Yeah. But yeah, I do think sometimes there is a little bit of tautology and I think it's reinvention of language and buzzwords and people jump on it. And interestingly, what I've seen is those, sometimes those people who do that, they perhaps don't, haven't had an education like in a design college or university. They perhaps don't have some of that perspective from say, being educated in, in, in say, for I can say, let's say a creative university, like say art center or Stanford D school or central St. Martin's or whatever. Having said that, I think what I do see is a very distinct set of skills associated with these new roles and with this new way of thinking. And for sure, it is quite different from perhaps a traditional design manager, because again, I don't think you see many of those roles around anymore. And there was maybe a need to redefine who was managing governance and formalizing the processes around the way we do our work and making sure that people had the skills and frameworks that were necessary and particularly in a large organization or in a company that was scaling. very quickly. But yeah, for sure. I think there's always a bit of that going on. If I remember, it used to be about lean and then it was Six Sigma and it was design thinking and, and, and then it's, it's blue ocean strategy and it's 10 types of innovation. And, and I think every few years, something new comes along and it speaks to what happened before, but it has something different. Yeah. And I think we have got to be careful not to, uh, be doing what I call the Empress clothes. I think we should call out bullshit when we see it and hear it. Yeah. But I do think there's something definitely different about this. And I think it is about this formalization and being able to, uh, to work in a slightly different way in an agile environment. Cool. This brings me also a little bit like to the next question, especially if we talk about like education and so on, what would you say that someone needs to have as a background in order to become a design ops manager? Yeah, I've worked at various universities over the years. I worked to education in Hong Kong. I've worked in America and I've worked in England at some of the top schools. And, and Mark, there's a couple of things I want to talk to you about this. One is I really do feel that the higher education system, particularly in England is in crisis. I think people are being charged too much for too little. I think the resources, um, have diminished vastly. The environments that they work in don't really support the approaches that we talk about around collaboration. People are squeezed into these, um, signature buildings, which have cost an awful lot of money, but don't, are not really always fit for purpose. There is some amazing educators out there and there are, and students are amazing wherever you go. They're first in Hungary. I think it's not a matter, I think one of the good things about a general education at say degree level is that it's preparing you to go into a lot of different directions. And I think that's really important. I don't think we should be offering higher education degree courses in design arts. I think that's for professional development. And I think the prerequisites for that is, I would say, first off is get a good design education, get an education, which teaches you about how to do human centered design, how to use craft skills to visualize and build, how to solve problems creatively, how to work together collaboratively. And I think those are the prerequisites that the students need. I think there's a lot of courses which, which do that very effectively. I think that there is a greater need to understand business and business thinking and understand how a business functions and how organizations function. And I think there is a lack of that with design education still. I think good courses, I always try to have those sorts of classes in the courses I taught. When I was at SCAD, we had entrepreneurship for designers and we, they had to build a business plan. They had to do spreadsheets. They had to understand profit and loss and that sort of thing. To become a design arts manager, again, it's about people skills. It's about understanding how teams function. It's about understanding design processes. It's about understanding the different craft of stage craft, trade craft and stage craft. And I think that comes with experience. It's about working on different scales of projects. One of the key things for me about good, effective ops people is also keeping abreast of developments in the way technology works and the way the tools work together. And I think that means that you've got to be involved with dev and tech and business to make sure that you're delivering a good product and understand what good product is. What worries me is you'll get people who, doing a design management course doesn't make you going to be a good design manager, right? Back in the day, but you had to get some experience. So I would say the prerequisites for being capable of running in an ops role is get some experience. And I don't just mean two or three years experience of doing a bit of UI or UX. I think it means a good ops person has probably been running studios, has been running multi-agency environments, has been working with lots of different types of stakeholders, has been doing lots of work with users and understands the challenges of connecting with their specialized researchers. And at the same time, has worked on building with developers, building products and building systems and services. And that doesn't happen within two or three, four years, having done a general assembly course. That takes time. And I think yourself, some of the best people are those who have been there and done that. And I think that's a big part of it. Yeah. So just to knock that out is one, get a good design education because you have to understand what it is to be great and be a designer. Two, get some experience working with lots of different projects and lots of different people where there's an emphasis on design led strategic design, design led strategy. And two is to get some experience, which takes time. And then you can actually get into an ops role. Yeah. And I think that's what with people who are being employed as ops leaders, whether it be a design ops or research ops leader. Yeah. They've got a good few years under the belt. They've done it. They've been in the trenches. Nothing beats experience. My mom, my mother always said, a drop of experience is worth a bucket of theory. It is really about experience. Can you share what services you offer and what you're teaching people who want to deeper dive into design? Yeah, last few years, I've been working with companies, like I did some work at Publisapient recently, where we built a toolkit for them. And we looked at some playbooks and we piloted those. So it was really about capability build. So the sorts of courses I offer for professional level through the IXSD Academy is we offer rudimentary courses on, you know, things like service design, UX, UI, we have what we call essential programs. And what we do there is we have a playbook and we have various tools, various methods that we teach often associated with a canvas or a map. And we look at how we can turbocharge different activities by bringing them together. How do you solve a problem? How do you frame a problem? How do you map experiences? How do you map journeys? How do you design services? How do you prototype services, that sort of thing. And then we have an Ops course, we just actually launched an Ops course, which is Research Ops and Design Ops 101, Closing the Loop. So I'm beginning to see research is going off over there and design's going off over there. And there's something being lost. And it's like, how do you close that gap? And that's about how you matriculate from a problem statement and a need statement to an insight, to hypothesis, to a backlog. So we emphasize a lot of the agile approaches around how we work with speed and flow. How do we use things like backlogs and user stories and epics? And how do those turn up in different guises? And we do hands on learning. So we show and talk about the theory very briefly. And then we get into it. And we start actually using these methods. And they build from the theory through to the practice. So when people come do a course, they can then go back to their offices to their or to their homes these days. And they can start to use those approaches and use those practices and principles. And with the Research Ops and Design Ops, we're looking at the way research turns up with different lenses, and the different approaches and practices you can use, how you then take the findings, and then articulate those and socialize them. How do you deal with legacy insight? How do you manage those archives? And then how do you as a designer pick those out, and then use them in a backlog and verify your concepts and ideas and go back to research to do usability testing and so forth, or using prototyping to de-risk and then moving it into a delivery sprint. So it's all about doing it again, 20-30 minute learning sessions, have a go, have a do it, and then take it back to your program. Actually, when I hear about all these processes, and like also cycles, backlogs, and so on, since Christian is a product manager in this round, I'm also wondering like on what the best combination and collaboration would be also with a product manager, especially when it comes to backlog, when it comes to planning, when it comes to prioritization, and so on. Because like historically, that's a little bit like the DPM role as well. And I know there's some overlaps between design. Yeah, yeah. Again, it varies company to company, and the sector you're in. But I would say that, to me, the product manager represents the business. So that if you look at the Venn diagram of design thinking, they're in the business bit, they should have a good understanding and knowledge of what user experience design offers, and the importance of good, effective, and consistent user interface design. At the same time, they've got to understand and how to have a conversation with tech, because obviously, they're using a platform and building stuff on a day-to-day basis. And one of the issues that I sometimes have with product is it's too myopic. So product owner will be too, or product manager will be very myopic about delivering a set of functions and features. I think when the UX person turns up, or the interface designer turns up, is that, well, certainly the UX person or service designer, is you're trying to see it in a much bigger picture. But ultimately, that's the product, someone who's responsible for a product is about making that product work at its optimum, and making sure that the user can use it effectively, and the business can generate income by using that product or at least value. So I think that from an Ops point of view, it's more how Ops turns up to facilitate that, because I think Ops has a role in helping the product manager understand the approaches that can be used to design whether it's incremental innovation. and using something which is about tactical delivery versus when to get strategic and using something like speculative design or service design to help set a strategy and a roadmap. And I think OTS has a role to play in that, in first of all, giving people the tools to learn, but at the same time, giving them the playbooks and giving them the methodologies that they can come together when they're in a mode of creativity or strategizing, they're using the right tools and they're sharing the right language and coming together. But I do think it varies depending on where you're at. I've worked with product managers who are very protective or almost dictatorial. And I've seen them fail because they're not thinking widely enough, they're not testing and validating the concepts. And this is where, again, the research ops things come in. I won't talk specifically, I won't name the client, but it was a very large company involved in entertainment and gaming. And you had a bunch of people who didn't understand design, didn't understand user-centered design, owned products, and they were just doing what I would call me-too products. They were looking at the competition and saying, oh, we need that feature. And so there's this incredible kind of Frankenstein products being built, which were full of legacy and full of legacy features, which were not tested adequately before they were released. And when they were released, they were released with so many bugs and inconsistencies in things like the interface or journeys is that they were failing. And I think this is what happens when you don't have a product manager or products owner understanding design, understanding the role of design, but also understanding the role of research and user research. Some of the diagrams you might see in some of the presentations I've done is I have these three particular areas and I have research, definition or design, and delivery. And I think that each of those areas have backlogs. So as a product owner, I should have a backlog, which is about speculative strategic things that I need, which are bigger bets, which need to be hypothesized and then validated. But I've also got some immediate needs about functions and features that I need to learn. And that's another backlog for that. And I think research has a role to play in supporting the product owner and the designer has a role to play. And this is where ops comes in because you can get that flow. Ops is all about flow and getting that movement and velocity and having a cadence. So when I was working with his businesses, we moved from a very fragmented opinion driven, I'm a specialist, it's my product, you do what I say, to an experimental approach where we're using sprint cycles of two weeks where we had the first week was about discovery or speculation. And the second week was about building and testing. And then every two weeks we were in London testing new products, new product features, testing high level, new games, new approaches. And the speed at which we were able to work was only made possible because we'd adopted more of an agile cadence and operationalized our approach. But again, that business was still an immature business when it came to design thinking. And before I arrived with the colleagues that I work with, now is a small cog in a much bigger machine there. They'd already gone through two experience design teams. They'd literally brought in a team, the business had been so anti-design, they'd left, another team had come in, they'd eaten them up and we were the last stand. And there was a lot of conflict and resolution that needed. And it actually took a senior C-suite guy to come in who got it to bang the table and fire people and say, you're old school, you're out, goodbye. And brought in a new set of people who had a learning mindset. And I think that's one of the key things here as well is we've got to approach all these things with a learning mindset, yeah. That's also what I'm always teaching and coaching the product people that I'm saying, hey, you need to work close together with the researcher and the designer and evolve them. To be honest, I don't see a difference. I think these people should be like a pair of twins. They should work together, do things together and develop together the same mindset. Absolutely. One of the big mistakes that I see teams use is they spread the butter too thin. They have a designer working on two or three projects. They have a researcher working on two or three projects. They have a business analyst working on two or three projects. You've got the product manager or owner running around trying to get things done. You've got a scrum master with them trying to get things done. Yeah, yeah, yeah. And it's bullshit. I use the 80% rule. You're not going to make any change and you're not going to be effective unless you spend 80% of your time working on that new product. It's different if it's a product that's been released and it's tweaking. But fundamentally, you need people to be in that digital room working together on Mural, aligning, assigning tasks, and getting on and doing their work and then coming back together regularly for their standups and throughout the day. I often see a lack of that. I see that what happens is that they're not using user researchers effectively. They're not using any user research often. That's the first thing that people kill to kill a budget. I've seen it at the start of a project, even in an agile organization where you've got the product owner with the tech lead off in a corner writing out the epics and user stories. And there's one time I had to bang the tail and say, look, stop, you know, let's get the designer and the researcher here at least to listen. Let's get, why don't we do a workshop on this? Let's spend a few hours and let's use some techniques to do a diversion and convergent approach about this. And we did that and the results were amazing. Everyone got aligned a lot quicker. People agreed to support each other with a lot more, you know, kind of commitment. And people were then able to go off and do their specialist trade craft in a way that made sense for them, having aligned around a set of objectives and a set of epics and user stories that they bought into. And then move into a sprint cycle that was prioritized properly, T-shirt size properly and ended up being a lot more effective. But so often I see just the product owner or manager just off in a corner with the tech lead. And of course that's just two sides of the three-sided diagram. If you don't include design, then you end up with something that's not desirable. It ends up just being a set of features. So it's no good. It's too transactional, right? Yeah. Yeah, definitely. Maybe just closely like trying to tie like all the loose ends together as well. We also talked about a lot of different ops roles now from research ops to design ops to dev ops and so on. I remember like when we met, we also talked a little bit about this umbrella of innovation ops in general that tries to tie the things together. So I was mainly wondering if you want to share a little bit like your thoughts on innovation ops. Yeah, thanks for asking that. So it was last year, the design ops conference. We run the design ops conference every year. We've got our third year this year in June and we're online again. And one of the things that I saw in my work and also through the different conferences that I attend is that a lot of people were talking about design ops, but actually it was innovation they were talking about. And I wrote a paper about innovation ops recently, which looks at the notion that innovation and there's different types of innovation and there's different roles needed in innovation, like the same there is in design, there is in research. And you need to create an environment where people can be innovative. And you don't want to use the wrong type of innovation to try and solve the wrong type, a certain type of problem. There's incremental innovation, there's disruptive innovation and so forth. And I said that really to enable companies, and this is again at scale, to be disruptive, they need to adopt an asymmetrical approach the way they work, which means asymmetric in the sense of guerrilla, adaptable, highly plastic, to exploit opportunity and to deal with chaos and to deal with the changes, for example, COVID. And I'm a big believer that crisis actually drives innovation. You don't change unless there's a crisis. The banks didn't change until they started being threatened and disrupted by new digital disruptors. These incumbents are very symmetrical, they have these very hierarchical structures and decision-making happens at the top and works down. Even if they're a flatter organization, there's still a lot of that. With an asymmetric organization, you have highly distributed teams and highly distributed decision-making. It's highly lean and it's highly operationalized. And innovation needs to be operationalized in the same way design and research does. And by that, setting up things like crowdsourcing capabilities, so you're getting out into the business and eliciting ideas, about using the right type of innovation tools for strategic roadmapping. Again, you can operationalize those. And we see those with toolkits or methods, say Blue Ocean or Larry Keeley's 10 Types of Innovation. So, sorry, I'm misspeaking there, but Larry Keeley's Model of Innovation. They're a way of operationalizing innovation, repeating ways of experimenting and validating and getting information and eliciting input from all people that have something to contribute. And again, you need operations to support that. So you need a head of innovation or innovation ops to support that infrastructure, to support those processes, to hire the right people and have... have a flow which enables ideas to come in at one end and then hard products and services to come out the other end, which deliver outcomes, which people want to buy into from a value point of view. Yeah. I'm focused on innovation ops at the moment. Every design lead or founder or CEO who listened until now and doesn't want to hire a design ops, honestly, I don't know who can help them. But talking about that, my very last question also to come now to the highlight of this conversation, eventually, how do company hire for an ops position? Okay. So I think if it's a research ops, let's say it's the head of research ops. I think you're looking to hire somebody who has built teams, has built capabilities, is able to productize practices in a way that supports fluid and flexible ways of working. I think they've got to understand the notion of what user research is, contextual research, ethnographic research, all those sorts of things. And I think they've got to be capable of working in organizations where there is often resistance. So they've got to have a firm set of legs and be able to push back where it's appropriate. Same thing for design. You need people who've got the experience set, have got a good understanding of how to use these methods and approaches to deliver consistency and enable people to get out and do their work. And I think underpinning that I keep coming back to is that's about people who've got some breadth of experience. It's about coming back to people who understand these approaches. I think it's about coming back to people who've got a good trade craft, good stage craft and good state craft. And the other thing is, I guess it's also about fit. I had an interesting conversation with someone today about, you see an awful lot of kind of nepotism, people hiring folks who've been to the same school that they've been. They've been to, I don't know, Carnegie or they've been to Pratt Institute or whatever. And you substitute that name for anything. I think what you've got to do is you've got to hire people who stretch you and you've got to hire people willing to deal with the difficult challenges. And I think that fundamentally is about having an honesty about where the organization is and where your team and their skill sets are. So I think underpinning all this is people with experience, but have the honesty to recognize that you need to hire a different type of person, like an ops, a head of ops or a head of research ops in order that you can move on from where you are now. And I would say is that if you're failing to embed design in your organization and you're failing to scale, then you need somebody who's got an ops background or has got a good, strong design management background who is au fait and familiar with the ops approaches. So just like thinking also because design ops is not entirely new, but still fairly new, I think it's definitely one of the roles where the market is not as full with design ops people compared to, for example, product designers. And I would think of, especially in smaller cities or areas, it might be harder to find someone who already brings a lot of experience in this area. So what would be a good alternative to fill this gap? One of the areas that I've helped clients is actually coming in as an ops expert and coaching and helping a team or a particular individual to transition into those roles. That's a good way to do it, is you buy in that experience and you buy in that consultancy expertise. And I also think that here that smart people, self-learners, they're what I call auto diktats, they're able to learn. And I think when you go out into the community, whether it be the research ops community, design ops community, or the innovation ops community, whatever, there's a very strong connection between some of these people leading these groups, these communities. And those are a good place to start, is start with the communities, connect with these people, come to the conferences like the design ops global conference, the design ops summit, go to the meetups, the design ops meetup, whether in Australia or in Scandinavia, get involved. And there's some good books emerging now. Some of the companies like Envision are publishing some good books being printed increasingly around these subject areas. And I think at the end of the day, I think if you bring in some energy and passion, we can all learn about these approaches. I think it's recognizing whether you need them. Yeah. And I would say this is not all companies are ripe for it or ready for it or need it. I saw that recently at an engagement where there was a large bang. And really they didn't have the maturity to have that kind of role. I didn't have the need for it because they're still trying to grapple with basics, like getting design thinking in the organization as an approach and a way of thinking. So I think, you know, part of it is that you've got to look at that. Part of it is the business looking to implement and embed things like design thinking and agile throughout the whole organization. Then I would say you're ready for ops. And I would say that maybe what you do is take some of your senior people, maybe a design director or head of design or head of research, and they take on that role. And then maybe you split that role off with somebody who comes in and you hire to it. I think the important thing is at least you make a start. I think it's about an approach and I think that's important. You can call yourself anything you like. It doesn't mean anything. I think it's more about whether you need to have that scale and you have the complexity where you need operations in place. Yeah. I think understanding where you are and where you stand at the moment is the most important steps to be able to make the right decision. Yeah. I just noticed recently, for example, we talked about the British government, gov.uk, you know, they spent, I'd say the last five years getting design thinking and service design and UX and UI and content designers into their teams. And now I think that I'm beginning to see them hiring ops people. And I've had conversations with some folks there about how do they do that, just like we're doing now. So it's interesting to see how a large scale organization like that has gone through this five year maturation cycle of bringing in design and recognizing that user-centered design is part of that now their DNA to now to operationalize so they can get it distributed throughout all the different teams and the different types of roles that they have in order that they can really amplify the value of design. I was working with the gov.uk because we were doing integration. And when I was checking out the API documentation, it was first of all amazing and also on every page they had like forms where you can give feedback on the usability and how much you liked it. So a very agile way, very design thinking way they are approaching good stuff. I think there are very few governments who actually have such an advanced approach. Absolutely. Yeah, I think the role model. Yeah, I think, I think when you think about where they were six, seven years ago, I would say now they exemplify how you can undergo a significant major digital transformation process in government and deliver real significant gains and you only need to see that now with the latest kind of journeys and forms that they're releasing. They would say they've got a long way to go. And, but it really is a great example of how design can impact and how at the same time that they've adopted agile as well. So they've had so many moving parts and I think it's a real testament to the different folks who have been in there. And it is, that's the important thing is it's a community effort and they have some really good communities there and they're very open and honest and they love to learn, so that's really nice. Yeah. Great. Pete, it was a great chat with you. Thank you very much for all the insights. As far as I remember from our very first conversation, there is one more special you'd like to share. Yeah, we've got a couple of free passes for your audience. Obviously you guys, you're going to get a complimentary pass to come and join, but we've got two passes that you can distribute those any way you like. You can run a competition, you can do a first come first serve basis, but we've got two passes that we can provide, which are worth nearly a thousand pounds each. It gives you full access to the four days, the conference and the workshops. We'll have 30 speakers, six keynotes. We'll have lots of workshops and it's all going to be online so you can keep safe. We pivoted last year. You can see some of our sponsors there. We've got Mural and Figma and Foolproof, in fact, which is an agency and the Academy, which is my Academy, we're supporting the workshops and Mailchimp have been great over the last couple of years with supporting us too. Do, you know, if your folks are interested in the conference, we'll get some information out to you guys. And we've got two free passes for you. Amazing. And I think Alex and I, we will share the passes on social media and people who will reshare will get the chance to win those. If you, if they will then exchange their information, we'll make sure that they get their passes and so forth. So that'd be really cool. Yeah, absolutely. We'll give them a link. They can sign in and do the link once you give us their names. But yeah, it's, thank you so much for letting me rabbit on and talk. And I hope there wasn't too much repetition in what I said there. And I hope I answered your questions fully. It's great that you guys are doing this podcast and trying to deal with these very important issues that are coming out in our professions and thank you so much. I appreciate it. Thank you, Peter. I think it was very insightful. So thanks. for taking the time and joining us, even though it's already like evening hours. Highly appreciate it. Yeah. No, I love it. I've got my curry waiting for me. Yeah. Thanks. Thanks guys. Thank you very much. Awesome. Hope everybody keeps safe and come and join the conference. It's going to be great. Yes. Amazing. Do that. And thank you very much again. Have a great night. Bye bye. Thank you. Cheerio. Bye. Welcome back to the debrief Christian today, a slightly longer episode, but I think totally worth to, to like really deep dive a little bit, like on the topic of design ops, research ops, absolutely. Innovation ops. I think I learned a lot of things. So maybe back to you, what are your takeaways from today's session? First of all, let's get one thing straight. Pete has said already so much around the whole topic, but what was really helping me today to better understand is this whole management perspective, looking at design and my opinion on design ops or in ops in general was always fixing symptoms and not problems. But now I better understand where he's coming from and that it's actually like a mitosis or in natural involvement of this whole area of design. And that was something that was definitely very enlightening. And also the very best thing came to the end. And many people asked us also how to hire for the right mindset and how to hire ops people. So I think Pete really nailed that down today. How about you? On the same note, if we speak about ops, do you think that product will undergo a similar development and do you think that we will soon see product ops roles or is this something that is already covered by something like, let's say a scrum master who already is focused more on processes, even though not as much as you would see it in design research and development roles? Yeah, so a scrum master focuses more on the engineering processes than the product processes. But yeah, I'm very honest with you. I'm consulting right now a company that is actually working with product ops. So yeah, there is definitely this involvement and as Pete said, depending on the company majority and also the growth, at some point you really need that support to be able to better scale. What's your main key takeaway, Alex? I find that I had quite some conversations in the past around design ops. One thing that I heard from different people was actually this idea around, okay, design ops people are so focused on processes, so they don't need to be good designers or didn't even have to be designers at all. The idea that they are just good in terms of people skills. And I think this is something that Peter brought a little bit to the point, right? You need to have the understanding, you need to know design, you need to have experience and also experience working in different organizations and companies and so on before you can even think of moving into design ops, design management and so on. So that was definitely something that was good to hear from someone who's that deep into the topic as Peter is. And that's also one of my biggest takeaways for today. Yeah, absolutely. And I think the worst thing you can do is to start hiring for such a position when you don't know what you want to achieve with it, because then you definitely focus on symptoms and the real problem. Yeah. Or even when you're not mature enough as a company, obviously there's no reason to have design ops if you don't do proper human-centered design thinking or have HR processes in place. Boom. All the buzzwords in one sentence. All right, Alex, I think there's so much that has been said. Just to get back to the little lottery that we want to do is two cards for the conference. So keep your eyes peeled. We will soon announce and launch a small campaign on social media. Yes. All right. Thank you. Thank you. Thank you.