Erin: 00:34] Hello everybody. And welcome back to awkward silences today. We're here with Roy Olende. He's the research operations manager at Zapier . Today, we're going to talk about something that Roy says, people ask him about all the time. And maybe it's something that you've thought about too, which is transitioning from a role in UX research to a role in UX research operations.

So we'll get into how Roy made that transition himself. And some things you might want to think about if that's a transition, you're curious about yourself. So thanks so much for joining us, Roy.

Roy: [00:01:09] My pleasure. Really glad to have to be chatting with you.

Erin: [00:01:12] And JH is here too.

JH: [00:01:14] Yeah. we've talked about both of these topics a lot, but I've never actually thought about the prospect of somebody moving from one role to the other. it'd be super interesting to see what we get into.

Erin: [00:01:22] Yeah, so yeah, so Roy. Maybe we could start with, tell us a little bit about how you found yourself making that transition from UX research to UX research ops.

Roy: [00:01:31] So I've been in a full-time research ops role since the start of 2020. But for a few years before that I was a full-time UX researcher. And, part of my role was actually helping designers and product managers learn about research, build out systems and resources to help them to do research better.

And so at the end of 2019, I came to the end of my role at my previous company and was just looking up, you know what's like the next step for me. I think. I jumped into my new job search thinking about UX research, because that was my sort of core skill and strength, but there was this consideration on the side, which was, research ops is this growing field. There has been a lot of attention paid to research ops in the last couple of years.

And really part of my job has been to do this. As I considered my next role and thinking about the future, I thought this is a really sort of bare land, right? there is an opportunity to play a part in shaping what research ops looks like in the future. Long story short, I got a few opportunities and I decided to switch into ops because I thought this could be a great opportunity to not only help folks within the team. I work Zapier, but to play a part in shaping this practice, because even though it's been around in some fashion for quite a few years, it's really risen in prominence the last couple of years.

And so there's an opportunity here to make an impact.

JH: [00:03:05] When you have you looked at the landscape around, research ops? Is it the case that most people who move into it are former researchers themselves like practitioners and you need that experience to be effective on the operation side? Or do you see people coming into that type of role from different backgrounds as well?

Roy: [00:03:21] Yeah, it seems to be a mix, to be honest, I'm part of a group of. Of research ops, full-time research ops people, and we meet once a month just to chat over stuff. And there's a real mix in terms of background. Like some folks have come from marketing, some folks have come from straight business ops type backgrounds, and some folks have come from user experience, have come from research. and I think there is, I think because the name is so tied together and the work that you do is so tied together. There's part of this where initially. I think most folks would think, Oh yeah, you should have a UX research background.

But the work of research operations is actually quite different from the work of UX research. UX research, you are, you're digging into these questions, you're finding answers to. to topics that are going to help a team make progress in some way. but with research ops, it's really about delivering a service, right?

And so there's some different skill sets that are at play when you're talking research ops versus research. So this is where I think there's been a diversity in terms of the background of people who come into the field. even though there is, I think. I think sort of an assumption that a lot of folks in research ops come from UX research.

That's not necessarily the case.

Erin: [00:04:43] And were you the first research operation? Tire at Zapier, or did you join an existing team?

Roy: [00:04:49] Yeah, so I was the first hire. So the goal is for me to set up the research ops function as the company grows and the research team grows, and we also have designers, product managers, doing research in the company. But yeah, so I was the first hire. The head of research who is, her name's Jane.

She's an incredible head of research. She knew from the offset that from the outset, that it'd be really, it'd be really important to lay down some structure in the early days, so that as the team grows, we're not scrambling to figure out, what resources we need, what we need to build so that research can happen at scale.

So her approach was to bring me in early so we can build it from the ground up. I know other teams have taken a different approach where it's come to the breaking point and then bring in a research ops person. But yeah. I'm the first one who, who's done this at Zapier

JH: [00:05:38] So you make this transition. You're the first hire in this new role at this company? Like where did you start? Like what, uh, what things were most top of mind on the op side, as you stepped into that role?

Roy: [00:05:50] Yeah. I think as I stepped in, it was interesting, like even during the interview process, the two things that stood out, which I think stand out for most research ops functions, are recruitment. So like figuring out participant recruitment, because that's a big headache and figuring out knowledge management.

So coming in, I was thinking, Oh yeah, that's probably what I'm going to focus on. It seems like those are two big rocks that, if I could make progress there, it's going to help the team. but before even diving into that, I needed to understand how research happened. How does research happen at Zapier?

