What are the pros (and cons) of ResearchOps reporting into research versus other ops, like ProductOps or DesignOps?
This is It's a Great ResearchOps Question, a 6-part podcast series produced by the Cha Cha Club, a member's club for ResearchOps professionals. In each episode, a panel of club members will tackle a great question about ResearchOps, like what does AI mean for research, or how do you build a compelling business case for research ops? This series is sponsored by Great Question, the all-in-one UX research platform. And I'm your host, Kate Towsey. I'm the founder of the Cha Cha Club and the author of Research That Scales: The Research Operations Handbook.
Kate Towsey:This is episode 5. In the studio, we have Steph.
Stephanie Marsh:Hi. I'm Steph Roche. I am the research operations lead at Springer Science Publisher.
Kate Towsey:And Shane.
Shane Olbourne:Hi. I'm Shane Olbourne, and I am the senior research operations program manager at MongoDB.
Kate Towsey:And last but not least, Ed.
Ed Lyon:Hey. I'm Ed Lyon, and I lead the research operations team at Wise.
Kate Towsey:All guests views are their own and not that of their employer. Okay. So this is episode 5, the penultimate episode of it's a great research ops question. And our question today is what are the pros and cons of research ops reporting into research versus other operations functions like product or design operations? So let's start with what your team structures look like.
Kate Towsey:You know, I'm really wanting to dig into who do you report to and what aspects of ops are you focusing on? Who wants to kick us off? Any volunteers?
Shane Olbourne:I can go ahead.
Kate Towsey:Shane, you jump in.
Shane Olbourne:So our team is structured under a PGM org. We are part of a creative ops organization, and we dotted line to research. So we are, partnered with research from the research, leaders, and we have a research leaders in operations weekly. It's kinda strategic that way. So the way that it was grown, and the way that it is now, it keeps that same tradition going.
Shane Olbourne:Within our team of our creative ops people is we have design program managers. We have, core program managers that work within the, the the the core team per se, then we have one that supports design systems, and we also have, the 3 of us that do research operations. A leader recently went from being the lead of research operations to being the lead of product UX operations. So that's that's how that it's a new newly formed team for about 6 months old.
Kate Towsey:So if I heard right, you've got creative ops in there. Is that correct? That's a new term that sounds very cool. And you've got UX Operations? Yes.
Kate Towsey:Is that correct?
Shane Olbourne:Yes. So product UX operations, which engulfs design design systems and then program managers who support program management in general too.
Kate Towsey:And then what does the creative ops look after? Is that does that sit within UX ops?
Shane Olbourne:So u a yeah. So the product UX ops sits within creative ops. Creative ops is the larger org that we're under.
Kate Towsey:Okay. I got it. And then that is a dotted line to research?
Shane Olbourne:Yes.
Kate Towsey:Brilliant. Okay. We've got that. Okay. Cool.
Stephanie Marsh:I think we
Ed Lyon:want some maps or something.
Stephanie Marsh:Because we're
Ed Lyon:I'm about to do some of the same words, but it's gonna be in entirely the different opposite direction.
Kate Towsey:Oh, that's interesting. Well, well, test us, Ed. You can
Stephanie Marsh:go ahead.
Ed Lyon:So we we also have creative ops, but it's like a like a peer sort of organization to us, and they're like an internal agency mostly working with marketing product, marketing, that sort of thing. But they're they're very separate rather than being, like, the the umbrella to us. So I lead a team of 3, and we're dedicated on research ops. We split our time about, like, 70, 30 between the smaller part. It's central centralized things, like how do we design our recruitment flow, tooling, all those sorts of things.
Ed Lyon:But more and more, the majority of our time we spend in product teams and squads that we call them, like, the collection of product teams where we deliver, like, more complex operational work. So when people need to work in, like, 5 countries at once or anything like that, that's when we would step in and, like, make it a much more efficient, like, program or project. So we there's 3 of us. Previously, we reported into research, but now that's, like, we view them as, like, our partners, and we sit within, like, the larger what we call design ops group. So that is every point of 5 people to focus on design operations, and that's all within design.
Ed Lyon:So we're like a big cuddly group of designers, researchers, content folks, and operations as one big org together. But, yeah, then creative ops is in marketing, so just to mess with the Shane's words and my words being the same but different. So that's how we are loosely.
Kate Towsey:And before we get to you, Steph, Ed, when did that shift from you you mentioned that you used to report into research, and now you report your partner next to research. What precipitated that shift to happen?
Ed Lyon:Yeah. Initially, it was, so I joined as the first research ops person, and that was into a small research team. I've got, you know, 3 researchers at the time knowing they were gonna grow, so that's why they brought in an ops person. And when that director left, or would that be going on 2 years ago now, it was just a situation where they recruitment was gonna take a while for, like, such a senior position. So their options were, like, do you go into, like, a design director or the ops?
Ed Lyon:And it was a very, like, mutual decision at the moment. Like, let's give it a go. Like, what could change? How what could the benefits be? And it's gone, we think, pretty well.
Ed Lyon:So we decided to stick with it.
Kate Towsey:We're gonna get back to that question of what are the benefits next. So, you know, you'll you'll be able to share those in a moment. But before that, Steph, do you wanna share, your your structure with us?
Stephanie Marsh:Yeah. I just it's already been interesting because I haven't heard of Creative Ops until today, so that's very interesting. I
Kate Towsey:haven't either. Yeah. Yeah. That's fresh.
Stephanie Marsh:And one of the things I wanted to talk about was potentially where the ops starts and then where it moves as it matures. So, yeah, definitely like to get back to that. But, for my team, so, I report into the head of user research, and we sit within the UX team, which is in the technology department. I like to think of it as nested Russian dolls type of thing. So we are a, a team of 3 people.
Stephanie Marsh:There are 10 researchers, but there's also designers doing research. And there's about 35 of them. The interesting thing about Springer Nature is that technology and product are separate departments that work together in product teams. So it's quite an interesting dynamic. Yeah.
Stephanie Marsh:So designers tend to be embedded within teams, working directly with the product t people and, like, the devs, the BAs, etcetera. And then we have researchers that are sort of embedded in programs or across programs, but we don't have enough to be actually embedded in Teams. So there's lots of and then research ops sits across all of it. There is a design system team that reports into the UX, VP. There's also one design operations person, but that's quite new.
Stephanie Marsh:But yeah. So re ops has been going longer than design ops being a thing within the organization, which is a bit unusual. I think, usually, design ops comes first.
Kate Towsey:A couple of interesting things that I I hear here. 1st step, as you say, research operations leading the way for design operations in the organization. And then, Ed, you also mentioned that, there were 3 researchers. And so the leader decided at that point it was pertinent to bring in operations. Well, hurrah.
Shane Olbourne:It can happen. It
Ed Lyon:can happen.
Kate Towsey:Yeah. Not waiting until 40 researchers that they're trying to like, they're climbing over each other to try and get things done. So that that really stuck out. I thought, wow, like, that's kudos for that.
Ed Lyon:Mhmm.
Kate Towsey:So, Ed, you were talking about the structuring and that you had once been you were once reporting into research. And then in recent times, you everybody decided on an experiment to move you out, and report, up to what was the name again?
Ed Lyon:DesignOps.
Kate Towsey:DesignOps. You said that it's going really well. Can you talk about the pros, that you've experienced?
Ed Lyon:Yeah. Definitely.
Kate Towsey:And the cons, if you like.
Ed Lyon:No. My manager might listen to this, like, just stick to the just stick to the pros. Yeah. But well, that's the place to start. Like, one of this, like, as we talk about, like, structures, part of it is also your line management.
Ed Lyon:And I've got very fortunate that person, whatever their job title is an excellent, like, coach and lead. So in one way, there's a a thing of the part of us to all recognize and, like, what's good for your own career development as well outside of, like, the structure and the org channel, those sorts of things. But I won't give him too much credit in case he does listen to this. The benefits that I've seen kind of matched up to, like, where we were as, like, a research group and with ops within that. So I joined in quite early days of it getting more mature and formalized.
Ed Lyon:So there was foresight that they were gonna scale a lot. They knew they were gonna be hiring. Like, I joined when this company was about 1500 people. It's now 5,000, three and a half years later. And they they knew that was gonna be happening.
Ed Lyon:That was all that was planned out. So the the reason they had the foresight was, like, they they saw it coming, which was, you know, a big benefit. But when you started the ops function at that point, there was no, like, centralized process. There was no way that other folks could pick up and do things themselves. Otherwise, there's always been far more non researchers doing that research than there have been researchers just outstrips by the 100 of those people.
Ed Lyon:So we always knew that my job was for both those audiences. And when I joined, the job was to set it all up. For that stage, reporting into research was wonderful, Like, because you inevitably they were gonna be all those folks doing research. PMs, the analysts, the designers, etcetera, and you help them as much as you can, but the job was to focus on the researchers to get them in a good place that they could do their best work. And to be honest, after, like, 2 years, there was like, okay.
Ed Lyon:That's really good. We're gonna make incremental changes, but it's a good place of maturity. It's, like, really stable. People have all the tools they need, etcetera. So when this kind of force change happened, it was almost like like a spring cleaning.
Ed Lyon:It was like, here's a different perspective on it. Someone who's not worked in research ops at all, and it's, like, still a new function to so many people as well. So it kinda gave a different view on it. The feedback was different. The perspective was different, and the perspective from research was very stable.
Ed Lyon:Like, it was a the director left, but everyone else was quite stable in their jobs. We haven't had much, like, attrition or anything like that. So he suddenly got, to be honest, instead of having, like, those researchers who were, like, maybe partners or sometimes you might we might even call them customers. Suddenly, I got the gift of having peers for the first time. Like, people who they were solving for different people or maybe it was a slightly different problem.
Ed Lyon:It's all the same, to be honest. It's like, our job is to listen to people to what they really need. This is what we often say in ops sales. Like, instead of, we'll hear a bunch of things, they'll say what they need, and our job is to interpret that to the actual need. We do that in a way of research as our focus.
Ed Lyon:There's this design as a whole, which includes researchers researchers, to be honest. So getting that group of people, and, like, they were always there, but it's like, we say it's, like, it shouldn't just be formal structure that means you talk to people, but there's something in that that, again, you begin rituals, then you'll just start to have that cadence. In our modern world, we have a cozy little Slack channel where we can be selling together and suddenly you have a warm relationship, and you do start to talk when you do become people. We give each other you know, we do our own version of scripts, basically, even though we're we're ops scripts or something like that. The biggest pro was having peers who I could talk to.
Ed Lyon:They didn't really have a stake in the game. They didn't I think care, but, like, they're not gonna go and use the process I'm making in the same way a researcher would. So having that different person in the on my immediate zone, I think that was the big thing I first noticed. Like, this is gonna help me have a different perspective on how we design the services for researchers.
Kate Towsey:I wanna leave space for, either Steph or Shane to jump in, but to say, and it's interesting with, democratization that, what, you know, what I'm hearing is to do that really well and to really be within the world of the people you're, democratizing towards. I don't know if that's a way of a term. It really helps to be part of the team, literally within the structure.
Ed Lyon:Yeah. Yeah. And that's, that's gone further as well as we get more embedded within product teams. It just, that goes one step further as well now. It's not just the ops folks who have a, like, a benevolent view of your work.
Ed Lyon:It's the people who are using it and encountering the issues with it as well, and suddenly it changes it. That's not one step further as well because they've got another perspective in the or and that is, like, how could this be quicker even if you've made it 10 times quicker already, or how could this work better for my specific use case or my customer focus or whatever like that.
Shane Olbourne:I've noticed that there is well, there's there's always a trend, and it's always one of those things that does happen in this industry specifically that doesn't matter how mature your all gets, someone is making a decision where they're gonna cut it down. And they're gonna say, well, operations is they did their job. They said what they were going to do. Thank you. We'll we'll reshuffle.
Shane Olbourne:What the last company that I worked at, I joined after the company went public. They had that epiphany and said, we'll get rid of ops, and we'll redo research. Research is gonna move to product. And they kind of reshuffled everything, and they realized, hold on a second. I think we need to build this again.
Shane Olbourne:So they went out and they hired researchers, and they started very early. Then they said, we're gonna hire ops with research, and my eyes lit up. It was so exciting because I got to be part of a team that was growing their research again, separating themselves from product when product was doing all of their research. And then the leader who was leading the research and gonna be my leader actually joined after me. So you got to be there with the researchers, build it from the ground up, kind of plug yourselves in, and see their pain points in real time.
Shane Olbourne:You got to also be part of the team, and the way that your reporting structure worked is you were reporting up to a design VP who said, you know what? I don't do research, but I trust in you. And it was a really good feeling to start a a team like that. And then growing from from the ground up, even though it felt like a filing cabinet was open and all the papers were strewn everywhere, it felt as though you were growing organically together. And it was a really nice way to report into research.
Shane Olbourne:So when your research leader comes in who has, say, an innovative brain and says, you know what? These these are all things that I have done in the past. And they're like, alright. So what pillars do you think we should adopt from the research ops methods? Like, already understanding that things exist.
Shane Olbourne:And what got me really excited is I got to hear things like, we want to build jobs to be done, or this is what we're going to explore. So the researchers are like, okay. So we're all learning it together. You have an innovative research leader coming in and and really presenting that. On the other hand, if you were doing that and you were just a research ops person of 1 with a research team growing on their side, you don't see anything that they're going through.
Shane Olbourne:So I found that was really fun way, to to look at the role in a very different perspective. And to be part of it from the core was extremely
Stephanie Marsh:fun. Yeah. I've got a very similar experience. So now there's, like, 10 researchers and, like, 35 designers. But when I joined, there was 2 researchers, 2 ops people, and 20 designers.
Stephanie Marsh:So we was building the research practice and the ops practice at the same time and growing. Obviously, the research practice, in terms of people, has grown a lot more, and we've stayed, like, just quite small. But it made sense the particularly, like, given the skills in the team, to be altogether supported each other to grow a research and ops practice at the same time because the designers have been there for many years. The the good 8 years before any researchers came along, so there was quite an embedded design practice, but and they was doing some research loosely. But there was no real research practice.
Stephanie Marsh:It really made sense to, like, that mutual moral support to be working so closely with the researchers. But yeah. And I don't know if it will happen, but sort of I can see as we mature, I think it would make sense in an ideal world if I was making a decision, which I'm not, that we move out of research and into a more centralized space, whether that's customer research and customer experience or something like that, because we do want to collaborate more with design ops. But we also want to collaborate more with market research. And, like, particularly from a knowledge management perspective, just thinking how powerful it is to have user research insights, market research insights, maybe bring in customer service data, and have that all in one place, I think that would be, yes, like a utopia for me to be able to really leverage all of that.
Stephanie Marsh:And it and we do try to do it. And we obviously work across boundaries. But there is, like, budget silos and things like that that make it more difficult than, ideally, it would be to do that kind of cross organization collaboration.
Kate Towsey:And you look like you've got some deep thought going on.
Ed Lyon:I was I'm wondering that, like, you bring up knowledge management stuff, and I I'm curious. Again, when you talk about the maturing of, like, maybe we centralize as things go along, I think the the the style of the team, I think I think we all have teams of 3. So this is a nice, equal discussion. We have
Kate Towsey:a similar purely by chance. I could I could say that was my excellent curating, but it's not true.
Ed Lyon:Because, like, with 3, you we're I guess, we're mostly talking in the more, like, generalist sort of way where we haven't got hyper specialized, like, we haven't got, like, a privacy ops person, all those sorts of things. But in, like, with knowledge management, that's interesting, like, the crossroads you might be at as you do that to be more centralized. I don't know. It almost feels like a a simpler journey in one way if everyone's quite generalized because then they can spread that generalized they can scale that generalized skill wherever they need to pop in the org or something minute by minute. And I'm wondering how it would work with, like, a mix like a mixed team.
Ed Lyon:And this is like a I've never had the pleasure myself. It's, like, 3 generalists rather than having the the specialists of skill skill set. So I'm wondering how that would interact with, like, how you report or how any of us report and structure within, like, a bigger org if you have, like, a general person, but then we have a specialist person. Part of that is also there's, like, the narrative. Like, one of the things I talk about, like, mostly what we we do storytelling.
Ed Lyon:There's lots of people, because no one knows what the what the hell we do. Often when people meet me, the joke is you're the most niche person in the business of 5,000 people, because, like, there's 3 of you. Why you why why is that?
Kate Towsey:And, Ed, I could I could joke that that's the primary reason I wrote a book. Here's the book. Twelve chapters in what I do.
Stephanie Marsh:I think optics is a big thing. Yeah. Because, yeah, it's like we're very niche, but, also, we're just admin. You know, obviously, using bunnies is not very good on audio, but it's like, yeah, they kind of they either don't know what we do or they assume we're just doing admin tasks. And, obviously, admin is very important, but we're also trying to balance, like, the tactical with the strategic.
Stephanie Marsh:And, yeah, I think it's very it depends, like, who is above you and what their experience is. I don't know. I don't think there is, like, anyone. Like, we have to be organized in this way. I think it's very context dependent on the organization who's there.
Stephanie Marsh:Yeah. Because I was also thinking, is there anywhere that ops could sit that could be like a comfort of interest? Because, certainly and it may be different, but, certainly, like, from a researcher background, I've been in organizations where we sat under a UX umbrella or a UCD umbrella and then moved to product, and then we had to move back again because it did not work. Because, like, you need that neutrality with the, the product people because it's, like, speaking truth to power. It's like, well, this idea that you suggested, we did the research, and it's not gonna work.
Stephanie Marsh:We need to pivot and do something else. And it's very difficult for the researcher if they're saying that to their man their their line manager as well as their product manager, and I think that's quite a difficult thing for people to manage. So being, like, peers with product really works as a researcher. And I wonder what people think about sort of, yeah, who ops peers should be and who we should report in if that's different or the same.
Kate Towsey:I've long thought it might be interesting to, work more closely with all the other operations folks in the organisation, you know, human resources, operations, or marketing operations. And, when I was working at Atlassian, Again, these big organisations, even 5, 7000 people, they're big organisations. And because of structures that can be weirdly difficult, even working in a virtual space to jump those lines and get to know those teams in, in really productive ways. I find often it's because they've got their priorities that are set and they're totally different from, the priorities that might be in your part of the organisation. And so the ramp up to creating relationship where you can then synchronise priorities and funding, takes a long time.
Kate Towsey:But I've, you know, in imagine a world, I feel like science fiction where, or ops fiction, it must be some genre, where, Yeah, exactly. Where operations, all work together across the organisation. Because you know, skills frameworks and that sort of thing, and, technology. So, like, I'm not sure about DevOps, but the operations of IT. So it seems like an ideal, but I'm not seeing that happen anywhere.
Kate Towsey:I've never heard of that.
Ed Lyon:No. We have like some like loose rituals bringing together, like, people that would be referred to as ops, which has maybe up, like, a 6 count of different ops types for us, and it has benefits. But I think also that there's a misnomer. I think it's everyone who will be in ops in some way title. Like, for instance, we have, what we call engineering ops and what we call developer ops.
Ed Lyon:We but that's we have, like, a 1000 engineers. There's one person. Their job's really, like, cheap of stuff, which is an an entirely different job to, like, design ops or research ops or product ops sort of person we have here. Product ops, a lot of their work is program management. So what we've found useful and tricky so as as you we saw our research ops has changed, you need to find different peers.
Ed Lyon:It's like the formal structure would have inhibited it. So to begin with, we had to, by necessity, become really close with we call them our customer relationship management team. Like, they they if you wanna send comms to the customers, which in our case is you wanna recruit, you go through them. They hold the process, their tools, all those sorts of things. So to begin with, it was important where we were, and they were establishing at the same time.
Ed Lyon:We you could grow together. And at a certain point, your goals are gonna diverge. Your headcount's gonna change. Like, your structures and your priorities will be different. And, certainly, ours was to maintain and, like, specialize with, like, maybe in the the toolkit for, like, 12 months.
Ed Lyon:Theirs was to scale, like, crazy because the need for them was great. So suddenly, they went we started, like, 1 each. Then now there's 3 of us, and, like, they need 30 plus people because of all the comms that grow and the complexities of doing it in under different languages, etcetera. So then if you had formalized that, then, well, that you'd have to change after trial. We keep on saying, like, all these reorgs happen.
Ed Lyon:So it is, like, finding this, like, skill of, like, loose but, like, committed partnerships. So as we, like, said goodbye to that team, suddenly it was privacy and legal as our priorities change. And then we like, at least one of our team would meet with them often, and now it's design ops. So I think there's that that structure and the reporting is could almost inhibit. If we if you do change it, you might we might change thinking we should be with so and so.
Ed Lyon:But then as we've all experienced through our careers, we all this will happen. They'll come for you. And do you have the relationship and the rituals and the benefits of, like, collaboration that will maintain even if you're sitting in a different part of the office or even a different Slack channel or your stand ups with someone different this week? You know what I mean? Like, it can be, yeah, misleading,
Shane Olbourne:I think.
Kate Towsey:That's interesting. There are so many people going through reorgs constantly at the moment. I think that they're going to appreciate the very positive note that reorgs come with a silver lining that every time you reorg, you get to deeply know the structure of a different part of the organisation, the people in it. And so with, with the reorgs, you become more and more, connected and embedded within the organisation. I'd never really thought of it that way.
Kate Towsey:And so then the trick is to try and hold onto that connection as you move and shift across the organization. That's gonna be a gem for some people, I think. Let's take a super short break to hear from Ned Dwyer, the co founder and CEO of Great Question. He'll share his thoughts about the topic and will rejoin the panel straight after.
Ned Dwyer:I first wanna caveat that, look, I'm not a ResearchOps person, but from what I've seen, the more visibility that ResearchOps can get across the organization, the better. That's largely gonna depend on how the organization is structured. In a design or prototype of the organization, I think reporting to those functions and supporting those teams, being close to those leaders can be massively beneficial. Not just for visibility, but for access to larger and more discretionary budgets, access to decision makers who can see the impact that you're having. All these reasons why I think aligning yourself to the most powerful parts of the organization is better.
Ned Dwyer:I think there are risks in this, like, that maybe you're gonna be overlooked as less important than your designer ops or product ops colleagues. But I think the the collaboration potentials massively outweigh the downside risk. Just think about things like procurement or vendor management. When you can lean on individuals who can then specialize within those functions as opposed to distributing those, I I think that's really clear to see that 1 plus one equals more than 2. And the reality is product and design, they both need research ops.
Ned Dwyer:So I don't think you're gonna necessarily be diluting the power that you can have in the organization. So I think the real question that we should be asking ourselves is more, who should research be reporting into? But I think that's probably a can of worms we don't wanna open here today.
Kate Towsey:So, I wanted to move back to, a good question that you had, Steph. And, Shane, I'd love you to hop in on this as well. The question of where does ops start? We've spoken about it being very helpful that operations starts in a research space of, like, ideally, like starts with research. So the first, second, third research are there and ops is already there building from the ground up with them.
Kate Towsey:And at some point, when there is a desire to move operations, to, you know, to democratized support democratized research for designers and PMs and whoever else, it can actually be very help helpful to move as a partner next to, research. What have you seen as the maturity path for your team, Steph?
Stephanie Marsh:Yeah. So I think we're at, the crossroads now that the the research practice is established and embedded. And, as design ops starts to mature, we're starting to come closer together. But most of our rituals are still with the research team. So it feels like, yeah, we I think the interesting thing is getting that balance of still keeping the contact, like, that connection with the research, but then also, as Ed was saying, like, getting to know other specialists more deeply and how we balance that.
Stephanie Marsh:I mean, the the agile thing of having too many meetings, like, how many rituals should we have? Like, should we have them with the design ops, with the research, or are there other ways to, to have those connections? And, obviously, we have the knowledge management side of things at Springer Nature. So we're thinking about that and, yeah, realizing there's so many other knowledge management people with different titles that we haven't met yet, because it's an organization of 10,000 people all across the world. So there's you know, you never every week, I learn of a new team that I haven't heard of before, even after almost 5 years.
Stephanie Marsh:And now, we are also with the European Accessibility Act coming in. We are ramping up, being more inclusive, and thinking more about access needs in our research, So building bridges with the front end accessibility team and the DEI team and things like that. We end up going all over the organization. So I think, in some ways, I'm torn between it almost doesn't matter where we sit because we will go and make the connections that we need to make. But, yeah, I think, mostly, it comes down to, can we make the budgets and the people and, like, the resources work for us?
Stephanie Marsh:I think that's where, sort of, where we sit matters the most. Not the connections, but, like, the budget for the tools, the budget for the people, all those things. Aligning them, I think, will be, like, the next step in maturity for us to, like, really be able to scale more and be have more impact, If that makes sense.
Kate Towsey:You you get this very lit up look in your eyes when you talk about that. You won't be able to see that on the podcast, but you can take my word for it. Shane, you've mentioned earlier that you think you've worked in 6 different companies. So you must have a very broad view across the maturity path. You've spoken about MongoDB.
Kate Towsey:Oh, no. It was your previous company to your current role. What what have you seen as the maturity path? Let's let's start with the best and worst, you know, or go with the best and the worst. What is the maturity path that you've seen that have worked and ones that you've gone like, wow, I wouldn't repeat that again?
Shane Olbourne:So the maturity thing is a huge question that we always ask, and it depends on where the research maturity is at. If your research team is embedded into a product team, and let's say your research team has a high maturity level, but your product team doesn't have a product excellence maturity. That's that's one example and I'll get to that in one second. But there is also another part of it as when you are a, I would say, a mature ops team and you're running efficiently because you came out to I mean, we're we're very lucky. We've inherited, k.
Shane Olbourne:We've definitely inherited where you've come from and the pillars and and that really is something that we all kind of some of us may have said, you know what? I kind of did that in the past, but really now it's solidified, and it's becoming more and more published, and it's becoming more and more celebrated and shared. So every company that hires a research ops person always does this, and it's I think it's repeated itself. They come in and they say, what are the things we need to spend time on? What are the things we can throw money at?
Shane Olbourne:What's gonna stick? And the first thing that you always tell them is, you know what? We've gotta be compliant. If we're gonna get bringing people, we wanna make sure people are opted in. We wanna make sure we're doing the right things.
Shane Olbourne:We wanna make sure that people we're bringing our researchers are compliant. They, that they they match the requirements. They agree to everything, and everything is kosher. So by the time we serve that person to you, there you go. That's exactly what's gonna help, with the product org, etcetera, etcetera.
Shane Olbourne:But where it comes to that problem is if you do everything right and you have all of this structure and you have everything that works and other teams look at you like, they're very structured. How did they get that going? They only have it they're only supporting a small team of researchers. And then the design ops could say, well, we're we're we are supporting 100 of designers or product managers and product ops. And, like, you know what?
Shane Olbourne:We have we have product ops, but they're not doing clearly as as much, I guess, impact per se or doing much structure on on what they're doing. So the problem that you get to to say to you is, obviously, yeah, I'm only supporting this many researchers, but it's always because this is a kind of a with a last to the table with a newest art form or with a newest operation structure. So that's kind of what I'm noticing. But then you get to the point of my last role was kind of lucky because we created this. We created research ops, and they were like, hey, you did it really well.
Shane Olbourne:But, hey, you're too matured. Everyone has to catch up to you. Can you go over here and see where other problems could be and bring other teams together? And I moved into a different approach where it was more of, let's go bigger to product. The team reports up to product.
Shane Olbourne:Let's see if you can kind of do the same thing for design and product and kinda edge that. And the coolest thing was the market is now as you noticed with tools, the the coolest thing is tools are evolving and getting really smart really fast, and everyone is getting into the tool area. But with products specifically, is there is tools out there that is all about insights, priorities, linking CSMs together, linking sales together, linking PMM, research, design, product, that it's really changing how we are working as a as a maturity level. So everyone kinda gets on the same page. And that's probably the most exciting thing that I've seen is you're bringing out you know, there's different, I guess, different strategies from how ops teams are going to work that you can really plug in.
Shane Olbourne:And I would I would love to be part of that, as you said, Utopia before, where imagine that research design, product, and everyone is all plugged in, and everything is transparent. And they all can see everything from road mapping to delivery, and they can see the impact of where that research plugged in, how that design implementation changed, how that feature changed, and who was involved in all of those parts. I would love to see that. And then have a customer report back and say, here is my issue, and everyone knows who was part of that issue and where that is. The ultimate utopia, and I think that's kind of what we're all working towards.
Shane Olbourne:And I think it's it keeps happening with the way that ops keeps evolving together.
Kate Towsey:It reminds me of a book that I, I'm I'm busy reading at the moment, called Product Operations. I've got it up here on on because I can never remember the full name. How successful companies build better products at scale. It's by Melissa Perry and Denise Tills. I think you've pronounced her surname.
Kate Towsey:And, what I'm enjoying about it is that, they beautifully map out, product operate, you know, the various they've got their own pillars. Research insights, I think is 1, and I think marketing is another one. I I forget these three pillars. And one of them is research, but research operations is like a footnote in here. I think so far, I think I'm in chapter 5 or something, and it's research ops as mentioned once.
Kate Towsey:And I'm looking at this entire pillar and going, that's the work of research operations. But imagine the product managers have got such incredible business sense and data sense and structure sense. They bring so much that if you work in a purely qual research space, isn't already sitting within your own research team. And so I think it would be so powerful to be able to partner more closely with product operations. Are you, Ed, I think, you know, in your structure, it sounds like you are partnering closely with product operations.
Kate Towsey:Is that true?
Ed Lyon:Yeah. Yeah. Throughout to the all three design, research, and product ops were hired at a similar point about three and a half, four years ago. The the functions have all stayed. The people have changed each of them as such, so the focuses have changed.
Ed Lyon:But so frequently, in both case, I'll I'll stay with product ops. They have been, like, very incredible partners at these big moments throughout the journey. And one of them was around, like, this thing we're touching on, like, the product ops person or PMs were getting very interested in insights as as it was the the term. I'll use that term very loosely. Data to inform business decisions is is is how their definition was.
Ed Lyon:And I like Shane, you mentioned there a minute ago how it's exciting that all the tools are, like, incorporating these things that are becoming often not like a one stop stop shop, but tools that encompass different use cases rather than qual and quant researchers. It's PM designer and researcher and stuff, and it's almost actually, it adds like a signal of where, like, a partner could be or, like, a strategic partner, or who's sending tool requests. And it it has changed over the years. And the first sign of this was, when we were looking at bringing on some sort of knowledge management, some sort of, like, data analysis call data analysis tool, it was people in product, specifically product ops, that were the biggest champions alongside the researchers, very much like, yeah. Great.
Ed Lyon:Brilliant. Go get it. Whichever one, they all sound great to us. But it was a product ops person at the time who was the most pretty insightful, and the one one who brought the most, like, challenging questions to it about how it could be applied. How how are you actually gonna take this to the product teams?
Ed Lyon:How will this actually envelop into a day to day environment and it actually impact decisions and those sorts of things? And it is especially you know, the the same with us. They could have there's lots of different perspectives within product ops. But that that proximity to at least in in WISE, it's often there'll be some sort of, like, a product owner is, I think, an often more useful language. Like, they're kinda responsible for their area.
Ed Lyon:They're not solely the lead or the person in charge, but kind of they will be reporting, and the buck stops with them often enough in situations.
Shane Olbourne:I like that they have a product development life cycle that they can just spit that out once, and everyone's like, oh, I get I I'm I'm on that same page. I'm on that same page. And then an engineer can say, we have a software development life cycle. So they have 2 strategic things already, and then there's the double diamond that's in there. So research is kind of mentioned in the product development life cycle.
Shane Olbourne:And it feels as though once that conversation starts, it's like, where's my place in it? And I think that's what it's kinda starting now. It's like, yeah, you do have a space. Here it is. Once your team has, say, a a relationship, which is what we do really well is where people connect us and we can get everyone involved, I think that's where ResearchUp shows its value too.
Shane Olbourne:That we can say, hey. This has already been mentioned in these conversations. There's already road maps that are here. They're already working on this, if there's knowledge management that connects back to that. It's so nice that we have that luxury now that we can plug that back in and say, this exists.
Shane Olbourne:Here is documentation. And what we do best is we also that we connect, we're also best practices, specialists. So we can always go in and say, hey. Have you noticed this? Have you noticed that?
Shane Olbourne:And just pointing people to the right direction, being like a docent. It's a lot of fun that way.
Stephanie Marsh:I think, yeah, going back to what Ed was saying about product ops and being partners, I think it's a really strong case for being close to them in terms of literacy of each other's specialisms. So, yeah, like, the product people having research literacy and research having product. Let's say literacy is really important. And the reason I thought about that was, like, tool request is something I've had from day 1. We need and then I always come directly back to knowledge management.
Stephanie Marsh:But I remember day 1, I was like, we need an insight library. And then it's like, okay. We'll gather. We just joined. But, you know, after, you know, figuring out the landscape, realized it's like, oh, we're we're so far away from having an insight library.
Stephanie Marsh:There is so much knowledge and best practice that we need to build up before we can have an effective insight library. Like, we're not even naming our files consistently. I don't think we're ready to actually manage some insights. So I think having, that literacy of each other's special innocence really helps sort of understand maturity levels and, like, where we actually at. Do we need a tool now, or do we need to do training to do a thing to then eventually have a tool to manage thing?
Stephanie Marsh:But, yeah, it always starts with we need to talk rather than we need a practice or, yeah, a process or something.
Kate Towsey:I often think of, operations as being akin to, like, commuting and traffic control because you have trains and you have cars and you've got bicycles and lots of different modes of transport in the city. And if the train people decide they're just going to do their own thing and they don't speak to the road people and the road people don't speak to the bicycle people, then everyone's going to be riding into each other and nothing's going to work very well. And so the better that we can coordinate with the other transport types in the organisation and map out the entire transport, transport network together, the better things are gonna run. And I feel that that's in a way what we are talking about. Our original question is, just to kind of recap where it's gone.
Kate Towsey:I've deleted it. What it is, is that I'm using the space bar and I keep going onto the Google document and then deleting the sentence. So, the main question that we have is what are the pros and cons of reporting into research versus other ops like product or design? The one thing we haven't, we've covered a little bit in there is the, pros of porting, reporting into product or design operations at various parts of the maturity area. And then I find it interesting that we have also knocked on the door of wherever you report into, you still need to know what the train people, the bicycle people, the road people.
Kate Towsey:And if we can get to a place that we're structured in a way that we can be working all together to make a cohesive civic system, then that is gonna be the true utopia. It's not even just being embedded in a team with operations. It's actually doing that deeper work. So as part of our main question today, I feel like it's it's kind of, owing that we at least cover what are the pros of working under research specifically? Who wants to dive in?
Shane Olbourne:I think a good pro of reporting into a research team is when you're part of the road mapping, the planning, and the prioritization. And I think that already sets up. You can anticipate most of your roadblocks. You can anticipate where most things are coming from. And you also have built in advocacy.
Shane Olbourne:You have built in planning for, if you were going to bring in, say, what other ops strategies are like people, platform, process, it allows you to think along those lines. So you are already reporting to them. This is how that is structured. The only thing that I see is a little bit different is you're always gonna have to advocate for yourself. If you're an operations person and a small team reporting up to research is when it comes to the time that we always care about, which is calibration time.
Shane Olbourne:How have you shown your impact? This is the best time to show quality and to show, I guess, your value there as well. That's how you can show impact, because if you know exactly where research is going and if you're kind of ruddering the ship and steering that, that's a great advantage to report up to research.
Kate Towsey:It's pretty silent from the rest of the room.
Stephanie Marsh:Yeah. It's been I just there's so many things to think about from this conversation that's been really great. And I just sort of thinking, like, I think all the things I was gonna say is we could do as peers of research as well. But I completely agree with what Shane said in terms of if we know where research is going, we can be strategic about what we're doing to support. But we could do that equally as partners or reporting into them.
Stephanie Marsh:So, yeah, I don't think there's a conclusive answer anymore.
Ed Lyon:I I think my answer is it doesn't matter. And, and like, I think if, if I'm my most truthful, we could be, we could be doing just as good a job if we were reporting into a research director as we had previously. It's about maintaining the extra effort of the relationships outside of that one that's a given, whether that's with ops folks, which is, I think, maybe harder to do. Like, if you if you're within research, my hesitancy, like, that's can almost be too cozy. You're, like, everyone there completely, like, pretty much, like, we love research ops because we're researchers.
Ed Lyon:It's a very, like, empathic room to be inside of, and you're all, like, very warm and fuzzy. You can say I think that one's easier to maintain when you're outside of it. It's harder to build whether wherever else it would be if it's another ops, if it's product, whatever. Those relationships are less automatic. They're less of a given, So I think you already have such a good chance of having a good working relationship with researchers because they know firsthand all the pitfalls and how wonderful it is when you make these incremental changes or you do all that how effort it is to change tooling or something like that.
Ed Lyon:Other folks, we're so niche that I think one of our we'll add we'll add a a pillar, like, become less niche. That's that's the new one.
Shane Olbourne:Like, Mhmm.
Ed Lyon:And however you can do that, whether that's reporting lines or it's inserting itself into other people's meetings and whatever it is. So I almost, like, disregard, like, reporting lines is one thing, but putting yourself about wherever you happen to fall and, like, sharing your rigor and, like, your approach and how useful your that approach is, whether it's like Shane, it looked like how it's yours seems to have changed, and you was like, you know, like, Shane's done it over there? Brilliant. Now let's see what Shane do it in that place, like, the same rigor and the same approach, but, like, the day to day might look really different. And I think that's that's something I take a lot of, like, heart from to know, like, apply the same skills but in a different way And, like, be a surface is is really what it's about.
Shane Olbourne:There is a little side effect that I noticed. Go on there. So when everything happens and you report under research, and let's just say you're growing this is I think it's probably good if you are growing a team and you're and you're embedded in part of research. That's the things that I mentioned before. They kinda work together, but here are the disadvantages that happen that organically are gonna happen.
Shane Olbourne:The us versus them starts to appear, and we're all trying to avoid that. We don't want us versus them. The compliance and all of the stuff that you do build as part of research because there's not really anything really like it, but when it comes to research and how you are customer facing with a lot of your, communications, the way that you work there, you also start to notice certain teams, if they are doing, say, reaching out to customers, having customer contact, that they don't do those practices. So it automatically makes you go a little bit resentment towards that. Like, I'm doing all of this work to make sure that our researchers get people that are qualified and correct everything's right, and they're just going to a Rolodex and calling their favorite customers.
Shane Olbourne:And then they end up saying something like, But that's an insight, or, That's feedback. That's our research. So it automatically happens that way. So if you're not part of it and you don't see it, you don't have that 10,000 foot view, you're definitely not gonna see it. And it becomes like groups of teams, everyone kind of talks to each other, there's not really stand ups that researchers don't talk to product, etcetera.
Shane Olbourne:That's the thing that you try and avoid. And the other thing is when you get too highly specialized is it looks you don't have that flexibility in your day to day as well. So you start gaining these bad habits. So it's very hard to stop that and to say move out. They're the things that I've noticed and I think that if you what if you started reporting to research and they're like, alright, so here we are, we've done the 6 to 12 months, now we move to the next part and now you can move the operations a little bit out and start branching out.
Shane Olbourne:It's kind of like, you know, 1 in 10 doctors agree that if you start a research ops, then you're gonna start having these, personality traits. But I think that's kind of the way to kind of stop that is really know that it's coming. Definitely want to work with your stakeholders more. But now that you've gained that little level of maturity, you can widen out.
Kate Towsey:And that takes a really, open minded and mature research manager to let ops go when time is right, and allow operations become a partner rather than a reporter, which is really interesting. I don't know that every manager would have that that openness that I've met at least to be able to do that. So perhaps one of the takeaways for any research managers listening to this is, that they can be great benefit in moving ops out and then next to you as a partner, allowing them to be embedded in a different team and that you don't necessarily lose all of your operations goodness. You can just spread it wider across the organisation. We are right on time.
Kate Towsey:Actually, it's 5 past, so we're a little bit late. Are you all good to go for another few minutes?
Shane Olbourne:Sure. Yeah.
Kate Towsey:Okay, great. I feel like, there's some really good endy stuff in there that I can pick out as, as end of. Is there anything though that you thought that we were gonna talk about today that we haven't and you're like, oh, I really wanted to say that thing because this is your moment.
Shane Olbourne:You were about to hit on it. And you're about to hit on it. And I was I had something that I did a bad thing and I kind of prepared something, but I didn't wanna forget it. Because I think it is what does it look like? In your opinion, what is the best structure for strong research ops capability?
Shane Olbourne:And one that grows the impact of research too. And I think we're all kind of repeating the same things, but what I've noticed, the hybrid approach kind of is that next approach. Like, yes, you've started with a team and you've kind of gone in and out or you dotted line or you kind of move left and right and you lateral move. But I think the hybrid approach is if you are sort of embedded, and how products do change is maybe you float to a product and maybe float back out, but you still have a core that reports up to a specific function. That would be really nice for the future of ops.
Shane Olbourne:And because we are influential and we are a trusted partner and most of us, we work in comms a lot. We're always trying to convince. And when it comes to budget management and really trying to be, I guess, geopolitical in a way, but that's kind of what we do. And I think there is a lot of it there, like going in and out and floating and definitely using those really strong skills that we have. We're inherent problem solvers.
Shane Olbourne:And I I say it all the time, it's kind of what we do. So use the strengths of what ops can do and complement your team.
Stephanie Marsh:Yeah. I think one of the takeaways I've had from this conversation is, yeah, ultimately, it doesn't really matter where we're reporting to as long as the person above us gets it. Because and often when there's, like, restructuring, you could be someone will inherit your team, but they don't really know what you do. But as long as that person, you know, whether they're a research director, an ops director, as long as they get it and they can provide some cover, that's what makes the difference. Because, yes, we are inherent problem solvers, but even when we are making things better, we are disruptors as well.
Stephanie Marsh:And, you know, obviously, we're trying to make sure that processes happen as smoothly as possible as we're iterating them. But, you know, no one loves change, and so we are disruptors too. So I think having that cover by someone who gets it is really important.
Kate Towsey:I think that's that. That's a beautiful wrap up. A big thanks to our guests for sharing their time and expertise and to our sponsor, Great Question. Learn more about Great Question at greatquestion.com/chacha. That's c-h-a-c-h-a.
Kate Towsey:In 2 weeks, a different crew of ResearchOps professionals will tackle another Great Question. So make sure to subscribe and tune in. This podcast is a limited edition series produced by the Cha Cha Club. We're a member's club for ResearchOps professionals. You can find out more at chacha.club.
