Ops at scale: Lessons from Google
Scaling research at Google means juggling people, process, and product at a level few teams ever reach. It’s about building systems that keep thousands of decisions user-informed without slowing anyone down. At that scale, Research Ops isn’t background work. It’s the strategy that keeps everything moving.
At Gather & Grow in New York, we went behind the scenes with the team driving one of the biggest Research Ops programs on the planet. They shared what it really takes to move fast, stay compliant, and keep innovation on track.
👋 Sara Strouss, UX Research Program Manager at Google, has spent most of her career building the operational foundations for high-impact UX Research. From centralized repositories to democratization programs, she knows what it takes to help researchers move fast without breaking trust. Her current focus is operationalizing recruitment workflows and integrating Rally to empower research at scale.
👋 Marcel Schwarzberg, Head of Production and Ops at Google, is a Program Manager on the UX Infrastructure team focused on scalable systems that help teams make faster, user-informed decisions. She’s currently accelerating Google’s UX Research through an AI-powered Q&A agent and streamlining research ops workflows across teams.
If you weren’t able to join us live, or just want a refresh on the insights shared, keep reading or watch the recording.
Want more from Gather & Growth 2025? Check out our other panel recaps:
How did each of you end up working in Research Ops at Google, and what does scale look like there?
Sara: I’ve been in Research Operations for most of my career so far, working in smaller teams of about one to three people. In that kind of setup, you have to wear a lot of hats, which I’m sure many of you here have done at one point or another.
When this position opened up at Google, it was really exciting to have the opportunity to work with other program managers who have as much or even more experience than I do. But more importantly, it meant getting to focus on one specific part of the research operations bubble instead of constantly switching between things like legal, databases, and process building. It’s been great. I feel very lucky to work on a really awesome team.
Marcel: My story is a little different. I’m probably one of the newest members of the Research Operations team. I came over from marketing at Google and more recently moved into Research Ops.
Part of my role has been figuring out how to roll out Rally to our teams, how to communicate that change, and how to think about our processes from end to end. And to your question about scale, it really is global. There are researchers all over the world, and of course our Google users are everywhere too.
For us, it’s not only about Google’s end users but also about the UXRs who come to us for guidance, the research coordinators we support (who I’ll sometimes refer to as RCs) and the participants themselves. So there’s scale on multiple levels, and that’s always top of mind as we think about evolving and improving our processes.
What are the biggest challenges and inefficiencies you’re solving for?
Marcel: We’re always listening to our UXRs. They’re the ones on the ground doing the work. We can have as many processes as we want, but if they don’t work for them, it doesn’t matter.
What we were hearing was that things weren’t moving fast enough. And in a time when everything changes so rapidly, being able to move quickly with user insights is a real competitive advantage. The only way to do that is to make sure we can deliver research and insights fast.
“In a time when everything changes so rapidly, being able to move quickly with user insights is a real competitive advantage. The only way to do that is to make sure we can deliver research and insights fast.”
– Marcel Schwarzberg, Google
So for us, it’s all about finding efficiencies throughout the process and creating a consistent experience. Whether someone is recruiting internal Googlers or external participants, the scale is massive. When you think about how many different product areas we support, it’s huge.
We’re lucky that our team has been around for over 10 years. They’ve built a really strong foundation of compliance and governance, like we heard in earlier panels. Now it’s on us to make sure the framework still works for everyone, that it’s efficient, and that it can modernize as times change.
Sara: To keep Marcel’s house metaphor going, this team has been around for a decade, and as we’ve started moving into Rally, it exposed workflows that had been sitting untouched for years. That’s normal. You build something, move on to the next thing, and before you know it, some systems haven’t been revisited in a while.
So this past year, as we’ve transitioned to Rally, we’ve been critically rethinking what’s inefficient, what’s unnecessary, and what we can rebuild to make things better.
How do you get stakeholder buy-in for a transformation like this, especially when speed matters?
Marcel: People can be funny about change. I’ve really focused on simplifying the message. It’s easy to see the benefits of a tool like Rally, but people are used to doing things a certain way. So we try to meet teams where they are and clearly communicate what’s in it for them.
We show them how their day-to-day work will change, what’s going to be faster, and where we’re hiding complexity behind the scenes, whether that’s through automation or by having our RCs take on certain tasks.
Going to teams individually has been really helpful. We get to hear what’s unique about their needs and make sure they feel included in the process.
Sara: It’s funny because the goal is to create one consistent experience, but we also want teams to feel like we’re building something special for them.
“The goal is to create one consistent experience, but we also want teams to feel like we’re building something special for them.”
– Sara Strouss, Google
Part of it is showing how Rally directly addresses their feedback from existing processes. When people feel heard, they’re more open to change. It’s also been nice to anticipate their questions. For example, with scheduling, we were able to say, “Hey, that issue you had? We’ve already fixed it.” That kind of response builds trust and helps us get buy-in quickly.
Google supports very different organizations, like Fitbit, YouTube, and Google Cloud. How do you balance those competing needs and still build a unified experience?
Sara: It can definitely be tricky. A lot of it comes down to messaging, like Marcel said. Each product area has its own nuances, but at the end of the day, they all have the same core need: “I need participants. I don’t care how you get them, just help me talk to them.”
That’s actually been really reassuring. We also have an advantage because our team’s been around for a while, so most product areas already understand the basics of compliance and opt-in. They have to take training before they even work with us. Of course, we get unique requests too, things like custom branding or specific workflow tweaks, and Rally gives us more flexibility to think about how to accommodate those as we continue the rollout.
Marcel: We also highlight the value for our Research Coordinators and participants, not just UXRs. A lot of manual tasks are now automated, which saves time for RCs and makes their work smoother. And for participants, things like incentives now go out faster, and there’s less back and forth about payments. Those little pain points add up over time, so removing them makes a big difference.
What does the future of Research Ops at Google look like? And where does AI fit into that picture?
Sara: I’m really excited for next year. We’ve spent a lot of time getting things standardized and operationalized, and there will always be new challenges that pop up. But now we can start focusing on some of the shiny things we haven’t had time for yet, like panels, self-service recruitment, and getting participants to researchers faster and more efficiently.
“Moving to a new participant management tool gives us a more holistic view of everything instead of patchwork fixes across different systems. That means we can be more strategic and less reactive.”
– Marcel Schwarzberg, Google
Marcel: Moving to a new participant management tool gives us a more holistic view of everything instead of patchwork fixes across different systems. That means we can be more strategic and less reactive. We can start anticipating needs before they hit us and be ready when product areas come to us. And yes, AI is definitely part of that. We’re excited to experiment, but it’s really about prioritizing what has the biggest impact. There’s a long list of things we could do, so we’re focused on where it will make the most meaningful difference.
What are you most excited about for the future of Research Ops at Google?
Marcel: There’s a lot to be excited about. For me, it’s when the process works smoothly, and we’re getting close. Once everything runs cleanly, we can start thinking about how to make it even more self-service, more automatic, and more on-demand. I also want to keep solving what I call “paper cuts,” those small pain points that make a process feel heavier than it is. Things like integrating with Gmail and Calendar, small quality-of-life fixes that free people up to focus on the big stuff.
Sara: I’ll zoom out a bit. Speaking for the Research Ops discipline as a whole, I’m very curious where things are going with AI. I’ll admit, I get a little nervous when I see “AI participants,” but I also think it opens up space for us to lead. We can help teams figure out when to use different resources, what kind of participants are right for what kind of study, and where automation makes sense. That’s going to be a fascinating evolution.
How do you decide when to build tools in-house versus buy something external?
Sara: When we transitioned to Rally, we did a full build-versus-buy analysis. Of course, Google has the engineering talent to build, but it really came down to time and complexity.
Could we build something as nuanced as what we needed, at the speed we needed it? And would it actually make things faster? Rally met those needs, especially around governance and compliance, which were non-negotiables. Privacy, for both participants and researchers, was also top of mind.
And we’ve built a strong partnership with the Rally team. We share feedback from UXRs, see what’s coming on the roadmap, and get to collaborate directly. That’s been a huge advantage.
“Time is such a big factor. I’ve worked at places with in-house tools, and eventually, they become tech debt. You’re constantly lobbying for engineers to maintain them.”
– Marcel Schwarzberg, Google
Marcel: Time is such a big factor. I’ve worked at places with in-house tools, and eventually, they become tech debt. You’re constantly lobbying for engineers to maintain them. Working with a partner like Rally, whose entire focus is this space, has been really beneficial.
How do you make sure that people who self-serve or use your systems actually do good, compliant research?
Sara: That’s a very real concern. When people have access to insights, there’s always the risk they’ll look for what confirms what they already believe. But honestly, that can happen even without a repository.
Sometimes just saying it out loud helps, asking, “Are you using this data to support what you already think, or to understand what users actually need?” That small reminder can shift behavior.
“We focus on connecting those dots, helping teams find relevant past work while reminding them that older data might need refreshing.”
– Sara Strouss, Google
And at Google’s scale, there’s another side to it, duplication. Often someone has already done very similar research. So we focus on connecting those dots, helping teams find relevant past work while reminding them that older data might need refreshing.
Marcel: Exactly. We encourage people to use past research as a foundation, not a final answer. Data gets stale fast. You can use it to form a hypothesis, but you still need to validate it. That mindset is something we reinforce through training and guidance.
How do you prevent confirmation bias when teams use insights or repositories on their own?
Sara: We’re starting to democratize research and build a repository, and it’s super exciting, but I totally get that fear of someone looking at user insights and just finding the confirmation bias in there, then running off with it. You’re not able to handhold and deliver insights the same way you’re used to.
From my experience at other companies, if someone wants access to participants, or even to use a repository, they have to take a training that covers basic biases and reminds them to keep those top of mind. That’s one layer of protection.
“If someone wants access to participants, or even to use a repository, they have to take a training that covers basic biases and reminds them to keep those top of mind. That’s one layer of protection.”
– Sara Strouss, Google
But honestly, it does make me nervous too, because there’s always that chance someone will take research and use it to fit their own narrative. The truth is, people already kind of do that, right? You can make data work however you want if you really try.
Sometimes it helps just to say that out loud to people: “Hey, just pause for a second. Does this actually reflect what users need, or is it just fitting your team’s goal for the quarter?” That moment of self-awareness really can make a difference.
And the flip side, especially at Google’s scale, is that there’s a high chance someone has already done something very similar. So part of our job is helping connect the dots. We can point teams to related projects or existing insights and say, “Hey, here’s something close to what you’re doing. Maybe review it and build from there.” We never want to bias people, but we also don’t want them duplicating effort. It’s really two sides of the same coin.
Marcel: We always encourage people to use past research as a starting point, not a final answer. Data can get stale quickly, so older insights should be used to form hypotheses, not to replace new research. That’s something we reinforce through our training and conversations with UXRs. It’s about balance. We want teams to move fast, but still question how they’re interpreting and applying what they find.
Running such a large operation, how do you enforce compliance when people might go rogue?
Sara: The idea is to build those compliance moments right into the process so people are checking themselves as they go.
For example, if someone is submitting a research request to our team, can we put the consent form or NDA or ICF right in that workflow so they have to engage with it? Can we make it a required step? Same thing with trainings, you can’t move forward unless you’ve taken them. That way, you know they’ve at least seen what the right process looks like.
Of course, there will always be the tricky cases where someone actively decides not to follow the guidance. And at that point, that’s kind of on them. We can do everything we can on the Research Ops side to set them up for success, but we can’t control every decision. Our goal is just to make it as easy as possible to do the right thing and as hard as possible to do the wrong thing.
Marcel: We always start from the assumption of positive intent. Most people want to do the right thing. We also have the advantage of legal partners across all of our product areas. If something feels off, we can flag it and point them to someone in legal who can help walk them through it.
“It’s not about being punitive, it’s about creating guardrails that protect both the researchers and the organization.”
– Marcel Schwarzberg, Google
And sometimes you do need that “hammer” role, the person who can say, “This isn’t compliant, and you can’t move forward.” It’s not about being punitive, it’s about creating guardrails that protect both the researchers and the organization.
At Google’s scale, how do you keep track of past research and avoid duplication?
Sara: It’s definitely something we think about a lot, especially given how much research happens across different product areas.
We have large repositories and dedicated research tooling teams that manage them. There are a lot of different pieces and elements that come together for that. It really depends on the product area and what they contribute. Some groups have deep, established systems, and others are still developing theirs.
I wouldn’t say we have one single, perfect answer, but part of our job is making sure teams know what resources exist and how to access them. Sometimes people just aren’t aware that a library or database already holds insights that could help them, so creating that visibility is a big part of what we do.
Marcel: There are certain guardrails in place around things like data freshness. For example, when I worked in marketing, we couldn’t use research that was more than six months old. If it was older than that, we had to refresh it before using it again.
You could still use that older work as a foundation, something to build hypotheses from, but you’d need to validate it with new research. That’s a mindset we try to reinforce with our teams.
“It’s really about using existing insights as a starting point, not an endpoint. You can reference them, learn from them, and then go test again.”
– Marcel Schwarzberg, Google
It’s really about using existing insights as a starting point, not an endpoint. You can reference them, learn from them, and then go test again. It saves time, reduces duplication, and makes sure the work stays current and relevant.
What role do training and ongoing communication play in keeping all of this running smoothly?
Sara: Training is huge. It really is the connective tissue for everything we do. We make sure new researchers and PMs know what’s expected of them, what compliance looks like, what bias means, and how to recruit responsibly. It’s not just about checking a box, it’s about helping people understand the “why” behind each step.
“Training is huge. It really is the connective tissue for everything we do. We make sure new researchers and PMs know what’s expected of them, what compliance looks like, what bias means, and how to recruit responsibly.”
– Sara Strouss, Google
We also refresh those materials often so they stay relevant. Teams change, tools evolve, and regulations shift, so the training has to evolve with all of that.
And honestly, sometimes the training is just a good excuse to have a conversation. It’s a way to remind people, “Hey, this is why we do things this way,” and get them thinking more critically about their own approach. It keeps the culture of good research alive instead of letting it become a set of static rules.
Marcel: Transparency and repetition really help too. When people can clearly see what’s required of them, they’re far more likely to follow it. The more consistently we communicate the “why” behind our processes, the less it feels like red tape and the more it feels like part of doing great research. At the end of the day, most people want to do things the right way. If we make it easy to understand, keep it visible, and reinforce it regularly, compliance becomes second nature instead of something people have to remember to do.
Any final advice for teams trying to scale Research Ops responsibly?
Sara: Be patient with transformation. It’s definitely not a quick process.
We’ve spent the past year transitioning to Rally and reworking systems that have been in place for a decade or more. That kind of change takes time and a lot of patience, but it’s absolutely worth it. Once the foundation is solid, everything else gets faster and easier. I think that’s one of the biggest lessons from this past year: You can’t rush transformation. You have to take the time to get it right, to bring people along, and to make sure the systems you’re building are actually going to last.
“Research Ops is a living system. It has to grow and evolve alongside the people, the research, and the products it supports.”
– Marcel Schwarzberg, Google
Marcel: It’s really important to build with flexibility in mind. What works today might not work a year from now, because tools, regulations, and even org structures are constantly evolving. If you build your systems to be too rigid, they’ll break as soon as things change.
Keep things modular. Listen to your researchers, because they’re the ones who see what’s working and what’s not every day. And be ready to adapt as you go. Research Ops is a living system. It has to grow and evolve alongside the people, the research, and the products it supports.
💜 Thank you, Sara and Marcel, for pulling back the curtain on what it really takes to scale responsibly at Google.
When systems work, teams can move fast, stay compliant, and focus on what matters most: learning from real users.