What is Design Operations? With Philip Rowe

Brett Harned:       Hey and welcome to Time Limit. Today's episode is all about an emerging topic that sits in this kind of professional cross section of design, project management, and product management. It's called design operations and I enlisted my friend, Philip Rowe, who's a user experience program manager at Google and just so happens to be working in design operations himself. Philip's got experience in design and project management so he can see the role from all sides. I'm excited to introduce this topic to you if it is new for you.

Brett Harned:       If it's not new and you don't know Philip, I know you will enjoy the interview and gain not only an understanding of what design operations is, but some tips to keep your projects moving.

Brett Harned:       Before we jump into the conversation, I have to apologize. I'm a rookie podcaster and somehow I recorded this interview through my laptop microphone and not my external mic, so the audio is not perfect. So I apologize to you and to Philip, but I promise it could be worse. I think you'll still get a lot out of it. Sorry. Let's check it out.

Brett Harned:       Philip, thank you so much for joining me on Time Limit today. How are you doing?

Philip Rowe:        I'm doing good. How you doing, Brett?

Brett Harned:       I'm doing great. I'm really excited to talk about design ops or design operations I should say, to make it sound more formal. But I think this is a topic that's been emerging for some time in the digital space, which is where we both come from, right? We've got listeners from all corners of industry. But I think it's a topic that feels to me at least, that it's rooted in project management in some ways, and I could totally be wrong on that. But I know that you're in a design rops... Design rops, design ops role at Google, right?

Philip Rowe:        Yes.

Brett Harned:       And you've previously managed projects and you've presented on the topic of design ops, which is pretty much what's led to this discussion. So maybe if we can just take it from the top, if you can explain to the audience, what is design operations?

Philip Rowe:        Sure, I can take a swing at that. For me, what I love about design ops and what's interesting to me is it's this blend of disciplines. Right. It's this tactical, strategic design thinking, it's project management, but it's really this lens on combining business, and design thinking to one role. So the focus is you can think of as program management or project management, but really for design teams and in the design disciplines as it were, very much like operations of design and creative teams. It's the way I like to think about it.

Brett Harned:       That makes sense. So you're in product organization at Google. Does design ops really only work in that type of organization or have you seen it played out in other types of environments?

Philip Rowe:        I've seen it mainly in product organizations, at least definitely here at Google. Maybe because I'm a little biased, I think it can play out in a lot of different scenarios, definitely enterprise operations that use UX. Anywhere there's creative happening I think is a place that design ops can play. Definitely the product organization and product companies like Google are very much using design ops to help our product teams develop great products. But I can see where design ops could flow into other areas too though.

Brett Harned:       Okay. So you... And I just want to be really clear for our listeners, so you mentioned product organizations and design in UX. So UX is user experience design...

Philip Rowe:        Yes.

Brett Harned:       ... which is how people are designing flows and information. So UX, generally when I think of UX I think of digital products, but I guess user experience can really be in any industry, but do you think design ops is more prevalent in digital at this point?

Philip Rowe:        I think so. It's definitely what I've seen. We're a digital company, we're very much a design ops as well here. And when I talk to colleagues in other organizations and other companies, those are pretty much all digital organizations. And I think digital is where this has seen the need for this because of the complexity of products and integration pieces and the digital, we have these design teams that are growing because of the complexity. So this has brought up the need for design ops too, so yeah, pretty much mostly in digital organizations is where, I think, design ops is the most prevalent.

Brett Harned:       Okay, that makes sense. So let's take a look at how the design ops role takes shape for you at Google. You mentioned helping product teams and design thinking. But can you dig into more specifics? What are the things that you're doing on a day-to-day basis?

Philip Rowe:        Yeah. That's a great question because for me, one of the things I love about this role and the way we look at what we do is that every day is really different. But what is a theme for when I think about my day... It's hard to think about what I do on a day-to-day basis, but the thing that really is a theme is really setting clear priorities for the designers and the different [inaudible] on the teams. Making sure people are clear on what they need to do on a day-to-day basis.