Which teams do research? How does research differ? When we look at full-time UX researchers versus designers and PM's and marketers and all that stuff, because in the end, you can't just come in and apply a framework to a team without really digging into the context. Right. So that's the first thing I worked on, it was like researching research.

If you talk about that in the meta conversation, yeah, just researching, how do we do research? And as I was doing that, we also had an initiative that kicked off, which, internally we call these all hand research ride alongs, which were. So, for a bit of context, every employee at Zapier is expected to spend a couple of hours interacting with customers.

And mainly that has been through with the support. Support channel. So like email support, but we opened up these other channels like jumping into live chat, jumping into research, ride alongs, which are just open research sessions. So my plan was to focus exclusively on researching research, but this opportunity came up.

And so I put in place a program for anyone in the company a couple of times a week, just jump into a research call that's happening. So this part of this is where it's like. Yeah, you have these plans and intentions as you come in and then you also adapt to, to the changes. But fundamentally I think anyone who's starting a research ops practice, it's really critical to know how does research happen here?

Because it's likely that it's different from how research happened in another context that you came from.

Erin: [00:08:01] And how did you endeavor to figure out how research happens? I suppose the obvious would be to talk to. So people who are doing research, but, did you have, you know, a list of questions to ask them or you, what insight were you trying to get to? I guess not just how do you do research, but presumably how can we do research better?

Whether that's more efficiently or more quality or, whatever that might look like. And did you have an idea of where there were opportunities to improve the research going in?

Roy: [00:08:32] Yeah. I think fundamentally, I just wanted to understand, like, where are the problems? and then where are things going? What are the barriers to research for different teams? Are those the same for full-time UXRs versus someone as a PM or designer? And then what has worked well in the past.

So just getting some, yeah, just some guidance around. the state of research. And this is where my background in research was a hundred percent helpful. I think it's not impossible for someone who doesn't have a research background to do that well, but I definitely could frame my questions and frame the approach to learning, a little bit better because I have a research background, but fundamentally, all I was trying to do was understand, okay, what are the problems?

And what are areas where we're doing well? So it's essentially speaking to different groups, like a bunch of product managers, a bunch of designers, all our UX researchers, a bunch of people from marketing and just learning like. Yeah. How are things going? How have things been things different now compared to how they were, if you were here two years ago, what's changed.

Why has it changed? So just getting that deep context, and personal, opinions and perspectives from across the company, just helped me to then emerge from that with, okay. I now understand. You know, say in our context that our research works quite differently for those within UXR and those outside of the UXR function.

And these are the problems that we have across the whole team. And these are the ones that are maybe just within certain teams. So if I can understand those core problems, like what's been going really badly and then what's been going well, really puts me in a good place and really did put me in a good place to think about projects going forward.

JH: [00:10:22] To, to pivot a little bit. You mentioned, this was a transition you were considering for yourself and then have since made that transition. And you said some people ask you sometimes for advice or are curious about it as well. What would you say to somebody, like, in the sense of you'll love research ops, if you know, like how would you, like what factors or what traits or like good signals that someone should be serious about moving into this type of role.

Roy: [00:10:45] I think fundamentally at this point where research ops stands, I think you will enjoy research ops if you're comfortable being like an explorer, being in unchartered territory. You know, there's not many people who maybe no one can say I've headed up. Actually, there is someone I know I've headed up research ops for five plus years in an organization.

There's not many people. I can count them on one hand. So you are starting off a new practice in a company where people generally have no idea what you do. So you have to be comfortable going into a place and just venturing out into unchartered territory. You know, I think about a practice, like UX research, which maybe was at this place a few years ago where people were sort of asking, like, what is, what is this really about, what sort of value is it? Does it bring to the organization? It's not that we're fully there yet with UX research, but at least it's further down the path. Where people can understand, it's important to speak to human beings and really figure out their needs and their desires. So with research ops that's the first one. You have to be willing to be a bit of an explorer and go into unchartered territory.

The second one I think of is like you, you are now in a practice that is about delivering services.

Like you, you deliver items that people are going to use. When you're a UX researcher, you sort of uncover insights and then someone else takes action, right? Generally. But now you are the one who's going to have to take action. You're going to have to build something. So if you enjoy building, if you enjoy the challenge of creating something new, even more so than uncovering those insights, which is obviously valuable.

That's a piece that's important as well, right? if you like to create something and you're in a different place now, because once you create stuff, you're getting feedback about it. you're essentially putting yourself on the line. maybe a little bit more than on the UX research side.