Philip Rowe:        And just really shepherd, I made this reference this morning, someone said, well you're kind of like, I can't remember the word they use, but you're kind of like a shepherd. Right? And that's really the key there. Really trying to make sure that our teams are able to get done what they need to get done on a day-to-day basis. And then on the flip side of that, making sure our leadership team is aware of what people are working on and the priorities that leadership has set matches what people are actually working on. So that's a big part of my day-to-day role.

Brett Harned:       Okay, cool. So it sounds like, yeah, you're a shepherd. I feel like people would say that about project managers, right?

Philip Rowe:        Yes.

Brett Harned:       You're a leader, you're cat herder or whatever the word might be, right?

Philip Rowe:        Sure.

Brett Harned:       How is design ops then different from project or program management? Is it because you're solely focused on product design and managing a design thinking exercise or process?

Philip Rowe:        I think that's most of it because my role is kind of a UX or design program manager. So I'm program manager on the design team, and we have here at Google program managers that are technical. So there's your focus is maybe a different discipline, but you're still doing program management type of work.

Philip Rowe:        I think what's different for people like myself who are UX or design program managers is that you really are not only working with design teams, but you have an understanding of the design process. You have an understanding of the different roles across design. So my lens is really about user experience and design and all the work and disciplines and processes and tools that go along with that and really knowing what a team like that needs versus a team that's an engineering team or a product team. So really focused on the design discipline and what's needed for that in a program management kind of sense.

Brett Harned:       Got it. Okay. So yeah, it's program management. It's specifically around user experience design. How did you develop an expertise in UX design?

Philip Rowe:        Well, I started having an interest in design and UX several years ago. I had for a while there I had my own little single personal consultancy business and I did everything from tech work to website design. So I really got interested in design and UX and took a couple classes in that. Then as I got into the agency world, I started really gravitating to projects that were really UX focused, a lot of website redesign, a lot of app redesign. I ended up specializing and project producing, more on the design UX side, and that's led me to a role previous to Google at Nike doing UX producing. And then that led into the role here at Google as a UX program manager.

Brett Harned:       Got it. Okay. So I have to think that you've got to have some kind of expertise and background or at least deep knowledge about design, more specifically UX design to have a role in design operations. I can't imagine that somebody would step into a role in design ops without having a deep understanding of how design works.

Philip Rowe:        I think for me that's the way it worked. I do know people who have come into the role who have maybe not had a really deep experience in UX but they had really deep interest in product or UX or design. So it just depends on the level. For me that was a requirement for me to get into this role, but I think you can transition into it, even if you don't have a deep understanding of design, you just have an interest of it. And I think having the program management skills and producing and project manager skills is probably, I'll say a little bit more important than the UX design skills, but I think anyone can who has interest and wants to... You have to want to have comfort with working with creative teams, being comfortable with ambiguity, and being comfortable with the different ways design teams work in order to work, I think, in design ops.

Brett Harned:       Okay. Yeah, I think that absolutely makes sense. It's almost like you read my mind because I wanted to ask you what are the skills that you need for a design ops role, but it sounds like it's more on the project management and organizational side of things and less so on design itself.

Philip Rowe:        Yes. I think that that makes perfect sense. I think it's a way to putting it. It's really about being able to, the organizational and the way that a different type of team culture and team work happens in design that really is the differentiator between program management and design program management.

Brett Harned:       I'm really interested in this idea of design program management versus development or engineering program management. It's like splitting two disciplines that are obviously tightly connected when you're producing a product. Can you talk a little bit about process and how you make the connections between the design and development programs?

Philip Rowe:        Sure. I can speak to that. I mean, we here we have program management like myself or a UX program managers, but we also have a technical program managers which work, as you said, on the development side. We work very closely and hand-in-hand as you would on a product side as you would imagine, particularly in our role as we're doing product development. There's definitely product release or launch schedule. So we have to work very closely with our engineering counterparts to make sure the UX is aligning and coming together in time for engineering to work and looking at the product vision. So it's this kind of, it's very much a collaborative effort. We meet regularly with that, with my counterparts on engineering. I'm in the meetings, UX and engineering and product are in the same meetings, collaborating on priorities and seeing where things are. This kind of collaborative work that goes on.