That's another component, right? So one being comfortable. You're venturing into uncharted territory and two are getting into the space where you are making things like you are delivering services who have delivered in resources. if those two things feel good to you, then maybe it's something worth considering.

Erin: [00:13:08] I'm interested in this idea of operations as building something and you're talking, you know, building services and, I think of operations largely, right. You're building processes. so do you, what do you think of as the output of. What an operations team is creating. And you mentioned services. So like you talked a little bit about recruiting and knowledge management, for instance, being key pieces of what you think about, what are some of the stuff you create that gets used by the research team?

Roy: [00:13:44] Yeah, it really varies. And again, this in my context may be different from what happens in other contexts, but, something as simple as. Something I'm working on right now is a well-defined process for how folks outside of the UX research team do research, right? Like, these are the things you will do, and these are guidelines for how you can, you can accomplish these pieces.

And that, it's actually a, sort of a big effort because, you sort of have to understand. In our context, how do we build products? How do, how does the design team work? How does the engineering work? What's the handover process between design and engineering and that knowledge? Similarly, how do PM's work and how do PMs work with the designers?

So it's not just about, this is a good way to do research. It's Oh, what are the other pieces within this ecosystem? And how can I then create something that's going to work for this context. and when you, when I say something like a research template or research checklist, anyone of us could probably scour Google and produce something, like pretty easily. That doesn't mean it's going to work. In the context of Zapier. So this is a way to think about the service angle, right? You have to consider the elements happening backstage for a designer and the incentives at play for a PM, and then try to create this simplified system for them to do research so they can learn and they can make progress.

But also think about, if I set up too much, then no one's going to actually do this. So there's just a lot of factors at play. you're weighing more than just creating a process. There's so much context underneath that and so many incentives and, yeah. And other factors that play that's sort of why I frame it in the sense of, you're creating a process, but you are thinking, you're thinking a lot deeper about it than just pulling out a process and handing it to a bunch of people.

JH: [00:15:50] I have to ask, since you work at Zapier, as you are designing, building all these things, and it's a tool, right? For connecting different things through automations, or do you have like tons of zaps? is this, is that part of the, I'm just very curious, on that side of things.

Roy: [00:16:05] Yeah, honestly, I do. One of the values we have is, don't be a robot build the robot. So we're very much about if there's something that you're doing repeatedly, a computer is probably better place to do that than you, right? Not all the time, but in a lot of senses.

So it's a core to how we work as a team is thinking through. Do you have to do this manually? And if not, then either builders build a workflow for it, build a zap or buy a tool. That's gonna do it for you. one of the things I wish I had done before I joined Zapier is actually used Zapier more like I'd heard about Zapier, but I wasn't aware of all the things that it can do.

So as an example, we think of a zap that's set up. A super simple one is for these research ride alongs that we have. Anyone across the company can jump into a Slack channel to see when these research ride along sessions are happening. So there'll be a zap set up for throwing this information into Slack, whenever the call gets booked, and you just have to react.

So you add a check circle to that Slack message and it automatically adds you to this event and then sends you some information about what's going to happen. and then right before the call, about half an hour before the call, you get another ping. and you've got some more information about how to join the call.

So all these things. In the end, they're pretty simple, but, because we've thought about the human side versus the more automated side, it's just really easy to go and build us out because this is the world in which I live. yes, a hundred percent. I definitely build a lot of zaps.

I will say though, that there comes a point where you probably need to buy something right. That will simplify the process for you. we have some folks who have zaps with a hundred steps, you know, like, you know, they have, they have a trigger then a hundred things happen off of this.

That's okay. But in terms of the configuration we have right now, it's probably not like the greatest set up. So we use zaps internally, quite heavily. We use our tool because. Especially in an ops role, it's really valuable to not have to do things repeatedly. but there also comes a point where it makes sense to like to buy a tool.

Erin: [00:19:17] One of the things I keep coming back to, it all starts with understanding your, your internal clients, the people you're serving as the UX research team and not just the UX research team, but the teams they serve. So the entire organization. And if you can really understand. Their problems, their opportunities, their motivations, their blockers, all those things you listed.

That's how you get to the right solution, whether it's a zap or a process or a combination of, enablement around the process. Cause that's a huge piece of it too. It's like we have this process. Why isn't anyone using it? Or we have this process, but you know, it's maybe getting used like 50% of the way that's intended.

So I'm curious also how much iterating on process is part of your process.

Roy: [00:20:03] Yeah. Yeah. I think, coming in, one of the things that I wanted to do was create early wins. You know, for example, the research ride alongs, the setup that I originally put in place was just like bare bones. Just get it out there. see if it is valuable, if it's being used and where we can improve.

So in that example, we did have folks jumping into calls. Luckily I got, someone who. Started to work part-time in research ops with me. So her full-time role is in recruiting, but she's really interested in research. So she came on board and spent a good part of a quarter, improving that process for research ride alongs, making sure that people were more aware of what's going on, improving our zaps that were set up for the research ride alongs and, helping with the training and that sort of thing. So a hundred percent is there's going to be times. I think it makes sense to jump in, create something like improving the process.

Even 20% is going to be a big factor, but there's also some parts of research ops where I think it makes sense to just do the hard digging and create something, not necessarily complex for complexity’s sake, but. If it's a big problem that requires something that's going to a solution.

That's going to take a while to build, just go build it for a while. as long as you understand what those problems are. So I think it's a, both and like early on, I'm definitely the pro like, have an early win, show something that is valuable, continue to iterate, but there will be times where it's like, just go build that or go find that really big tool because that in the end is going to be less work for you and more value for your team.

Erin: [00:21:55] Yeah. are there examples you can point to where there've been like these sort of big problems you knew were going to have, difficult solutions or expensive or they'd take a long time to ultimately build or, and are those transferable to other kinds of organizations, right? Like what kinds of things tend to fall into those buckets?

Roy: [00:22:12] For us one that stands out right now is knowledge management. I had mentioned when I joined Zapier one of the first things I thought about was knowledge management. but I think what we're seeing is knowledge management. It's huge. It's dicey, it's complex. it's tough. and so there is a world in which, in some contexts you go, Hey, we're going to throw everything in excel, or we're going to throw everything in an air table, just have it there because it's a log that's helpful.

In our context, we're thinking about the data side, so our decision science team, as well as the UX research team and other folks who do research, and it just feels as though, you know what one, we need to understand this a little bit better and it would make sense to spend more time on this and go out and either find some most likely find something.

I don't think we're going to build something. Most likely find something that works for us and our team. so that's one that for sure, is a big one. I don't think it necessarily means every team is going to have that, but, yeah, it's, there's definitely a level of complexity where. We already have a bit of a log of research that's going on.

So it doesn't really make sense to start small. We have an internal blog where people share their research findings. And that's good in terms of general knowledge management, but in terms of the needs for, say like a research repo of sorts, it's, it doesn't really work right. The searching and like tagging and that sort of stuff just doesn't exist as we would want it.

JH: [00:23:52] Do you have an example from the other category of something where you started small and got something out quickly and then evolved it over time?

Roy: [00:23:58] Yeah. I think our research ride alongs, those are great examples. And these actually applied in other settings where product managers were jumping on research calls and they wanted to bring in other members of their team where we built a super simple system, just with Calendly and Slack and zapier to make those events easily visible, really easy to join. We added a look back as an option for folks to use, for jumping into research sessions.

So that was very scrappy. Let's just use Zapier to create something that's going to be easy for our teams because everyone is using Slack. Everyone. You don't even have to use Zapier, we're building the zaps for you. and that was a really easy, quick win. We're seeing that there probably has to be a little bit of evolution. We have made some changes already. Like the person who came in part-time made some great changes to that process and made it a lot smoother.

And there's many opportunities like lots of opportunities to make that even better. I'm not quite sure we There's a solution out there for us, in terms of those ride alongs, but there's definitely room to make them better. yeah, that's a, one from the other side, but we started scrappy and trying to improve

Erin: [00:25:16] Roy. How long have you been in your role at Zapier?

Roy: [00:25:19] So I joined in January, yeah, almost a year now.

Erin: [00:25:22] So the best year of all time, you spent it in research ops.

Roy: [00:25:27] Well, 20, 20, I'm not sure. 2020 is going to go down as the best year of all time.

Erin: [00:25:31] Right, right, right. It's an interesting year to try to build scalable processes, but maybe a good one in that sense. And Daffy has been a remote company like forever. Is that right? So

Roy: [00:25:42] Yeah, remote, remote from the start. So it was, it was helpful. Yeah. Really helpful to already have the setup. We knew that we already did remote research. We also did field studies and had lots of field studies planned for this year. so obviously that. Didn't happen and probably won't happen in 2021, but it did help that we didn't have to make a giant shift in the way we work.