Philip Rowe:        And on process-wise if we're thinking about it, we're using processes that are tailored to whatever project we're working on. For product releases, pretty much a release schedule, very much waterfall ish, if you want to think of it that way, but some hybrid components of agile in there as well. Process wise, we pretty much are following, I'm kind of looking out to my engineering colleagues about what the release process and then figuring out how best to integrate that design process into that release process...

Brett Harned:       Got it.

Philip Rowe:        ... engineering.

Brett Harned:       Okay. So, your counterparts in engineering are essentially coming up with estimates and probably working in some level of like a hybrid or agile method.

Philip Rowe:        Yes.

Brett Harned:       But they're still having to meet specific launch dates.

Philip Rowe:        Exactly.

Brett Harned:       So they're kind of dictating then what your design schedule or how much time your team will have to produce design for those products.

Philip Rowe:        That's true. And then we also have this, when we're exploring [inaudible] new ideas or new designs. There's a process that design team is using to explore and iterate and converge on a solution. Then working with engineers in that process to make sure that what we're designing, can be built and doing those trade offs too in real time. So that part of probably more of an agile kind of like iterative process, but there's kind of this hybrid of approaches depending on the product, the feature that's going into the product as well.

Brett Harned:       Got it. So how does design thinking work into that process?

Philip Rowe:        Well design thinking works towards the beginning of that process, kind of exploration, and when we're thinking about, hey this is a great idea, we have this direction we want to pursue. So the design thinking part of that plays into the beginning of that phase when we're thinking about let's go out and think about the divert and think about all the ideas we have and what's possible. And then as we're doing that, we use these things called a process called design sprints. Very famous. The teams use quite a few.

Philip Rowe:        So we do this divergent thinking on teams and we do this also with product and engineering as well. So it's a cross functional process and then converging back on thinking, pulling away those solutions that aren't working and actually coming back to a solution that does work and using user research to help us define what are the great solutions that come out of that process that the team can actually build at the end of that process.

Philip Rowe:        So it's this kind of divergent convergent process for design thinking, design sprints, we use that for that. And that gives us, gets to a point where we can actually say, this is build-able and it can be done this time frame, and it's a product that actually can be launched.

Brett Harned:       Interesting. Thank you for the kind of behind the scenes view into how you're doing things at Google. I think a lot of people find that really interesting. It's like how do you create these massive products that so many people are using? It's like you're doing it the same way, so many other people that are and your public experiencing a lot of the same challenges that those people are experiencing as well.

Philip Rowe:        Definitely, yes. And it's, for me, just being able to be a part of it is super inspiring and fascinating and [inaudible] boring too, so it's great to see the creativity that our teams are able to come up with and what the smart people here can build too.

Brett Harned:       Yeah. So I want to talk about the teams a little bit. I know that there's this concept in product organizations that I think you might've brought up in your presentation about the three legged stool metaphor. Can you talk a little bit, explain that concept to us, and talk a little bit about how it applies to your role or even to your process in the organization.

Philip Rowe:        Sure. Yeah. The three legged stool, there's many names for it, there's a three legged triangle. This is basically a three sided product team organization. So there's the three parts of that are in product, engineering, and then design or UX. So those three components of the stool working together to develop products.

Philip Rowe:        The idea is that no one of these teams could work without the other. Right. And you have the three legged stool, because there's this balance that needs to happen for product, engineering, and UX in order to deliver something that is a great product. Right? A product excellence kind of product. The idea there is that we all have to collaborate together. That's why I mentioned in design sprints, you really want to have a cross functional team for that, because having just designers or product or engineering in the room really doesn't speak to all the disciplines and people who actually need to build those products. So it's this collaboration across those three disciplines that is a part of that three legged stool concept.

Brett Harned:       Got it. So what are the kind of roles within those teams, the people that you're working with or even kind of managing through the process?

Philip Rowe:        Oh wow. There's quite a few of those.

Brett Harned:       Yeah, I'm sure.

Philip Rowe:        On the product side, of course, we have a set of product managers, engineering, we call them [swes] here, they're software engineers. And on the UX side, I deal with a wide variety of UX disciplines on our own teams, from designers to researchers to UX engineers. So our teams have these various disciplines that are all about figuring out what's the best user experience, as you would imagine. Also figuring out how do we determine and measure that so that we are ensuring we're delivering a great user experience. Then working with our product managers, engineering, swe teams, in order to deliver those and launch those features and those products.

Brett Harned:       Cool. I have a question about just the life cycle of projects. So let's say, imagine that you have some sort of a roadmap that you're working toward with delivery dates. And we all know that every product that's digital is always ripe for change. After a product is released, are you then managing that project and working with the team of researchers to kind of research how the product's being used and defining ways to make that product better? Or does that get handed off to another team?

Philip Rowe:        That actually stays within the team. Once a project, a product or a feature or say a product is released into the wild, the teams get feedback for surveys and reviews and all of that so that feedback that we get, product engineering and UX teams are looking at that and determining, this is the product that's delivering or not delivering as we want. Then how do we improve that, how do we solve those problems or fixed that. And UX research is definitely looking at how best to capture that information and then designers will look at, well maybe look at changes we need to make, or updates that need to be made for that.

Philip Rowe:        I mean I think all three teams are still involved once the product is released, always looking at how to make the product better. So all three of the three legged stool teams are looking at ways once products are released, improving those, and making them better over the longterm.

Brett Harned:       Yeah, that's really cool. So there's real ownership within your team and real accountability to make that product better at all times?

Philip Rowe:        Yeah. At all times. I mean after this call I'm going to go through and make a list of things our directors of UX want to look at for our next release. So there's very much top of mind and real time for the teams here.

Brett Harned:       Okay. So what kind of tools or process points or touchpoints are you using to help keep yourself on track with all of those things? Because those are pretty big teams that you're managing, really big projects and initiatives and that's the details of that have to pile up. So what are the things that you're using to keep yourself on top of everything?

Philip Rowe:        Actually, we have several tools here internal to Google that software development uses, but I also use for our UX teams to manage it. But frankly a lot of the work I do, I use a combination of, I hate to say Google sheets and it's almost like spreadsheets to keep track of things on the list, and then integrating those tools with our developer tools in order to see that all my bugs and features that are listed that we're on top of. Then from that this is [inaudible 00:00:20:02] our new team, over the course of the next six months, I'm actually going to be building a dashboard for our directors that pulls information from various sources and get some help with that.

Philip Rowe:        So for me personally organizing the information really at this point is pulling from different sources and using just good old fashion lists and a spreadsheet in order to-

Brett Harned:       Spreadsheets, yep.

Philip Rowe:        ... keep track of them. I could tell you, that I get little fancy but I find that keeping it as mostly simple, keep it as low effort as possible, something that I can update quickly and be able to really interact with on a daily basis is really for me is one of the keys.

Brett Harned:       Yeah, absolutely. The easier you can keep that kind of administrative stuff and the more clear you can keep it, the better, so then you get to focus on the people. Right?

Philip Rowe:        Yeah, exactly right.

Brett Harned:       I think, on that kind of note, I'm curious about how you create a solid team culture or keep momentum going, especially when you're working with large teams and you're managing programs here too, right? It's not like you're just managing one project. Do you have any tips for developing team culture, or getting to know your teammates or coworkers, that kind of stuff?

Philip Rowe:        Sure. I can offer some tips of, I recently back in the fall changed teams here at Google, and one thing that I always, always do I think is just, I mean it may sound simple, but you really want to be able to show people the basics, respect, I thank people, show gratitude and kudos whenever I can. Also I think, celebration is a thing that should be used for celebrating quick wins or even big wins, but find a way to celebrate milestones of what you achieved is very important.