We've been remote from the start distributed from the start. So it was more a case of just continuing on with everything going on. Obviously it makes a bit of a difference to work, but not anywhere near the shift that companies who are co located we'd have to make.

Erin: [00:26:20] Yeah. And what surprised you in that time, since you have made this transition, you talked a little bit about. You know, this is not a great role, especially I imagine being UX research operations, employee one, right? Not a good role for someone who wants to just do what's familiar and not explore and find new solutions.

What is, what has surprised you, good or bad or anything?

Roy: [00:26:47] I think what, what surprised me the most is I thought I would come in and mostly work on problems. We were facing opportunities with the UX research team. So we have a team of researchers, And what's happened is okay. I actually spent the majority of my time thinking about, and working on problems and opportunities for folks who do research, but are not full-time researchers.

We have lots of PMs, lots of designers, a few marketers. A few engineers who do research sort of week in week out. I didn't account for the fact that it would be most valuable to work on resources and services and tools that are going to help those folks as opposed to.

Focusing full time on the UX research team. I think in 2021, I would definitely want to do a few more things focused on the research team. So it doesn't mean that I do nothing for that team, but I thought I'd be focusing like 80% of my time there. And it's a switch. It's 80% of my time focused on the rest of the company and helping them get to a good place.

And that's a bit of a, it's a bit of a result of the approach to research that we have. So our full-time researchers are not embedded within product teams. So we have them outside decoupled from those teams thinking about sort of really long-term questions and problems.

Like right now we're thinking about problems and opportunities for mid 20, 21 end of 2021 sort of deal. And so that leaves PMs and designers with a lot of research work to do themselves. And so they need quite a bit of support and help that's going to be different for other teams. And I think that's maybe the impression I had coming in was, let's focus more on the UXRs, but there has been a lot of need outside of the research team. So that has been very surprising, but in a good way, like it's not negative in any sense. It's part of realizing, okay, this is the context in which I work, and this is where I can add lots of value right now.

Erin: [00:29:09] So give us a sense of scale. How many full-time researchers do you have at Zapier? Like give or take.

Roy: [00:29:15] Yeah. So five, uh, in the UX research team. And then there's over 30 PMs and designers.

Erin: [00:29:26] So a lot more in the people who do research and are primarily doing it, it sounds like more evaluative research, whereas your researchers are doing more like discovery research is that kind of breakdown that way.

Roy: [00:29:38] I think the more evaluative research projects, just because of how those break down, over the course of product development, but PMs and designers also do their own discovery research.

Erin: [00:29:52] So they're doing a lot of, and is the kind of work that you're doing to help support those people who do research, who aren't researchers, are you teaching them how to do research like method work, or is it more, a level removed on the recruiting and the managing the knowledge or all of the above?

And I'm curious, cause I imagine this comes up with a lot of operations roles, right? Especially when we talk about democratization of research and everyone has a different kind of point of view on where the right place to be on that pendulum is, which is obviously a whole other conversation, but, supposing as an organization, we've decided we're okay with some level of democratization and it's not just going to be researchers who are doing research.

Yeah. I imagine the kinds of work you might focus on are pretty different. as far as who you're supporting.

Roy: [00:30:40] Yeah, I'd say all the above, but none of the same time. I think, Especially as a team of one, it seems like I'm going to be able to grow my team in the next few months, which is great. COVID initially dented that, just as we were being more cautious, but, as headcount grows, then you get more opportunities to work on different things.

But especially for coming in as the single person or you're a team of one, yeah, you're gonna have to tackle. All of the things. But my, one of the biggest things I learned is you probably want to tackle them one at a time because you're also fighting fires that just pop up every day.

The reality for PMs and designers and marketers and such is, you know, everyone comes in with a different lens on research, different level of experience. think of a designer who started off in a little startup, And decided I'm going to do research and, kudos to that designer for doing research.

They jumped in, they started doing interviews. Maybe they did some sort of testing. Maybe I did that for a few years. Then they come to Zapier and they get asked, Oh, what do you do? Yeah, I did research, but. But what if all their years of research they've been doing really flawed research, right? they feel very experienced, but when it comes down to having a researcher review their work, a researcher would say, You know, you're really at a, at a junior level when it comes to your research, they would feel like they're at a senior level because they've been doing research for many years.

On the other side of the equation, you may have to say a PM who. Got to enroll in a UX research course and they did it. And maybe they've only been doing research for a year and a half, but they follow the process. They're really conscientious about how to do user interviews and not being biased.

They may come in and look at that design and go, wow. They have four years of user research experience. They know more than me. it's not really the case. And so this is where the training comes in like an evaluation, figuring out, if we want to train people, what sort of resources make sense for.

This whole team, and also in light of what's going on with the product strategy, right? What are we building? How are we building it? Is the cadence of the shipping chain changing? Will that open up opportunities for designers to do more discovery? So should we focus more on the interview side of things?

So this is where. One, that piece of everyone comes in with different experience levels. So someone who says they have experience in research, that can mean something very different to them and to you. and then figuring out what's going on in the company. So what I say about doing all these things like that, these are the factors that come into play.

Because I think in order for a research operations person to create value. They're gonna eventually have to tackle all of these pieces, in some way.

JH: [00:33:47] Yeah. It's what I want to explore, I guess, is I think a standard question of somebody who's considering a new role, When they're interviewing to ask the interviewer is. What does a typical day look like? and obviously there's not usually a typical day, but given everything you just described, what are some of the typical tasks or recurring things that you're doing in this research ops role?

Can you maybe just give a sample on that regard?

Roy: [00:34:10] Yeah. Yeah. I'll walk you through, I try and have standard days, but, uh, that obviously changes depending on what's going on. so the way I structure my day is the first half of my day. Is really focused in, on whatever my big project of the quarter would be. one thing that I've been working on that I've made a slight shift for Q4, but see, one piece of this has something I'm calling air traffic control, which is like a really getting a better sense of What's all the research going on across the company, because not everyone follows the same process and not everyone is really tracking what's happening.

So that's a big piece for me to, to figure out. And so the first half of my day is built around, making progress on that project. and then. The last half of my day, I structured it around just, interacting with folks. So people get in touch with me over Slack and go, Hey, Roy, I'm doing this research and I'm not sure how to figure out recruiting for this.

Could you like give me a resource or jump on a call with me to help me think through this? So some of those will just be giving advice. Some of those will be on a call. Some of those will just be slacking, Hey, here's a resource for you to take a look at, have a read through. If you get stuck, just get back in touch with me.

Jumping on calls with our full-time UX researchers thinking about big plans they have and thinking through, okay, like what do we need to do now instead of later? So the second part of my day is like interactions, right? Almost like fighting fires in a sense. And, and chatting with people about, the needs.

They have another thing I do every week, because every week I speak to someone in engineering, product or design, like a continuous interview program where I always want to know. what's going on with these teams, how are they working? What are the problems you're having? So it's almost like a continuous research sort of thing.

So that's factored in. and any other meetings that I have, right? So one to ones or meeting up with design managers and that sort of thing. So broadly, the first part of my day is like heads down, project work. How can I make progress here? And then the second part. So like fighting fires, helping people and jumping into meetings to figure out how you can help.

Erin: [00:36:41] All right. Well, a question I like to end with, sometimes is especially, I think interesting for you transitioning from UX research to UX research ops, maybe we'll do a two part, which is, you know, what do you love most about the two different roles?

Roy: [00:36:57] You know, in UX research, especially my previous role, I was really fortunate to work on big problems. we've, re focusing on the right target customer or defining a new target customer. thinking about the jobs that. The previous company I worked at, which is Buffalo. It's a social media company, the jobs to be done for folks who are in social media management.

So the opportunity for me to work on those big projects and to see that work. Shifted the direction of the company, so gratifying, right? Like I think to be able to see that the work you have done, other people take that and value that and then make a decision on it. that just, just warms my heart and the really good memory.

But I think what I like about research operations is. It's yeah. You're like I said, that sort of an Explorer, right? Like you're just out with, it's you and your buggy and. You have to figure it out, right? is this the few people that are going to, look to and go, Oh, that's exactly how you did that.

All right. I'm just going to replicate that there's not many around. there's definitely people I can reach out to to get support and, chairman ideas, but it is this vast on, uncharted territory where. I get to do what I think should be done. and in a sense, it's like a lot of responsibility, but in us it's really exciting, right? I never really know what's going to happen in a few days or a few weeks.

Like I could get, early this year, I thought I was just researching research and it was like, Hey, we want to set up this. Research ride along program so that anyone across the company can jump on a research call a few times a week.

Okay, sure. Let's do it right. I have never, I've never done that before. And so now I can say I've done it. that's really cool to be able to just be in the unchartered territory and figure it out. I really like that.

Erin: [00:39:08] Fantastic.