Philip Rowe:        I think having a team culture where people feel ownership and accountable for the work they do and really engaged in the work. And just for now I was trying to think of ways how do I make my programs and what I'm doing, make sure they're being inclusive and engaging the teams to do the work they want to do. And I think one of my roles as a program manager is to make sure that creative people and the designers and the researchers and everyone on the team can focus on the work that they need to focus on. And I take on the operational pieces and making sure that they're spending the most time on what has the most value too.

Philip Rowe:        So I think those are some of the things that I would offer as advice for getting a good team culture.

Brett Harned:       Yeah, I think that's great. I think if I kind of take that a step further, if you don't mind, since you're in design operations, you're specifically dealing with or, dealing with sounds terrible, you're working with highly creative people who are under pressure to develop and design concepts for a huge brand name. And I have to think that that brings a level of stress to those people, but then I'm sure that trickles down to you. I wonder if there's anything you do that is specifically focused around the creative atmosphere to kind of keep people feeling good about the work. And that what they're producing is positive even if ideas don't get accepted right away.

Philip Rowe:        Yeah. I think for me what I really try to do is... I mean one of the things I'm really focused on now just in my role is our reviews, where we have designers and teams come in to talk to leadership and present their designs. Right. And as you would imagine that could be a very stressful environment to come in, here's your work and room full of people looking at so. So as I facilitate those sessions, one of the things I think about is how do I make this a situation so that our design teams and people presenting have the most information about how to be successful in those situations. I almost think it's kind of a coach, mentor kind of situation where I'm really trying to think about how can I make my, not make, how can I assist my teams in being as successful as possible.

Philip Rowe:        I think that preparation and being assistive and kind of reducing the unknowns for teams and knowing what they have to do, I think that can help reduce people's stress level too. They know what they need to do and when and why, and then that information in that context really I think helps team members be really engaged, and stress out less about the things that they may stress out in a review or talking to our product manager or whatever. So thinking about ways to help them in that sense, if that makes sense.

Brett Harned:       Yeah, that absolutely makes sense. It's an empathetic approach, right? It's knowing the pressure that they're under, knowing how specifically you as a program manager or project manager can help them in the day-to-day and how you can help to frame conversations, meetings, outcomes, whatever it might be in a way that helps them to dig in and act with a little less complication, I guess. Right.

Philip Rowe:        Perfect way of summarizing that, yes.

Brett Harned:       Cool. Okay. I love this. I personally love, you know my background's been in creative working on the web, so obviously working with tech as well, but I've always had more of an interest in design and UX. I think that's probably why I wanted to have this conversation. And this has all been really interesting.

Brett Harned:       I do have one last question for you.

Philip Rowe:        Sure.

Brett Harned:       And it's really kind of in line with the theme of the podcast, Time Limit, kind of nodding to the fact that we're all working under constraints in some ways. And I'm wondering if there are any things that you do in your role that help you to keep all of those things together. We talked about spreadsheets and things like that. I'm thinking deeper than spreadsheets, right? All of the people, and the process, and all of the moving parts, on top of that, I'm sure that you get things like new requests and ideas or directives and how do you sort through what's a priority and what's important and still needs to be addressed.

Philip Rowe:        Got you.

Brett Harned:       Do you have any tips in that line of thinking?

Philip Rowe:        Yeah, I do. This is great you asked this, because it's very top of mind for me as we start a new year and I'm coming back from break. One of my goals was to put together for the first quarter, what does Philip delivering for the team, right? So [inaudible] what we call a OKRs, so I spent a lot of time on the break thinking about what those would be. I presented those to our directors on Monday, say here's a list of things that I'm going to be doing and here's the priorities based on observation and interviews and one-on-ones with all of you. So here, for the first quarter, here's the things, Philip's going to be working on, but then here's the things Philip is not going to be focusing on because Philip doesn't have time, quite frankly, right.

Philip Rowe:        So looking at really having alignment on what are my priorities and what's important and then versus what's not, and have a conversation about that. Then have an agreement about what that should be for my work. So then that really helps me as far as on a day-to-day basis when I get requests for things and I can kind of give it a, I can look at it and say, hey, this is on my list of priorities or it's not. So then am I able to be able to accommodate that or not, is it really important, and usually the answer is no. Then I'll have to delegate or figure out what the best to do about that.

Philip Rowe:        So I think for me it's really about setting expectations and alignment and a lot of thought into what's important. And how I can deliver as a program manager the most value and impact of the team and really being, I won't say strategic about that and very clear about what that is and what that is not, and enabled on a day-to-day basis, resisting the temptation to jump in for things that are not going to provide a lot of value. Right?

Brett Harned:       Yeah, I like that. I think so for anybody who's listening and doesn't know what an OKR is, it's basically objectives and key results. Right?

Philip Rowe:        Yes, that's right.

Brett Harned:       It's a Google coined term, I believe, isn't it?

Philip Rowe:        It is a Googled coined term that's used I think quite a few other places, but yes, Google coined term.

Brett Harned:       Absolutely. Yeah, we use it at TeamGantt. I think I use it the same way that you do and the team that I work with does as well. So essentially we're setting up some objectives with key results and determining where our focus will be, for us it's for a quarter and we work on projects that directly will impact those OKRs, and that's how we're measuring our success on some level.

Brett Harned:       And I like that, and I like the way that you framed it because if you're doing a good job and sticking to those, OKRs, you're actually focusing on what goals are. When I talk to people in presentations here at TeamGantt or the classes that I'm doing, we talk about project goals, right, and making decisions on projects that are determined by what your project goals are. So if a new request comes up and it doesn't meet one of those goals, then that request gets put in a parking lot or shelved until the next quarter.

Brett Harned:       So I think that's a really good tip. That's a good way of thinking about it. And it's also, I mean, I would say that it's not too difficult to come up with those OKRs. What's your take on that process? Yeah, it's simple.

Philip Rowe:        I think it's pretty easy... I'll say, having done it already, it's been pretty easy to do. I think for me, one of my challenges in my personal development is that my list was kind of long. My manager said, you know, Philip, I know you want to do all this, but thinking about what's realistic to do, right is as also I think an important part of this. So what's realistic to do. Then also thinking about, what's your own career goals on. What are you interested in too. If you can actually combine that so that you have OKRs that meet the needs of your team but also you are passionate about, then that's, you have the best of both worlds there.

Brett Harned:       Yeah. Wow that's a great manager to tell you this is too much. I've been in that same situation and I'm thankful for that because I think as PMs we kind of always want to take on more don't we?

Philip Rowe:        Yeah, we want to solve all of it, right.

Brett Harned:       Exactly.

Philip Rowe:        Not just part of it.

Brett Harned:       So that's really good advice. I think OKRs are a great thing for people to look into and we can provide a link to some background on OKRs in our show notes, along with any other things you think might be helpful for our listeners, Philip. But that's all I have for today. Thank you so much for joining me. Thanks for educating us on design ops and maybe we can throw out some book recommendations or links online that we can share with some folks if they want to do a little bit more reading. But I think this has been a great primer, and really interesting for me to see the direct parallels between design operations and really project management, which I thought was there, but I wasn't totally sure.

Philip Rowe:        Yes, there definitely is a parallel to that. Sure.

Brett Harned:       Awesome. All right, well thanks so much for joining us, I hope we get to talk to you again soon.

Philip Rowe:        All right, thanks, Brett.

Brett Harned:       All right folks, that's where we end it.

Brett Harned:       If you're interested in learning more about how Google design works or want to check out some of the resources Philip mentioned in the episode, check out our show notes. It's all great stuff. And I'm going to ask you one favor, please share and rate our show wherever you listen to your podcasts. Honestly, reviews help us to get the show seen and heard and that helps to attract better guests. Well, not better, but more guests. Trust me, it would help us greatly or I wouldn't even ask. And that's really all we have for this episode. Come back for episode 28 which is all about accountability.