Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

In 2011, venture capitalist Marc Andreessen published an essay in The Wall Street Journal (and later on his blog)1 that opened with a prophetic line: “Software is eating the world.” Andreessen was right: software did “eat the world.” Amazon became the largest global bookseller (and marketplace); Spotify took a bite out of record labels; and Netflix devoured video stores and cinemas. As Andreessen wrote at the time, software programming tools and internet services made it “easy to launch new global software-powered start-ups in many industries—without the need to invest in new infrastructure and train new employees.” Replace “software” or “internet” with “AI,” and his statement is almost just as true now. Over the past fifteen years, software companies have transformed entire industries, the global economy, and your life and mine—as too will AI.

A few weeks ago, I sat down with Oren Friedman, the cofounder and CEO of Rally, to talk about how these economic and technological shifts are impacting research and ResearchOps, and how Rally is responding. We spoke about AI, of course, and the vision of a platform- or UI-agnostic future. But we also discussed how, just as technological advancements are making physical resources like rare earth minerals, oil, and gas more valuable2—worth fighting for, even—the ability to build human systems, and the soft skills required to build them, are becoming more valuable, too.

Soft Skills as Hidden Assets

“I don’t even know what else to talk about because it seems that the only thing that’s important right now is figuring this stuff out: stakeholder management, change management, relationship building, and the ability to sell the value of research,” said Oren during our conversation. “Every discipline is dealing with it, but I think it’s just extra potent for research professionals because of all the years spent trying to build people’s understanding of the value of research. And I do think it still comes down to soft skills. We’ve been talking about stakeholder management for years, but it’s never been more important than now to know how to talk to design, product, and other leaders and how to get in front of them.”

If you’ve worked in research for any length of time, you’ll know the ongoing challenge of encouraging colleagues from other disciplines to appreciate the value of research—or more pointedly, the value of good research…and, more recently, the value of researchers doing research at all. Most organisations are sold on the idea of including research in the product development lifecycle, and they’re investing in the operations required to make that happen, albeit through democratisation efforts.3 If you’re a research leader, the key challenge now is to upsell the importance of research quality to the same audience, which should, in turn, resolve the assumption that all research can and should be done by non-specialists and that researchers and their operational counterparts are pedantic bottlenecks.

During our conversation, Oren stressed that this stakeholder dynamic isn’t unimportant to research technology companies, like Rally: “Top of mind for us is how we can help equip research professionals to better manage these relationships so they can appeal to product, design, and other teams,” he said. “Research professionals, including ResearchOps, are coming from a position of knowledge, strength, and credibility, so how do we help reframe this subservient, hierarchical structure that’s happened within so many companies?”

Part of the solution is empathy and meeting stakeholders where they are; a core product principle at Rally. Oren spends a lot of time talking to product managers (PMs) and shared this observation: “A lot of the work people are trying to do, that PMs are trying to do, they may not even call it ‘research.’ They may not think of it in the context of a study the way a researcher would. And so, even with the basic primitives that researchers use, it can be easy to gloss over PMs who just aren’t thinking about research that way. They’re using different terminology, methods, or frameworks to reach their goal of making good decisions. They might call research ‘continuous discovery’ or ‘talking to a customer,’ for instance.”

The concept of meeting people where they are came up several times in my conversation with Oren, not only because it’s a Rally product principle, but because shifts in the product landscape mean that research professionals are being obliged (forced seemed too aggressive a word, but it’s not inaccurate), to build how research operates around stakeholders’ language and workflows—a user-centric approach, ironically.

Democratisation Is Now a Directive

Four years ago, research democratisation was a strategic choice for research leaders. In most companies, now focused on efficiency and profit, it’s a directive. Every week or two, I hear a story about a company that has laid off all or most of its research team while retaining its ResearchOps capability, tasked with democratising research across the entire company. Oren has seen this dynamic first-hand: “Just a few weeks ago, a company we work with laid off the entire research team but kept the ResearchOps team. It’s as if research and ResearchOps now have to redefine and re-articulate their value to the product team, even though a light democratization program has already been in place. Now it’s like their whole job rides on the democratization program working—and working well.”

Rather than resist the change, many savvy research leaders are leveraging the value organisations now place on well-designed research operations (used to build scaled-up research democratisation programmes) to gain the buy-in required to build better relationships with stakeholders and, eventually, to rebuild their research team. As part of this tactic, these leaders are becoming operations specialists in their own right, in line with an interesting trend in the research professional landscape. One in which researchers are doing research operations; ResearchOps specialists are being asked to lead and sometimes do research; and both are being tasked with enabling everyone else to do research. No doubt, the world is topsy-turvy. But when these savvy leaders do start hiring, they hire specialised researchers to deliver high-quality, high-priority insights to the most important parts of the organisation, hinting at an optimistic future for their operations-forward research teams.

Optimism aside, for many, the transition isn’t easy. Oren shared, “I’m noticing it’s a really hard bridge to cross for research and ResearchOps teams who, for the first time, are supporting people who are less in tune with a healthy research process.”

A Healthy Research Process

That healthy research process is key, particularly when there are fewer or no researchers involved to model good research practice. ResearchOps can do some of this work, but researchers are needed for research strategy and craft advocacy. This is truer still because AI is making knowledge or insight generation seem effortless, speedy, and requiring little skill. “The tempting thing for product teams is to try to find the fastest route to whatever insight they’re trying to capture.” Oren’s deep in the weeds of this democratization shift. “But that’s a fundamentally flawed way of approaching it because if there’s no rigour or guardrails, the quality of the insights deteriorates, then the quality of decision making deteriorates, and what does that point back to? It always points back to research, which degrades the value of research and the understanding of it within the company.”

The research profession has always been aware of the importance of pacing—slowing people down in an increasingly fast-paced world to observe, learn, question, and absorb knowledge is the ongoing operational challenge—but demonstrating the value of pausing to a sceptical product leader in the middle of a cost-cutting cycle, with access to AI, is another matter altogether.

The knee-jerk reaction is often to insert more operational guardrails and standards, but when people feel forced to work in ways that seem onerous, they tend to rebel. As Oren put it, “Research or ResearchOps might be worried that PMs are just going to log into Gong, for example, search through all the insights, reach out to customers, not obtain consent, not log anything, not send incentives, not put the data in any central repository, and so on. But for each PM, designer, or engineer, that’s the easiest path. They aren’t incentivised to think in systems; they’re incentivised to think about the fastest way to get their own job done.”

Finding the Right Balance

This push-and-pull of seemingly opposing forces—control versus convenience—has been a key challenge for research professionals for years, but solving it is more critical than ever. In a world where anyone can chat their way to an insights summary, search a call library, or vibe-code a workaround, a heavy-handed (if correct) research process is easier than ever to ignore.

“It’s this yin-yang concept of convenience: PMs and other folks want the ultimate convenience of being able to query something and go (that’s the yin).” Oren invokes the traditional Chinese symbol representing opposite yet interdependent forces. “And the other side (the yang) is control: to support good practice, ResearchOps wants to set controls in a way that enables both ultimate convenience and safe, responsible research.”

Oren says it as it is: “For too long, ResearchOps has indexed on control at the cost of convenience, and that’s what I think could lose them their jobs. Because if it’s overly controlling, then it’s like, ‘Move out of the way! I’m just going to go figure it out on my own.’ So, we’re trying to design a system that helps ResearchOps teams create these convenient experiences while retaining control. Yes, still simplifying the UI because UIs aren’t going anywhere quite yet for the non-researcher, but also starting to work towards a more agentic future where you don’t need to open a specific application to do something.”

That agentic future won’t only change how people interact with research platforms, but also how they engage with research operations: “I think gone are the days in the not-too-distant future of training people on how to use a new SaaS application that your company is adopting. Because no one has the patience or time to learn new workflows or tools, and they no longer need to. They want agents to do it all for them; to be the orchestrators of their work. So that’s the kind of vision we’re trying to work towards at Rally.”

“I-Me-Mine AI” Isn’t Enough

PMs, designers, and engineers aren’t the only people who aren’t thinking in systems. In a recent article for The ResearchOps Review,4 I wrote about the notion of “I-Me-Mine AI” and the urgent importance of research and ResearchOps professionals taking a step back from their individual use of AI to consider and design its place within their wider research system, before anyone else does.

Oren also sees the chasm between those two modes of working—individual AI use and systemic AI design—as a once-in-a-career opportunity and ticking time bomb: “The beauty is that AI now allows for quality, speed, and cost, all things that were trade-offs before. Of course, there are still trade-offs, but it’s never been easier than it is today to sacrifice less of those things, as long as things are done right. And product leaders do care about doing things right—just not if it bottlenecks progress.”

The need for mutual empathy across disciplines (again, those soft skills) is also key for Oren: “I recently spoke to a product leader who explained that AI is moving so fast that he doesn’t want to fall behind, and he doesn’t want his organisation to fall behind. So he’s doing a lot of research and investigation on the right infrastructure needed for the product team to stay ahead of the curve because they’re also worried about their jobs, and about engineers moving into their realm, and design—you know, the blending between research, design, product, and engineering…it’s very intense right now. It’s also a really exciting opportunity, but how do we get research and ResearchOps folk to the point where they can have that systems-level conversation with them?”

Research and ResearchOps professionals are well-positioned to have these conversations, but many are understandably overwhelmed by the state of the profession, the world in general (a fair reaction), the speed at which AI is developing, and the implications for their careers.

“We’re trying to encourage ResearchOps teams to lean in and become more literate with APIs5 and MCPs,”6 Oren noted. “ResearchOps professionals can help set up these systems, such as setting up the right consent forms and cool-down periods, hooking up the right integrations, and inserting the right legally approved communications throughout the entire experience. ResearchOps needs to play the role of the chief architect of scaled-up, AI-augmented research systems.”

Oren’s right, and the moment is now.

When the Interface Disappears

Just as the boundaries between roles are becoming less distinct and the shape of organisations is evolving at a dizzying pace (read Carolyn Morgan’s article, “A Practical Guide to Structuring ResearchOps Through Organizational Change”),7 the format of research platforms is changing at breakneck speed. Everywhere, CEOs and founders like Oren are working hard to keep up with the pace of change—not just to secure their own survival, but to ensure their customers can deliver the experiences their stakeholders feel they need to keep pace. “Stakeholders are already demanding a NotebookLM-like storage as an output of all research materials,” a ResearchOps professional shared in a recent exchange. For many people, their personal professional success depends on their ability to work faster, and they’re looking to colleagues in operational roles to provide the tools they need—now. As a result, ResearchOps professionals (including researchers delivering operations) are seeing their roadmaps, standard operating procedures, and purpose shift overnight from support, training, and administration to technical systems design. But they don’t have to make this shift alone; research platforms like Rally are also responding to the change.

“It’s a new experience we have to design for,” is how Oren sees it. “Basically, using MCPs, we’re trying to figure out how, through Claude or through Slack, you might run these actions without necessarily knowing what’s under the hood. Because I think that’s another one of these leaps that research and ResearchOps teams have to make. We’re thinking about AI a lot in the context of meeting teams where they are, and how they’re trying to design the future of their work, which is orchestrating different agents that interact with your organisational tools and giving ResearchOps the Ferrari on the back end—the engine on the back end—and they are the engine mechanics, making sure that things run smoothly when you get in the car and you don’t all of a sudden have a flat tire or no gas.”

The New Competitive Advantage Is Interoperability

Until recently, most research platforms were developed in isolation—it was rare for them to collaborate—but that’s starting to change. I asked Oren to discuss Rally’s perspective on building open research systems, that is, systems that can integrate with other systems, and their approach to partnerships.

“Well, I’m happy to talk about it because partnerships are a very important part of our strategy as a company. We’re building a best-in-class solution, not an all-in-one solution. Rally launched as a user research customer relationship management tool (CRM), but we’re evolving into a best-in-class research infrastructure. No matter what research you’re trying to do as an organization, you need the infrastructure underlying it to make sure that it’s efficient, safe, governed, and fast—all the value props that the different people in the company care about, whether it’s from product to legal.”

The suite of tools now available for research, both specialist and non-specialist, has exploded over the past ten years. I asked Oren how they choose the tools they integrate with. “As infrastructure, we’ve tried to be agnostic about the tools we connect to because one of our product principles is to meet our customers where they are. So, whether you’re using Qualtrics for surveys, Listen Labs for AI moderation, Zoom, Microsoft Teams, Copilot, Claude or whatever, to make research work, your tools need to talk to each other. If they don’t integrate nicely and play nicely, then you’ll spend your time reconciling two spreadsheets, which no one’s got the time for, especially these days. So, integrations have always been a really important part of our strategy. We’ve been trying to create partnerships for a while, and we’ve found that some companies are really leaning in like Marvin; they’re aligned with us philosophically as we’ve been able to collaborate on certain customer pain points that we wouldn’t be able to do if we didn’t collaborate.”

Being Human Matters

If there’s a through-line to all of this (AI, democratisation, MCPs, partnerships, and the shifting shape of product and UX teams), it’s that research and ResearchOps professionals are being drawn into a more architectural role. Research operations are now less about enforcement and more about building: creating the conditions for speed without sacrificing quality; designing “friendly guardrails” that demand perfection only where essential; and meeting teams where they are, whether that’s in Slack, Claude, Rally, or an interface that’s yet to be launched.

On the future of human-led research: “I don’t think we’re going to be moving away from solving human problems,” Oren said, “because I think there’s always going to be problems in the world that people will pay money to solve. And that’s where every product fills a certain space. So, if you believe that we’re not going to stop solving problems for humans, especially when things are moving fast and changing so much, there’s an even greater need for understanding people. If you’re going to win in this highly competitive world, you need to find those gaps in understanding and build a solution for them. And that’s what research is, whether you want to call it research or seeking understanding or learning or whatever, I think that’s not going to go away. I don’t see a world in which AI moderators are talking to AI participants, and everything is fully abstracted. Because then, what (and who) are we designing for? If there are no humans in the conversation at all, then it’s like we don’t exist. I don’t think we’re going to move into that type of world. I might be wrong. I do think there will always be a need for a better understanding of humans and solving new problems. Because I don’t think we’re going to ever solve every problem. And if we do, then it doesn’t matter anyway, because we’ll have unlocked unlimited money and resources, and no one will need to work ever again!”

In other words, even as the tooling and teams shift, and even as “research” is renamed, remixed, and increasingly mediated by machines, the crux of research remains stubbornly (and gloriously) human: to reduce the risk of building the wrong thing, for the wrong people, for the wrong reasons—and to build beautiful things, ideally.

A final word from Oren: “I would like to see the industry and the profession championing that you don’t have to sacrifice quality for speed, that it’s possible to meet the timelines and needs of the organisation, to be user-centric, and to do so with a high bar, just like all these other disciplines are being challenged to do. No one is putting rubbish designs out there because it’s faster. The bar is still really high for good design work. The same goes for marketing and other disciplines. So, if other disciplines can do it, research can do it, too. And don’t give up on that because you’re the only ones championing it. No one else is going to fly that flag. And it’s important. It matters. It may not seem like it matters today because people are getting laid off left and right, but it almost has less to do with you as individuals—it’s a market correction, I think, in the context of an overinflated tech sector. As a research or ResearchOps leader, you’re getting the short end of the stick, but don’t lose faith in your skills and your inherent value.”

Sponsor and Credits

Rally sponsored the first year of The ResearchOps Review, when it was just an idea, making the dream of a dedicated professional publication focused on ResearchOps a reality. Thank you, Oren and the Rally team.

Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

Everything about reorganizations and layoffs is messy. They aren’t just “challenging” or “complex,” they’re the kind of messy where you’re in a meeting or workshop, trying to figure out reporting structures and teams while people are worried about losing their relevance or their jobs, or what their future role will be. It’s the type of messy where you have a handful of options on the table, and no obvious choice. It’s the type of messy where every decision will leave someone disappointed.

In the last four years, I’ve navigated two major restructurings and three rounds of layoffs at the same company. I’ve worked as a ResearchOps specialist in a distributed team in a decentralized model; led a ResearchOps team in a centralized research organization leaning heavily on hybrid practices; and I’m currently leading research operations as part of a decentralized organization with centralized operations. If you’re having trouble keeping track of all those organizational structures, you’re not alone.

In my experience, there’s no perfect organizational structure. There are as many permutations of how research and ResearchOps teams can be organized as there are research and ResearchOps teams. Reorganizations happen at multiple levels—business-wide, within organizations, or within specific teams—and they all affect each other in ways that aren’t immediately obvious.

In this article, I’ll share the patterns I’ve seen, the traps to avoid, and the questions to ask when you face your next reorg. Because one thing is true: change is the only constant.

Shifting Tides in Organizational Models

There’s something almost contagious about organizational design trends. One year, everyone’s decentralizing; the next year, centralization is the gold standard; then hybrid models promise to solve everyone’s woes. Organizations lurch from one structure to another, and researchers, designers, and ResearchOps professionals must hold on tight and go along for the ride. It feels chaotic because it is.

But here’s the thing: when companies reorganize, someone has to figure out how each separate team, and all the teams together, will function. That’s organizational design, and when structures change, your research, design, or ResearchOps model must change, too.

When I’ve needed to reconsider the structure of my team in the past, I’ve asked myself several questions:

• Should I centralize or decentralize operations, or opt for a hybrid of the two?

• What role does my team play in these scenarios?

• What makes the most sense for the business?

• How do I best align my teams’ work to the business’s needs?

These decisions are never made in a vacuum; they’re usually accompanied by endless possibilities of team structures, changes in business direction, changes in personnel count, and many other variables. The first time I faced a reorg, I searched everywhere for guidance: I read design blogs and had countless anxiety-filled conversations with fellow managers across the industry about the what ifs and why nots of every permutation.

What became clear in my search for guidance is this: there are three predominant organizational structures (centralized, decentralized, and hybrid), plus four common operating models (solitary, specialized, distributed, and elevated) that define how a ResearchOps team might operate.

Decentralized: Embedded, but High-Context

A decentralized model is fragmented yet effective; one in which researchers are embedded in product and design teams (see Figure 1). In this setup, researchers can build deep product expertise and strong stakeholder relationships, enabling them to become true subject matter experts for that specific product and to understand its nuances, strategy, and users. And because they work side by side with designers and product managers (PMs), they’re regularly invited to meetings where they can influence decisions, resulting in more impactful research.

These are significant benefits, but there are downsides. Being embedded within product and design teams means that researchers aren’t working alongside other researchers day-to-day and risk becoming islands. Without some form of connection or communication with others in your craft, the upskilling and learning that tends to happen naturally when working with other researchers is often lost. In short, researchers might become experts in their product areas, but professional isolation and stagnation can set in.

One antidote is to create an informal network of researchers that replicates a research federation, such as via monthly meetups, “lunch and learn,” cross-team review sessions, or a common Slack or Microsoft Teams channel. Whatever mechanism you choose to use, the goal is to foster a sense of shared identity and connection that the organization’s structure doesn’t automatically provide. These sorts of efforts aren’t a panacea, but they can help combat the most common downsides of decentralization.

You might ask, “What is the best ResearchOps setup for a decentralized research organization?” The frustrating answer is: it depends.

In some cases, there are no ResearchOps specialists (see Figure 2, Teams 1 and 2). In that situation, designers and researchers must take over the operational tasks. Team 3 illustrates a scenario in which a single ResearchOps specialist supports all operational tasks. In Team 4, the small ResearchOps team is made up of specialists who focus on specific areas, such as participant recruitment, budget and tooling, research knowledge management, or other operations-related areas necessary for your team.

If there’s more than one ResearchOps specialist on a team, it’s worth evaluating whether to further specialize, leveraging the economies of scale that come with specialization. When people become experts at one thing, both wasted time and the effort of being a “jack-of-all-trades” are reduced, making the operations cheaper to deliver as you scale up.

Finally, the ResearchOps functions in Teams 5 and 6 are more complex because they support multiple teams in a decentralized model.

Throughout the article, I’ll dig into the questions and points to consider in each scenario.

Centralized: Consistent, but Distant

In a centralized mode, researchers are organized in a unified team that operates like an internal agency (see Figure 3). Researchers can be quickly deployed to tackle high-priority projects anywhere in the organization, while maintaining consistent standards and facilitating cross-team learning.

Because researchers work side by side and regularly talk to each other, they tend to maintain consistent methods, leading to more reliable and comparable insights. Researchers also typically find themselves in the same meetings, so knowledge sharing becomes natural.

Finally, from a leadership perspective, leaders can easily see what’s happening across the organization and allocate resources strategically, rather than reactively.

Those are all the upsides, but on the downside, a centralized model can often distance researchers from where product and development work is happening, disengaging them from day-to-day product conversations. And because they’re not involved in the daily work, they don’t tend to build the depth of expertise or the strength of stakeholder relationships that come from being embedded. Through lack of exposure, product teams rarely fully understand what the research team can offer, leading to further dissonance.

Finally, the research team may end up responding to requests on an ad hoc basis rather than shaping product strategy from the outset. Worse still, rather than supporting product teams, research might look like an impediment to good decision-making, or even be used as a reason for poor decision-making.

Here’s the reality: a centralized research model can create bottlenecks, giving product and design teams good reason to claim that researchers are slow and a blocker. Sometimes they’re right, but sometimes they’re wrong.

Fighting or trying to enlighten research detractors won’t help. What does help is transparent prioritization and decision-making about which study is supported, self-service tools that can be used by non-researchers to conduct simple studies, and strong ResearchOps handling of enablement-oriented processes and tasks, such as participant recruitment, so researchers can focus on research.

Even with all this, the “slow research” perception can prevail because a strong ResearchOps function tends to introduce process, and process can feel like bureaucracy. It’s in times like these that I remind myself that “slow is smooth and smooth is fast,” meaning that deliberate, controlled processes are faster and more effective than rushing, making mistakes, or building one-off solutions for every problem.

So what’s the best ResearchOps model for a centralized research team, you might ask? Frustratingly, the answer is: it depends. It depends on the team, the research team’s business objectives, and the personalities, skills, and specialties of the individuals on the research team.

But here’s what tends to be true: in a centralized model, the ResearchOps team’s model becomes more straightforward, especially if it reports directly to the research team. If you have a smaller centralized research team (usually fewer than ten people) and a ResearchOps team of one, your only option is for your ResearchOps team of one to be a generalist: someone who handles all of the elements of ResearchOps.

If you’re a ResearchOps manager and the research team you support transitions from a decentralized to a centralized model, you might choose to leverage economies of scale and centralize the ResearchOps practice so that each of your team members is able to develop an area of expertise rather than focus on everything.

If ResearchOps is embedded in decentralized research teams, rather than having five participant recruitment efforts, you might maintain one standardized recruitment process across all of the decentralized teams. This standardization and specialization opens up bandwidth for ResearchOps to focus on other research-supporting initiatives, the list of which can be endless.

Hybrid: Best of Both Worlds, but Complicated

A third operating model research teams might adopt is the hybrid model (see Figure 4). The hybrid approach is the corporate equivalent of having your cake and eating it, too. Researchers are embedded in product teams, gaining deep expertise and strong relationships, but remain part of a centralized research function, gaining craft development and cross-product learning.

It’s the best of both worlds, in theory. In practice, it can get complicated.

In a hybrid model, all researchers belong to a centralized research organization, but while some researchers are aligned to specific product teams, others work on cross-cutting problems. In other words, they focus on insights or problems that transcend specific product areas.

In this arrangement, all research teams report to a centralized “super-team,” so to speak, but each sub-team is aligned to its specific problem or product area. This promotes a strong research-centric culture (the feeling that everyone is working together in one large team) while supporting the specialization needed to focus on product areas and the ability to support cross-cutting initiatives.

This structure also creates flexibility: researchers can be temporarily pulled into cross-cutting initiatives that span multiple product areas, or the organization can shift the balance between embedded and centralized work as the business’s needs evolve, as shown in Figure 4.

There’s a lot of upside, but an unintended complication of the hybrid model can be dual reporting. You might end up with two bosses with potentially different priorities: a manager who manages you for the research stuff, and a manager who manages you for the product-centric stuff.

In this case, whose deadlines take priority? Who’s looking out for your professional and career development opportunities? If your leaders aren’t aligned on your work, managing your work becomes the work, and you’re frequently left stuck in the middle.

Overall, without strong coordination, the hybrid approach can result in processes and research standards becoming fragmented, leading to inconsistent quality and duplication. Leadership alignment can also be a struggle, with product and research leaders sometimes disagreeing on strategy or resource allocation.

While the hybrid model aims to capture the best of both centralized and embedded approaches, to avoid these pitfalls, you must encourage clear processes, strong communication practices, and well-coordinated leadership.

Patterns to Follow and Traps to Avoid in ResearchOps Operating Models

You’ve now got an overview of the models that research teams use to operate, but how do these impact how the ResearchOps team operates?

In her article, “DesignOps: 5 Common Team Structures” NN/G’s Kate Kaplan outlined four operating models for ResearchOps teams: solitary, specialized, distributed, and elevated. But which model is best, when?

Well, it depends on your size, structure, and what your team and research partners need most, and how they’re operating. But there are helpful patterns and traps to avoid (see Table 1). Keeping some quick decision-making criteria handy can help:

• If you have one ResearchOps person supporting a centralized research team, default to a solitary generalist model and protect time for the highest-friction operational work.

• If you have many embedded researchers across product areas with inconsistent practices, prioritize an elevated or specialized layer to standardize the essentials (recruitment, tooling, knowledge management), even if some support remains distributed.

• If the organization is hybrid and priorities shift week to week, plan for a mixed model and document decision rights (who owns what) to avoid double-reporting chaos becoming “the work.”

• If leaders are misaligned, treat alignment as a prerequisite: no operating model will hold if leadership incentives pull in opposite directions.

Solitary: Nimble, but Constrained

In smaller research organizations, say fewer than ten researchers, distributed or solitary models work best. The solitary model (a ResearchOps team of one) is the base model, defined by a single ResearchOps specialist covering the most pressing tasks.

A solitary model doesn’t typically suit larger organizations. In that case, a specialized or elevated model, in which a centralized operations team supports the whole organization, will give you the scale to actually make an impact.

In hybrid research organizations, you might need a mix of the four.

Specialized: Focused, but Conditional

In a specialized operating model, each operations team member is set up to focus on one activity, such as recruitment, tooling, knowledge management, or event planning (see Figure 5). This focus means that quality goes up across the board and there’s an economy of scale, but there’s a catch: you need enough team members to specialize to make this work, and if one of them leaves, you’re left with a major gap.

A simple solution is to institute a buddy system: pair a specialist with someone who knows the ropes (but isn’t an expert) who can fill in if the specialist is unavailable.

Distributed (In Hybrid Teams): Agile, but Siloed

In a distributed model, operations specialists are embedded within specific research teams as generalists (they may handle everything from knowledge management to participant recruitment), enabling them to build deep relationships and gain an intimate understanding of their team’s context (see Figure 6).

On the plus side, these teams are agile, responsive, and can handle whatever comes up. But this model can also create silos because what one team learns doesn’t naturally spread to other teams. Processes can also be unintentionally duplicated, and as a generalist, you might not have the depth to tackle complex operational challenges on your own.

Connection and community among operations specialists can promote cross-collaboration and learning, addressing duplication and knowledge gaps, so keep this in mind if you take this route.

Elevated (In Hybrid Teams): Broad Impact, but Unintegrated

An elevated model enables the ResearchOps function to sit at the organization level, supporting all teams equally (see Figure 7). This model can help build programs with broad impact, maintain standards, and allocate resources strategically, but it’s also harder for team members to know what’s happening on the ground because they aren’t involved in daily conversations with the research team.

As a result, the ResearchOps team can be slower to respond, and sometimes solutions won’t fit every research team’s needs.

Seven Principles for Navigating a Reorganization

This article may have proven that organizational design is mind-bending and complicated. Even so, the frameworks set out above should help you navigate your next reorganization with more clarity and, hopefully, grace.

I’ve learned a lot from living through several reorganizations involving the models I referenced, and I’ve compiled a list of principles for navigating reorgs—principles I wish I’d known earlier:

• Your leaders must be aligned. If your research leaders and ResearchOps leaders have fundamentally different philosophies, in particular about the role of research, you’re in trouble. That misalignment causes friction, mistrust, and makes effective operations impossible. Make it your top priority to mend, or at the very least to acknowledge, the misalignment before you do anything else.

• ResearchOps is service design. You should constantly and continuously analyze needs, build frameworks, and recognize that today’s solution becomes tomorrow’s bottleneck, and nothing is permanent. Make sure you and your team are well-trained in the craft.

• Centralized operations provides stability. Even when research teams decentralize, a centralized ResearchOps function can provide much-needed stability and consistency in managing tools, maintaining compliance, and coordinating cross-team initiatives.

• A proactive posture wins out over a reactive posture. If you’re stuck in reactive mode (constantly “hamster wheeling” to put out fires), make a concerted effort to shift into a proactive, strategic building mode. It’s essential for long-term success—and peace of mind.

• Community and connection matter. Fostering a community of practice is vital for knowledge sharing, mutual support, and maintaining cohesion. In short, find ways to bring people together.

• Standardization enables scale; customization enables quality. Standardization provides the bedrock of scalable operations, enabling consistency and automation. However, customization addresses specific needs at specific times. Generally, low-volume activities can sustain high variety, while high-volume activities require low variety to remain manageable and repeatable.

• “Slow is smooth. Smooth is fast.” Aim to create a predictable cadence of work that relies on accuracy, consistency, and steadiness. This is key to success.

Too Important Not to Share

This article was hard to write—harder than writing my dissertation on immigrant minorities, xenophobia, and hate crimes. I think that’s because writing about reorganizations and layoffs means that I have to write about decisions that affected real people, including people who are my friends and people with whom I still work. It also means being honest about what didn’t work without burning bridges and sharing, in the open, what would usually be communicated only via an industry-wide whisper network. But we need to talk about this openly.

An industry colleague once told me that they loved reorgs because it gave them the chance to see what they could get away with. They are truly stressful, but each one forces you to reevaluate what’s working, what’s not working, and how to build more resilient systems. What doesn’t work is not talking about what we are all experiencing during these changeable times. To learn what does and doesn’t work, we need to talk openly and courageously about what does and doesn’t work. I hope this article encourages and continues the conversation.

Disclaimer: The opinions expressed are the author’s own and don’t represent those of their employer.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

In 2023, Jakob Nielsen published a series of articles urging UX professionals to embrace AI urgently or risk professional obsolescence: “either you’re the windshield, or you’re the bug,” he wrote.1 That’s to say, if AI were a high-speed car, a windshield would master it; a bug would be squashed by it. “It’s not AI that will snatch your job,” he wrote, “but the individual leveraging AI to outpace your performance.” Three years later, Nielsen’s articles are remarkably prescient.

AI is fundamentally changing how research operates (to be accurate, how everything operates), and with it, the research capabilities and responsibilities of everyone in its orbit. Researchers intent on being the windshield are leveraging AI to do more than simply alleviate logistics or speed up the doing of research (the past purpose of research operations) they’re also using AI to expand, or augment, their purpose: in the midst of doing research, they’re drafting product briefs, building lightweight prototypes, writing on-brand copy, and even making incremental product changes.2

In an article published in March 2025, the NN/Group offered that “AI is broadening the scope of what any individual can accomplish, regardless of their specific expertise.”3 (See Figure 1.0.) The notion of “experience designers” who, with the help of AI, can cover everything from content strategy to service design and research to frontend development is on the rise. AI is prompting entire specialisms to become democratised. (At this point, the idea that research leaders might choose whether research is democratised or not feels almost quaint!)

From Individual Expertise to Shared Systems

It might be an easy assumption that this “expanded-T” trajectory will further isolate disciplines or lead to an extinction event, wiping out entire specialisms.4 If everyone can do everything on their own—or rather, with an LLM or team of skills (the Claude kind), or agents in tow—then why have all these specialisms, and why work together?

In reality, the opposite is true. AI is currently only capable of delivering value (more on this later) when humans use AI to augment their own specialist intelligence and skills. To achieve these augmentative “wins,”5 teams working across the product development lifecycle (PDLC) must collaborate to build and train common-use AI agents, establish templates, and design workflows that enable non-specialists to independently deliver parts of their job with the help of AI. But systems are as much about control as they are about enablement, and it’s the system owner who tends to set the controls. So teams must also collaborate to establish guardrails, set standards, and formulate risk profiles for the parts of their jobs that should not be democratised or handled by, or via, AI.

The word “must” features twice in the above paragraph, which begs the question: Why must we do any of this work? Because democratisation is no longer a choice.

The research profession has been grappling with democratisation for more than half a decade, the implementation of which has usually meant providing resources and support to whoever wanted to do research; an egalitarian approach that rarely delivers return on investment to the organisation. But the accelerative, magnifying effect of AI has made the design of priority-and-risk-based research systems urgent. Never mind poorly facilitated user interviews; it’s no longer science fiction that a program manager or an engineer might deliver an advanced quantitative research study, replace customers with synthetic personas, or launch dozens of AI-moderated interviews overnight. Research teams must set standards and create workflows for when and how AI should, and should not, be used.

It would be compelling to assume that ResearchOps professionals—practitioners in a profession that emerged precisely to handle these systems and governance tasks—are currently consumed with designing well-articulated AI-augmented research operations. Plot twist: that’s not the case.

Every week, I engage with dozens of ResearchOps professionals as the editor-in-chief of this publication and as an advisor and educator, giving me an elevated perspective on what ResearchOps professionals are thinking about—and sometimes what’s on their roadmaps. Earlier this year, I ran a workshop with thirty ResearchOps professionals from across industries to explore what was on their 2026 roadmaps. Attendees collectively shared 170 tasks; remarkably, only twenty-nine were AI-related. That’s just 17 percent.

ResearchOps professionals aren’t innovating or augmenting operating models at speed behind closed doors, bereft of time to share their learnings. Instead, for a variety of systemic reasons, they’re late to the party—the most important party yet—and researchers are taking the lead. That researchers are taking the lead isn’t the issue. The greater concern is that neither researchers nor ResearchOps professionals are paying attention to the systems- or organisation-level design of AI-augmented research, which is problematic (extinction-level problematic) for several reasons.

The Hidden Cost of “I-Me-Mine AI”

There are four clear camps in the AI research space. Those who don’t want to use AI at all are in camp one, but public discourse indicates this group is shrinking. In camp two are those who are interested in AI but are too time-poor, energy-poor, or overwhelmed to take the leap. In camp three are those using AI to speed up or lighten the load of their own work (I call this “I-Me-Mine AI” to play off the title and lyrics of a Beatles song).6 Finally, in camp four is an alarmingly small cohort setting collective standards or leveraging AI at the operating system level.

To go back to Nielsen’s quote from 2023: “It’s not AI that will snatch your job, but the individual leveraging AI to outpace your performance.” Three years later, in an agentic age, I would argue that it’s not AI that will snatch your job, but the team, the discipline, or, more pointedly, the operating system that’s leveraging AI to outpace your performance.

Because UX roles are becoming less specialised, your individual value (the value that might win you a promotion) depends on whether you can do that “expanded-T” set of jobs or “jobs to be done”7 (JTBD) well. However, the past few years have taught too many people that individual value isn’t enough to protect your role. For your job to be secure, your discipline’s organisational value (the executive-level value that keeps your discipline employed) depends on how effectively you and your team can enable others to do parts of your job, all of which hinges on the design and delivery of scalable operating systems. This phenomenon is far from brand-new—it’s been defining research teams over the past half-decade via democratisation—but as mentioned earlier, AI is amplifying and magnifying the dynamics, and the opportunity.

An Operational Imperative

Unlike the generalisation of UX roles, which has largely been prompted by artificial intelligence (pun intended), the recent shift in how corporations operate is perpetuating an evolution in research operations: the JTBD and the role, too.8 “The great fiscal reset” that has characterised the lives of tech workers since 2022 has led to the destruction of many research teams in favour of skeleton-crew research operations functions tasked with democratising research.9 To go back to NN/G’s “expanded-T:” just as UX roles are conflating, in many organisations, the line between research and research operations is blurring, too. Every week, a researcher messages me to let me know they’re now doing research operations, or a ResearchOps professional lets me know they’re working solo—that’s to say, without the partnership of a research leader.

The growth trajectory of research teams is in the process of being flipped, a point that is highly relevant in an AI-augmented, profit-oriented world: where research leaders once built a team of user researchers, then constructed an operations function beneath them, ResearchOps professionals (or research professionals who have absorbed operational responsibility) are now building operations programs focused on democratisation, then making the case for research headcount on the strength of the scaled-up value they’re delivering. In many cases, democratisation is no longer a research leader’s choice—if they’re there to make the choice at all—but an operational imperative. The message from corporations is this: we want you to deliver systems that empower a spartan, generalist workforce, then we’ll invest in specialists where they’re most valuably employed.

This is precisely where ResearchOps should be stepping in—or where researchers now working operationally should focus their efforts. ResearchOps exists explicitly to build and maintain the infrastructure that makes accessing research insights (not just doing research) possible at large, and even super-large scales. In an AI-accelerated research environment, that work hasn’t become less important; it’s become urgent, not only because organised is nicer than disorganised, or orchestrated is more efficient than not, but because this is an unprecedented opportunity for research and ResearchOps professionals to secure a high-power seat at a table that’s desperate for trustworthy knowledge, and desperate to make the most of AI.

From Individual Efficiency to Organisational Impact

A 2025 PwC survey found that 56 percent of CEOs reported their companies were not yet seeing financial returns from AI investments.10 Writing in the Harvard Business Review in February 2026, Prabhakant Sinha, Arun Shastri, and Sally Lorimer concluded: “In most organisations, digital underperformance isn’t a failure of change management, but a mismatch between new ways of working and old organisational designs.”11 Though few ResearchOps professionals are delivering AI-augmented workflows, whether new or based on existing ones, there are pockets (a vague designation, I’ll admit; the number is currently unquantifiable) of researchers delivering AI-augmented research operations. An excellent, publicised example comes from the DoorDash research team. Their articles “Researchers Are Rewriting the Playbook with AI” and “How Cursor & Claude Code Are Changing Research at DoorDash and Deliveroo” are essential reading, in which they share how the company is systematically building AI-augmented research operations from the ground up. Indeed, the articles give the impression that the entire organisation is on the same trajectory, which tends to help with innovation.

DoorDash’s forward-thinking approach is inspiring because AI-in-research content is predominantly self-focused: I-Me-Mine AI (researchers using AI to augment their personal efficiency) is the dominant “operating model,” with little, if any, conversation dedicated to continuity across individuals or research teams, let alone the wider organisation. This is problematic because corporations don’t invest in or maintain teams simply because the individuals working in them are more efficient or happy; an unfortunate fact. If the research profession’s I-Me-Mine approach to AI doesn’t change, it will be a case of history repeating itself.

When ResearchOps first became widely recognised as a profession, circa 2018, research leaders were making a strategic misstep: typically, people were hired into ResearchOps roles to help make research (in effect, researchers) more effective and efficient. Rather than being tasked with delivering value to the organisation, their work tended to focus on, for instance, unburdening researchers of the task of participant recruitment by assuming the duty altogether, building a library to enable secondary research, or handling the undesirable work of procurement and vendor management. It’s not to say that no value was delivered, but did the corporation earn more money because their researchers were better prepared, enjoyed their work more, and were more focused on delivering research? In most cases, the answer is no.

The Clock is Ticking

To return to the Harvard Business Review article, consider this observation related to commercial AI efforts: “Repeatedly, executives tell us that digital initiatives fall short of expectations: improving execution but not strategy, increasing efficiency but without freeing capacity for higher-value work, showing strong adoption but limited business impact, and creating disconnected solutions that don’t fit with existing workflows.”

From the corporate perspective, the value of AI doesn’t lie in what individuals can do to augment their own workflows, for themselves—useful for building initial ideas and confidence, but a narcissistic and limiting approach if it becomes the status quo. I-Me-Mine AI might enable an individual researcher to save hours on analysis and synthesis, or reclaim time for more strategic thinking. But unless AI experimentation and adoption deliver tangible, cross-functional efficiencies to the organisation (an operations-level boon that’s obvious to a CEO), the research profession—and especially the ResearchOps profession—will have missed the moment. And what a moment it is.

AI is, without doubt, going to revolutionise how research is conducted and consumed across organisations, with or without researchers or ResearchOps in charge. One needn’t be Nostradamus to make that prediction! AI is powerful and empowering enough that, if research professionals don’t get ahead of building scaled-up research systems and purposefully setting standards for how they and others in their organisation do, create, or consume AI-enabled research, someone else will—perhaps with less concern for methodology, rigour, and ethics. This is the immediate opportunity for research and ResearchOps professionals, and now is the time because the canvas won’t remain blank forever, habits and preferences will become embedded (and oh-so-much harder to change), and the opportunity to naturally lead the design of organisation-wide systems is finite. The clock is ticking. Some might say it’s a time bomb. (At this point, I must reference another musical classic, Rancid’s “Time Bomb.”)

You Already Have the Required Skills

Researchers paired with ResearchOps are better placed than most to deliver AI-augmented systems that are impactful organisation-wide and prized at the executive level. To do this, you’ll need to develop AI literacy, for sure (see Anthropic Academy), you’ll also need to reimagine the purpose of your role—it’s being reshaped around you anyway—and make new use of your specialist skills.

The following list will sound so familiar it might even seem trite, but that’s the point. To seize the moment, you must hone your inner:

1. Service or system designer. Take a step back and study the full ecosystem; don’t dive in with a limited view.

2. Researcher. Learn from individual researchers or people who are doing or consuming research to identify good and bad practices. How are people approaching AI? What’s worth repeating? What’s worth designing out?

3. Strategist. Pick the most value-adding and low-risk places to implement AI. Where does AI augment human intelligence and skill? Where does speed threaten rigour? Where is rigour most important?

4. Change manager. Gather the makers and innovators in your organisation into a working group or council to encourage collaboration and the development of shared systems and rules. Governance is always better when it’s developed by a group.

5. Communicator. Start talking about what’s working and what isn’t working. Find ways of sharing your learnings to bring others on the journey, establish the value of your work, and help others build on your learnings.

Above all, you must switch the conversation from “Where should I use AI in my workflow?” and “Which AI tools should I use?” to “Where should we use AI in our workflow?” and “Which AI tools should we use?” Through action, language, and politics, you must design the culture in which your AI-augmented research operations will live—and the future of research in your organisation.

The Conversation Is Yours to Lead

The breakdown of siloes and expansion of roles across UX signifies that shared technologies, standards, and cross-functional collaboration are more essential (and powerful) than ever, but someone has to lead the conversation. It might have been assumed that ResearchOps would lead it, but researchers are centre stage right now.

It’s excellent news that the conversation is happening, no matter the altitude and who’s leading it. But to summon Nielsen’s windshield-bug analogy one last time, when it comes to AI-augmented research, without a significant shift, the ResearchOps professions are collectively in danger of becoming the bug, no matter how good you are at prompt engineering. More importantly, the research profession as a whole is in danger of being passed by the power of the moment: a real chance to get ahead of everyone else in setting system- and operating-level standards, and the future agenda for research.

“I Me Mine” was the final new song recorded by The Beatles before their 1970 breakup. Written by George Harrison, it’s a commentary on the human ego and the tendency for humans, and perhaps AI (time will tell), to look after oneself. But change often requires just one person to think of the whole; to bring people together and design a mutually beneficial system.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

I started my career selling surgical cameras for keyhole surgery, then sold grand-piano-sized blood analysers that could process hundreds of samples a day for every blood parameter you could think of. For the last twenty years, I’ve worked in cardiac operating theatres in a part of the heart surgery world called electrophysiology, both as technical support during procedures and as a salesperson. Essentially, a day in the “office” for me involves collecting three-dimensional data of a patient’s heart mapped in real time (see Figure 1.0). During the procedure, we analyse the patient’s heart anatomy, tissue voltage (viability), and, most importantly, the direction of travel of the heart’s electrical current. Using this data, the physician performs small ablations, or burns, to intricately adjust the flow of electricity in the heart during fast heart arrhythmias. In short, if your heart occasionally beats faster than you would like, the people I work with can fix it.

At this point, you might be wondering why a sales guy who helps fix hearts is writing an article for The ResearchOps Review, and it’s a good question. Fifteen years ago, when I was selling one of these systems to the cardiac department of a hospital, I learned a primary lesson that helped me become an award-winning salesperson, not just a good one. When I started working with user experience professionals in 2024—a story for another time—I realised that the sales tactics that had worked so well for me in medical sales were equally valuable in helping research professionals show their impact and value, too.

In this article, you’ll learn why sales is not just for salespeople. I’ll share a simple approach for how you can articulate (and sell) the value you’ve delivered, or want to deliver, how to communicate your achievements so they land with your key audience, and how these tactics will help you turn stakeholders into champions.

Selling Isn’t Just About Transaction, It’s About Transformation

I have an excellent track record in medical sales: I sell US$200K hardware, large magnetic-based sensors, energy generators, and steerable catheters—all of which provide hundreds of thousands of dollars in ongoing sales revenue to my employer. To sell this system to the hospital, I need to convince the specialists involved that it’s the best choice; the purchase may also need to be approved by a committee of experts, and, finally, the annual operating costs must be signed off by the hospital’s finance department. This process can take six months or more (a timeline that will sound familiar to ResearchOps professionals) and must be completed with every hospital that plans to use our system. It’s no easy task!

Fifteen years ago, I’d successfully juggled all of these requirements and was ready to close a deal, but there was a perplexing problem. My own team didn’t share the same sense of priority for delivering quotes, bundling agreements, obtaining internal sign-off, and meeting with key stakeholders. This was a great deal for the company, so why weren’t my colleagues jumping on board? In this instance, timing was everything, so the deal was at risk. That’s when I realised the importance of in-house sales. I was taking my customers on a journey of increased success—I’d successfully sold the hospital staff the picture of increased profits due to shorter procedure times and a better reputation due to fewer complications—but I had completely ignored the job of selling the importance of the agreement to my own colleagues.

This is key for research and ResearchOps professionals because, as knowledge workers, your value is measured (frequently subjectively) by your stakeholders and colleagues. In a corporate environment, great ideas and excellent work without enthusiasm from a team or backing from stakeholders are as good as if they never happened at all. So if you don’t sell the value of your insights or your research systems, or effectively prove a successful track record, you’ll be fighting to achieve your full potential—and sometimes to keep your job.

It’s often assumed that sales is primarily about signing deals or convincing someone to buy something, and it is. But it goes beyond the transactional—it’s also about getting someone onboard, or, put differently, helping them see how the exchange will transform their impact, approach, success, and outcomes.

That moment when the penny dropped fifteen years ago, the hospital needed a custom agreement, but the typical turnaround for creating this type of agreement would have far exceeded the window available to close the deal. By writing an elevator pitch outlining the needs, features, and benefits tailored to our internal finance, legal, and management teams, I was able to start the process. As a result, I got the agreement approved in just one morning. Not only that, but everyone now understood why we required a non standard agreement, and because they played a special part in putting it together, became invested in the outcome of the sale. This sale made my work visible to many levels of management and gave me easier access the next time I needed something, all because I asked my colleagues for a favour in a way that brought them on the journey.

Research operations is an emerging role; few stakeholders fully understand its scope and purpose, and much of the work is infrastructural and can take time to show results. Plus, you’ll often require cross-functional collaboration to achieve your goal. The sales tactics I’ll share in this article are crucial to addressing these challenges and going beyond transaction. But if you’re a research, product, design, or marketing professional, read on, because you’ll be able to leverage these insights to get buy-in and boost your impact, too.

Sell Your Work In Thirty Seconds, or the Art of the Elevator Pitch

Imagine you’re at the office and you step into the elevator only to walk straight into your boss’s boss, someone who makes decisions about your role but doesn’t really understand what you do. Or perhaps you work remotely, and you find yourself on a call with an executive for thirty seconds before anyone else arrives, and they ask what you’re working on. After a five-storey elevator ride, or a remote scenario equivalent, would they walk away thinking that your team offered good value? Would they ask for a follow-up meeting to discuss allocating additional funding to support your work? Would you be able to succinctly articulate the crux (and value) of what you do?

I’ve run several workshops1 for research and ResearchOps professionals, and most people struggle to define their goals in a way that shows benefits not only from their perspective but also for the business’s leaders. Workshop participants are often caught off guard when they have to explain their work to a team that doesn’t understand the value of research or research operations—they even struggle to explain it to each other. This is a huge problem: if you, the person who is most up to date on the initiatives you’re working on, can’t articulate what you’re doing in a way that’s easily understood, how will your work ever be valued or understood by the busiest people in the organisation? Let alone getting your colleagues onboard.

Objections I’ve heard at this point range from: “but it’s my manager’s job to promote my work, not mine,” or “I send senior leaders a monthly report, which they should read,” to “they’re running the organisation, so it’s on them to keep up to date with what we do,” or “this initiative is important for the user experience or for ethical reasons, but they just don’t get what we do.” And maybe some (or most) of that is true, but the reality is, if you want your work to get noticed and be valued, it’s up to you to do the selling by communicating it in such a way that your voice is heard. For many people, it can feel daunting, but there’s a straightforward framework from the sales world that makes it much easier to do.

Crafting Your Elevator Pitch: Needs, Features, and Benefits

Imagine you’ve identified a need to simplify the consent process for research participants. The current consent form isn’t written in plain English (it’s ten pages of legalese) and isn’t available in multiple languages, which increases the dropout rate among carefully screened, hard-to-reach participants from enterprise companies, costing the organisation time and money. Perhaps the consent form also doesn’t meet accessibility requirements or comply with new regulations and standards, which, if not amended, could cost the company millions in data privacy fines or lead to the loss of government contracts. So, you make it a priority to update the consent process, which takes several months and a lot of your and the legal team’s time.

To get buy-in for this initiative, you set up a meeting with your manager and prepare a pitch, covering three critical components: needs, features, and benefits. Now, most people can articulate why something is needed (a problem to be fixed or an opportunity to benefit from) but few can articulate the features (how you’ll fix the problem or leverage the opportunity, and what the solution will do) and benefits (how your solution will generate revenue, save money, or manage risk for the company) in a way that appeals to the person they need to get buy-in from.

So, let’s take the need as previously outlined (updating the consent process)—that’s the obvious bit—and add the features and benefits.

• Needs. The current consent form is overly complicated, leading to a higher-than-average dropout rate amongst hard-to-reach enterprise participants. It also doesn’t cater to participants living with disabilities, slowing down accessibility research and putting government contracts at risk. We’ve set this quarter’s goal to rework it. This will require an allocation of 𝖷 hours of internal time across operations and legal, and 𝖷 dollars to achieve.

• Features. We’ll create a simplified, one-page consent form in easy-to-understand language suitable for 90 percent of enterprise participants, so they won’t feel the need to run it by their legal department before taking part in a study. This will halve the number of dropouts for every fifty participants recruited.

• Benefits. Most people forget to share the benefit of doing something, but it’s the most important part! Within six months of deployment, we’ll have recouped the investment cost by reducing dropouts by 𝖷, saving 𝖷 recruitment hours currently wasted on dropouts, and by speeding up research delivery by 𝖷 weeks per research study.

This is your elevator pitch: a succinct statement that gets to the point and outlines the needs, features, and benefits in a memorable format. It might not contain every detail or metric, but it should communicate the basic idea clearly and boldly.

You can use this format to sell the benefits of a past achievement, or to propose a new project to secure buy-in, headcount, or funding—or all of the above. You can also adapt your elevator pitch to share in a one-on-one, send in a monthly report, share via a DM, or to fill the thirty seconds in which you found yourself face-to-face with your boss’s boss in the elevator (or onscreen). It’s happened to me before!

Without practice, speaking a pitch out loud is awkward and even hard; it’s not something that comes naturally to most people. But once you see how effective it is, you won’t want to communicate your idea any other way. You can bring your own style to it, too; just make sure to keep it succinct and stick to the basic format. It’s a great idea to practice in private with a friend, or announce to your manager that you’d like to get better at this and ask if they’re willing to coach you. They’re sure to learn something from you, too.

This elevator pitch, by itself, is a strong message and a great way to frame your work in a simple, memorable way. But you can take your elevator pitch one (important) step further by tailoring it to the person from whom you need to get a “yes.”

Tailoring Your Pitch to Your Audience

Consider the personality of whom you’re pitching your idea to. Do they care about data? Are they always looking for wins that can be advertised to the wider organisation, perhaps even helping them gain a promotion? Are they often more interested in the social credit—the story or the opportunity for collaboration—behind an idea? Or are they typically interested in a concise summary so they can move on to the next thing?

I don’t like leaning too heavily on generic personality frameworks—the Myers-Briggs Type Indicator (MBTI), Gallup’s StrengthsFinder, and the Enneagram Test are among the best known—and here’s why:

1. Personality frameworks are often overcomplicated. For instance, the Myers-Briggs has four preference pairs and sixteen different personality types, such as ISTJ, ISFJ, INFJ, and INTJ. If you have to spend too much time trying to decode the personality type of the person in front of you, you might miss your moment.

2. There’s a tendency to lump people into one category. The reality is that people’s personalities tend to change depending on the situation. For example, when I present technical data on product safety or patient outcomes, the doctors I work with are data-oriented, so I lean into the details. But that same doctor will become a decisive “driver” if an emergency arises during a procedure, which makes sense!

Besides, almost all of these frameworks hinge on the same four primary professional personality types: the results-driven person, the data or analytical type, the storyteller or people person, and the “expressives” or visionary future thinkers.

While they will never capture how extensively different we all are, these primary personality types (see Figure 2.0) can help you understand how your key stakeholders lead, collaborate, and make decisions in the workplace—and, of course, how to sell them your ideas.

• A driver or results-driven person is typically time-efficient and a logical planner.

• A detail-driven person is focused on the data and finer details; they want to know everything.

• A storyteller or people person is typically a supportive, relationship-driven team player.

• An expressive, future thinker is typically a visionary and creative influencer.

If you’re pitching to a results-driven person (a time-efficient, logical planner), you want to be brief and get to the point. For a detail person, you might share your elevator pitch, then add, “I’ve got a lot more detail to share. Could I book a time to show the highlights from the data, so we can dive deeper where you’re most interested?” For a storyteller or people person who’s, say, looking for wins that can be advertised far and wide, you might offer to pass on a one-page win-focused summary, which they can share at their next team or management meeting, or better still, offer to present it yourself. Finally, for the visionary, don’t limit the benefits of what you have achieved to the immediate future; draw a picture that shows further progress down the line—these people love to hear about your five-year vision.

A concise elevator pitch that focuses on needs, features, and benefits, combined with a tailored approach based on personality type, will take you far. But even with all this preparation, it’s worth remembering that what you wanted to say, what you said, and what your audience heard don’t always align.

What You Wanted to Say, What You Said, and What They Heard (and Didn’t Hear)

Several years ago, I worked as a skydiving instructor, taking people on 15,000-foot skydives. They received a full day of training, then jumped out of a plane for a fifty-second freefall before opening their own parachutes. As scary as this sounds, there would be an experienced instructor, like me, on each side of the student, holding them upright, so if the student curled up in a ball of fear (which sometimes happened), we’d hold them in the correct position, and they’d generally acclimate in time to open their own parachute (see Figure 3.0). The student would then float to the ground and have adrenaline-filled stories to tell.

Before the jump, I would train the student on the exit procedure—how to jump out of the plane—and ask them whether they understood. The answer was almost always “yes.” I then asked the would-be skydiver to explain the exit procedure back to me. On more than one occasion, they would ask, “Actually, can we go through it one more time?” They were literally going to leap out of a plane for the first time, and hadn’t listened closely enough to understand what to do!

The lesson is this: What you want to say, how you actually say it, and how what you say is interpreted are all entirely different things. This is a highly applicable lesson, whether you’re training adrenaline junkies, selling medical equipment, or getting buy-in for your work as a research operations professional. So what should you do about this?

The hardest part is noticing the disconnect. At the end of your pitch, make it a habit to ask, “Which parts about that made the most sense or appealed to you—or not?” or “How does this fit into the company goals?” If pressed for time, you can even simply ask, “How does that land for you?” Occasionally, you won’t get a satisfactory response, but more often than not, these kinds of post-pitch questions will start a conversation in which you can learn more about your manager’s needs and wants in relation to your ideas and deliverables. This is also the moment that you can share a bit more (personality-oriented) detail about your proposition. Listen and watch closely, because you’ll gather invaluable insights to hone your direction and pitch, and better meet their needs (or speak their language to sell them your needs) in the future.

Selling Your Work in Uncertain Times

These tactics—the elevator pitch, tailoring to personality types, and checking for understanding—might seem like extra work, but they’re more important now than ever. And it’ll feel like a much lighter lift, the more you practice. If you’ve lived for long enough, you’ll know that economic challenges are a historical constant. In just the last thirty years, the dot-com bubble has burst, there was the global financial crisis (GFC), the COVID pandemic, and now layoffs and the unfolding impact of AI. For better or worse, change is constant. Humans will continue to invest in (and invent) new technologies, pushing companies to find new efficiencies and cost savings, adapt to market trends and forces, future-proof their operations, and keep investors investing.

In a changeable world, it’s often not enough to do a good job; you need others to know that you’re doing a good job, and you need to make it easy and beneficial for them to champion you. Ideally, by communicating your value and successes, they’ll feel invested in sharing and promoting your value and success, too. To achieve this, first, you must make smart choices about how you deliver value to the organisation. I recommend reading Kate Towsey’s recent article, “Why the Distributed Growth Model Is Failing Research Teams—and What to Build Instead,” and then applying the sales concepts I’ve shared in this article. Using these simple sales techniques takes a bit of courage and practice, but it doesn’t require extra time or resources; in fact, it takes less. If your initiatives and achievements are supported by those around you, you’re more likely to be put at the front of the line, just as I was after I landed that deal fifteen years ago—and have been ever since.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

A few weeks ago, I saw a graph in The Economist that was deeply enlightening. Unfortunately, I can’t find the article again, but it illustrated the surge in investment that defined the tech wave between 2010 and 2022. More than just an illustration of the economy, this graph helped me understand that my career had been buoyed not only by hard work, ingenuity, and (I like to think) smarts, but also by impeccable timing. I joined the tech workforce at just the right time to enjoy an era of heedless spending on salaries, equity, and snacks—and sometimes rampant hiring. With this new framing in mind, plus years of studying the economy, I’ve come to understand that companies in emerging fields, like technology and now AI, operate according to a growth model, not a profit model, with significant implications for how teams within the company should operate to succeed. This context is important, vital even, because it helps explain what’s happening in the fields of research and ResearchOps, and how to build teams that thrive even when the economy shifts, or a novel field becomes mundane—tech1 is no longer sexy, instead AI, defence, and the space sectors are.

How Growth and Profit Models Are Reshaping Research

The growth of the ResearchOps profession in the past decade has been remarkable. What started as a niche role in the most progressive technology companies of our time is now a role that’s hired by all sorts of companies, from startups to the BFSI2 sector, and legacy media giants. As part of that evolution, ResearchOps job descriptions and, by extension, ResearchOps professionals themselves, are becoming more specialised.3 Laundry-list job descriptions—the type that list an impossible scale of work, never mind the scope—are becoming less prevalent and are being replaced with well-defined requests for strategists and systems designers, and knowledge and data specialists tasked with building the capability, both human and technical, for entire organizations to generate and consume insights at high speed and at large scales. And sometimes they’re being asked to do this without researchers.

If you work in ResearchOps and you’re looking for a more expansive career path, this may sound like great news, and it is. If you’re a researcher, this may sound horrifying, and it should. The expectation that ResearchOps can run the show solo isn’t just a problem for researchers; it’s also a problem for research operations and, in the long term, for the companies that take this tack. In this article, I’ll explain why this trend emerged (hint: growth and profit models are key), why it’s unsustainable, and why—and importantly how—research and ResearchOps leaders must partner in new ways to build the future of research.

An Unsustainable Trend: ResearchOps Without Researchers

Over the past two years, I’ve heard an increasing number of stories about entire research teams being laid off, and yet the ResearchOps function has remained intact, tasked with the job of enabling the rest of the organization to do what the research team used to do, and more. I’ve also heard stories of companies in which ResearchOps is their first research hire: they’ve skipped the researchers and gone straight to ops. These teams aren’t only being asked to democratize the doing of research, they’re also being asked to integrate AI wherever it makes sense (literally) and build insights traffic systems, a term I’m introducing here, defined as systems that enable research insights to flow through the organisation in the right cadence, format, and grammar so that the audience, whether product, design, marketing, or executives, can easily access and digest it. Shivanjali Mishra’s recent article, “The Systems Linguist: How Mapping Data, AI, and Language Builds Smarter ResearchOps,” captures this beautifully and is essential reading.

The vision of democratized research, combined with AI integration and insights traffic systems, is exciting—it is the future of research—but a world in which researchers are either not involved or have been reduced to a tiny team of usability testers (as if it’s 2010 again) is not sustainable. ResearchOps professionals are highly capable strategists, systems architects, and business analysts, but unless they come from a research background, they’re just not as equipped to make decisions about research strategy, methodology, or quality management: all key to successful research operations.

If you’re a research leader, this message is for you: Whether companies know it or not, they need you. And they need you to respond to the change in how they’re operating by building and operating research teams, or research capabilities, in entirely new ways, too.

So, what does that look like?

To understand how you should operate now, it’s useful to understand how research scaled during the 2010–22 tech wave and synthesize the lessons learned for rebuilding a more robust research capability in your organization today.

How We Got Here: The Distributed Growth Model

According to “The Crunchbase Tech Layoffs Tracker,” since 2022, a total of 509,000 tech jobs have been impacted in the US. The layoffs weren’t a blunt response to economic pressures—the NASDAQ index has never been higher—or the promise of AI. Instead, it’s symptomatic of the reshaping of how technology companies operate, which is reshaping how every person and team within them operates, from product to design, and research to ResearchOps. But what pushed tech companies to make such a significant employment correction—one that’s affected countless professions—and what does it mean for research?

Between 2010 and 2022, UX research teams ballooned off the back of well-funded growth in tech—and even in the odd government. Companies were focused on growing the size of their customer base, number of monthly active users (MAU), and even the number of employees. Interest rates were low, growth was paramount, and profit was second fiddle—and the talent market was highly competitive.

To support growth in customers and MAU, companies invested in user researchers: in simple terms, happier MAU equals more MAU, which equals growth, which equals happy investors. (You can say the same thing for AI companies today.) This dynamic isn’t likely new to you, but here’s the important bit: often, this hiring didn’t happen as a centralized effort, one in which the “company” or, more accurately, the company’s executive said, “Let’s build a user research team that helps us make decisions about critical business areas.” Instead, unknowingly riding the tech wave, the research team grew via distributed investment.

Here’s how it played out: a product or design manager realised that the amount of research they needed, often on pre-launch usability testing—let’s make sure we’re not launching a flop!—exceeded the number of hours they had available. So, they secured the funds to hire a researcher, either as a contractor or a full-time employee. The researcher focused their efforts on usability testing and, without the complexities of a scaled-up research department or too many rules, could often deliver insights fairly quickly without anyone else needing to lift a finger. So, the manager, keen to maintain this new superpower, hired the researcher full time and, soon enough, hired more researchers, putting the first researcher in charge. And just like that, the first researcher on the scene became a research manager.

Soon, other product and design managers, envious of their colleagues’ research capabilities, secured headcount to hire their own researcher. So they “flipped a headcount” to the research manager, on the condition that the researcher they hired would be dedicated to their specific team. Over time, the research manager became a manager of ten researchers, then twenty, then thirty, and, in some cases, a hundred or more researchers, most, if not all, acquired through flipped headcount. As the team grew (and as the notion of ProductOps, DesignOps, and ResearchOps became more popular), the research manager secured headcount for a ResearchOps professional tasked with making researchers’ work easier. In truth, these folk often acted more as research assistants than research system designers, making the research team even more expensive to operate with little measurable value delivered beyond the research team…unless they were put in charge of democratizing research. In this case, they were given a platform to showcase their skills as highly efficient, business-aligned enablers for hundreds of people—an important point in this narrative arc.

There are lots of ways this story can play out, but the central theme remains the same: instead of executive teams allocating a centralized budget to build a research capability aligned with its goals, and therefore geared to deliver executive-level value, product and design managers flip headcount one at a time, and, in doing so, fund the growth of a research capability without anyone necessarily being aware of the collective organizational investment. But the collective investment isn’t invisible, or small. It’s accurately recorded, down to the cent, in the company’s accounts against a line item labelled “research.”

The Hidden Cost of Distributed Growth

You might be surprised by how many research managers don’t know the total cost of their team to the business, or the average cost of each research study, which is a major managerial mistake. As a back-of-the-napkin calculation (corroborated in detail by Claude), a ten-person research team based in San Francisco costs between $2.2 and $3.2 million per year, depending on benefits. That’s peanuts when a company’s annual revenue is $53.439 billion (that’s Intel’s revenue in 2025; Intel also had the most layoffs in 2025). But in a cost-cutting, profit-focused context, it all adds up—and there’s one more bit of interesting maths that you should do. On average, a researcher can deliver two or three qualitative studies per quarter, which means that every research study costs between $20,000 and $30,000 to deliver.

The composite of these numbers, along with distributed investment, is where the rubber hits the road. If a research study or insight only delivers value within its immediate context and then disappears into thin air, from the executive’s elevated point of view, research is simply expensive vaporware—$3.2 million-per-year vaporware, to be exact.

When investment in research is distributed, and research outcomes aren’t constantly repurposed and redistributed across the company, fail to mimic the product development beat, or don’t hit the nail on the head for the highest-priority audiences, each stakeholder who flipped a headcount might know the value their researcher delivered, but no one else will.

This kind of spending may pass muster while the company is focused on growth rather than profit, but when the focus shifts to maximising profits, as it did in 2022, the executive will comb through the financial reports and find ways to cut costs. If they’re unable to communicate or point to the value a team delivers, or are convinced there are cheaper ways to achieve the same goal (say, by democratizing the effort or leveraging AI), that team will find itself on the chopping block. But if there’s a small team of business- and tech-savvy operators who are already enabling hundreds of people to do and consume research…well, we’ll keep them, thanks.

The suggestion here is not that researchers find a way to tie their value (or the insights they deliver) to the bottom line, as sales or manufacturing might. That’s a wild goose chase, and something I cover in detail in my book Research That Scales (see Chapter 2, “Lost and Won on Strategy”). The suggestion isn’t even that you must compromise and democratize research to make it seem like you’re delivering value—and save your job. Research is a cost center (a team that’s not expected to generate revenue directly), and there’s no need to pretend otherwise. But cost center or not, every team in an organization must operate in a way that makes its value, or the perception of its value, obvious to the executive, which requires being highly strategic about how you operate. In practical terms, this means you must have a research strategy, research operations strategy, and operating model that conscientiously balance distributed and vertical value.

If the terms “research strategy,” “research operations strategy,” and “operating model” have caught your attention but you’re not sure what they are or how to create them, I’ve literally written the book for you. The first four chapters of Research That Scales are dedicated to these concepts. Over the past eight years, I’ve run masterclasses with hundreds of research managers, and I can count on one hand how many of them had a research strategy and a resulting operations strategy (and operating model) that wasn’t happenstance. That’s a huge problem. If you’ve been able to deliver executive-level value without purposefully defining what you’ll do—and not do—(your strategies), and designed a model for how your organization should operate to achieve those goals (your operating model), you’ve been lucky, not smart.

So what does smart look like?

An Intentional Paradigm Shift: Building Vertical Value Into Your Operating Model

Sometimes the only way to grow a research team is through distributed investment, and this type of growth isn’t something to avoid. But if you’re a research leader, rather than continuing to grow a bigger and bigger research team that only delivers distributed value, you must, from day one, find ways to secure buy-in or find inventive ways to build vertical value into how you operate.

Vertical value delivers value vertically, as the name suggests—upwards through the hierarchical layers of the organization—ideally all the way up to the executive. While horizontal value often requires scaled-up operations and a lot of busyness to deliver value (lots of studies, logistics, stakeholders, and communications), in the world of vertical value, if you make the right choices, you need only deliver one to three perfectly aligned and articulated research studies or systems to be perceived as worth your weight in gold. Here, your operations aren’t focused on enabling quantity or pace. Instead, the goal is to become indispensable to senior leadership by consistently empowering them to hit the bullseye on million- or billion-dollar decisions, and, if possible, all the day-to-day decisions, too.

When it comes to approach, your inventiveness is the limit. But you’ll only succeed if you respond to the unique context you find yourself in. A paint-by-numbers, checklist approach simply won’t cut it—you’ll rarely find that kind of advice in my writing. And unless you work for an AI startup, this is not the era for grand visions that require significant startup investment. Instead, take a “LeanOps” approach and make the most of what you have. That said, let’s look at four key pointers for going vertical.

1. Align with Executive Priorities

As is likely clear by now, you must find ways to deliver research value that’s directly and unequivocally aligned with the executive’s priorities. Delivering “research value” needn’t mean delivering more research—it might, but that shouldn’t be the assumption. Instead, or in complement, you might provide a voice-of-customer report or access to a beautifully curated research library focused entirely on the executive’s priority: those new AI features for government customers, say. What you do is dictated by the needs and personalities of the people you’re trying to empower with knowledge. Again, the options are limited only by your ingenuity and budget.

I regularly hear a number of excuses for why this kind of alignment isn’t possible. To be blunt, most of it is procrastination. The most common things I hear: “I don’t have a seat at the table,” or “the executive hasn’t published a strategy, so I don’t know what their priorities are,” or “we can’t do this kind of work without additional funding, and getting the funding is hard.” Here’s how to handle these scenarios:

• I don’t have a seat at the table. If you regularly and artfully communicate your achievements in the language of the executive, doing this kind of work will likely eventually get you a seat at the table because you’re working in alignment with executive priorities—by definition, this is what they care about the most.

• The executive doesn’t have a strategy. You can find out the executive’s priorities by asking someone in finance where the executive is spending the most money. It’s a simple but highly effective hack.

• We don’t have the funding. If you align with a chief business priority and can offer a compelling story of how you can help, I guarantee you that ample funding will be made available to support the right efforts. You may not secure millions right off the bat, but you will certainly secure enough to deliver a minimum-viable example from which you can grow.

In the past and on multiple occasions, I’ve used these tactics to secure headcount, build specialist teams, deliver global research systems, and secure access to innovative research tools.

2. Repackage and Redistribute Insights

If you’re a research manager, I’ve got news for you: you’re not a research manager, you’re a research services manager—managing researchers is just one part of delivering a knowledge or insights service; it’s not the core purpose of the role. Core to your role is finding ways to create, repackage, and redistribute insights—the same insights generated through distributed investment—so they’re relevant to more senior levels of the organisation. If you’re not able to do this, perhaps because the initial insights are too shallow to repurpose for senior management, reconsider how research is done and whether you can build this kind of knowledge capture into your workflows without slowing delivery.

Research knowledge management is a huge topic, and thankfully, there are now excellent resources that you should devour. Here’s a short list of must reads:

• Research That Scales, Chapter 5, “Long Live Research Knowledge”

• Stop Wasting Research by Jake Burghard

• “The Systems Linguist: How Mapping Data, AI, and Language Builds Smarter ResearchOps” by Shivanjali Mishra is worth mentioning again

• “Pragmatic Knowledge Management: From Scattered Insights to Serendipitous Intelligence” by Lilyth Ester Grove

3. Apply the Prioritized-Access Principle to Democratization

It’s common for research leaders to attempt to deliver vertical value, or scale up access to insights, by democratizing research. In other words, by enabling designers, product managers, engineers, and others to do research themselves. In principle, this is usually a good move, but democratization efforts are typically based on a significant strategic mistake, making them far less effective than they could be. That mistake? For-profit organizations are not egalitarian: not everyone’s need for access is equal.

Your operating strategy, including your strategy for democratising research, must acknowledge that there are high-risk or high-priority stakeholders or topics, less influential people or topics, and those whose input or research topic needs are inconsequential. Though all of these groups might want access to the capabilities for doing research (or getting research done), in a profit-oriented world, enabling equal access to everyone is unwise and inefficient. It uses precious resources to deliver horizontally rather than vertically oriented value.

To use a concert-going analogy, too many research democratization efforts either aim to give everyone the all-access pass experience or to give everyone, including those working on high-priority projects, general-admission tickets. Key to a democratization strategy is ranking the access needs of various people or teams, the risk or importance of their work, and the research capabilities that are already available within those teams. Based on that information, you can design a system that provides all access to some, select viewing to others, and to everyone else, access to general admission or even an invitation to observe from the sidelines—or online. This advice isn’t about being elitist; it’s about being strategic with limited resources to demonstrate measurable value where it matters most to the business.

4. Regard ResearchOps as Strategic Partners, Not Administrators

If you approach building research as building a research capability (not just a research team), you’ll likely build a vastly more diverse team than you might have done in the past. As a research services manager, your team will likely include highly specialised researchers—the type who can do the high-stakes, strategic research that no one else in the organisation can do—as well as systems designers, librarians (AI means that librarians are more crucial than ever), communications and data specialists, and, yes, administrators to keep everything moving.

To design, build, and maintain these systems, you’ll need a senior ResearchOps specialist, even as a consultant, in the senior ranks (use The Universal ResearchOps Career Ladder as a guide) to partner with you and help design the operating systems that will make your research strategy an operable reality.

A small, well-designed ResearchOps team can enable hundreds of people to learn about customers while ensuring that insights flow to where they’re most valuable. That’s the value proposition that keeps many ResearchOps functions intact even when research teams are cut. But this only works if ResearchOps is working in the service of a deliberate research strategy, not simply in reaction to distributed, egalitarian demands.

Nostalgia Is Not a Strategy

At the 2026 World Economic Forum’s Davos event, Canadian Prime Minister Mark Carney said in his seminal speech about the changing world order in politics and finance that “nostalgia is not a strategy.” His words rang true on so many levels, and they ring true in the corporate world, too.

The companies hiring ResearchOps without researchers aren’t making a mistake about the value of operations. They’re making a calculated bet that they can get customer insights more cheaply and at greater scale without a dedicated research team. In some cases, they might be right. But they’re also making a bet that they can democratize research quality, maintain research rigour, and build insights traffic systems without the craft expertise, strategic thinking, and quality control that skilled researchers bring.

They can’t.

The real question is whether research leaders will recognize this moment for what it is: not a crisis to weather, but an opportunity to redesign how research operates from the ground up. To build research capabilities, not just teams of researchers.

The old model of distributed growth and horizontal value is gone. If you’ve been given headcount and you think you’re reorganizing things back to what they used to be, I encourage you to rethink your position. The current hire-and-fire habits show that companies value operational capability and small teams that deliver outsized value. Research leaders need to design operating models that deliver vertical value from day one, and partner with ResearchOps professionals to do so. ResearchOps professionals need research leaders who understand this shift so they can build sustainable systems that scale the value of research—they must also leave logistics management behind and become research systems designers. When both roles recognize their interdependence and operate accordingly, as a partnership, that’s when research (not the team, but the capability that enables curiosity and knowing) becomes indispensable. That’s a future worth building.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

So I scanned LinkedIn to understand the key worries, such as “Will User Interviews become inaccessible for teams with a small budget?” and asked members of the Cha Cha Club, a members-only club I founded for ResearchOps professionals, about their key concerns. Then I sat down with Basel Fakhoury, the CEO and cofounder of User Interviews, and Baran Erkel, the chief strategy officer at UserTesting, as a guest host on the Insights Unlocked podcast, to ask them your questions.

This wasn’t a polished public relations moment, and I wasn’t paid for my time. Instead, it was a candid look at what this acquisition means, now and in the long term, for the people who use these tools.

If you’ve got more questions for Basel and Baran, please post them in the comments.

Things Mentioned in This Episode

• Research That Scales: The Research Operations Handbook by Kate Towsey

• ResearchOps 2.0, an audio documentary about the past, present, and future of ResearchOps

• Cha Cha Club, a members’ club for ResearchOps professionals

In November 2025, we published The Universal ResearchOps Career Ladder, an industry-defining asset that’s already become a go-to reference for ResearchOps professionals, hirers, and managers worldwide.

But what was it like for ResearchOps practitioners before this resource existed? Caitlin Faughnan, the Senior UX ResearchOps Specialist at GitLab, caught up with to discuss exactly that. She shared how misunderstandings about the role and scope of ResearchOps have impacted her career growth, and how she overcame them by advocating for a custom career ladder for ResearchOps in her organisation.

When Caitlin did this work, she didn't have an industry benchmark to refer to. Now, of course, we have The Universal ResearchOps Career Ladder to lead the way.

The Universal ResearchOps Career Ladder

The Universal Researchops Career Ladder

16.7MB ∙ PDF file

Download

Download it. Explore it. Print it (if you like).

Download

Credits

The Universal ResearchOps Career Ladder was produced by , with contributions from the following Cha Cha Club members: Wyatt Hayman, Saskia Liebenberg, Rodrigo Dalcin, Jared Forney, Lauren Galanter, Caitlin Faughan, Stephanie Marsh, Stephanie Kingston, Kalee Dankner, Leah Kandel, Jamie Williams, Jenna Lombardo, Christen Penny, Luana Cruz, Alma Krezla, Carolyn Morgan, Lydia Iana, and Rebecca Dennigan.

Brought to You By

User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

About six years ago, I transitioned from academia to UX research. While in academia, I spent seven years studying linguistics, including a master’s in clinical linguistics and psycholinguistics. During that time, I learned about how languages are wired in our brains and how to assess and inform targeted interventions to treat language disorders.

Given my background, I think a lot about research systems and knowledge management—and working on a research repository in some capacity has been a consistent item on my to-do list for more than four years (almost as long as I’ve been involved in user research). In that time, I’ve set up research repositories in four very different tools (in terms of features and popularity), then reevaluated and offboarded those tools, and finally settled on one that seems to be sticking. And it’s sticking, not because of its features, but because of one key insight that changed everything.

That insight? Easy access to relevant and accurate user insights isn’t about finding the perfect software. It’s about embracing something more fundamental: A research repository isn’t just a tool; it’s a linguistic system.

If those two words—linguistic system—just muddled your mind, don’t worry. By the end of this article, you’ll know exactly what they mean and why they’re important. I posit that the modern ResearchOps professional must become a systems linguist: someone who can map an organization’s hidden data architecture, translate between different functional “languages,” and build truly integrated research systems. Given my formal training as a linguist, this article isn’t just a theoretical musing. It presents a practical framework that has transformed the way I approach every aspect of research operations, from tool selection and stakeholder engagement to preparing for an LLM-enabled future. And I believe this approach can transform how you manage research knowledge, too.

The Source of Meaning

First, let’s look at what makes a research repository unsticky. Even though a repository might have promising features, getting people to regularly use it—and the information stored in it—as a functional tool, can be challenging. On the surface, the challenge may seem like an onboarding problem, but it usually turns out to be deeper than that. I’ve learned that research knowledge can’t be treated as distinct from organisational knowledge and context; it must be seen as one and the same. Additionally, most companies aren’t leveraging the many sources of user voice they have available—social media mentions, support tickets, survey answers, interview transcriptions, and more—to support decision making. (More on this in a moment). These realizations fundamentally changed what I was building, and, therefore, the questions I asked. Instead of asking, “Which repository tool has the best features?” I asked:

• Who needs to find answers, and how do they naturally look for them?

• What questions are they asking, and in what language?

• Where does relevant data already live in the organization?

• How can we make these disparate sources speak to each other?

These aren’t tool-selection questions; they’re systems questions. And more than that, they’re linguistic questions. They’re about understanding how meaning flows through an organization, how different groups encode and decode information, and how we can build translation layers between them.

This mirrors a fundamental principle in linguistics: meaning emerges from systems, not isolated units. In other words, meaning is relational, not inherent. For example, in a medical context, the word “sick” means unwell (I am sick), but “sick” also could be used to communicate awesomeness (That painting is sick!), or to express frustration (I’m sick of this traffic!). A word doesn’t mean anything by itself; it means something in relation to other words, in a particular context, used by particular people for particular purposes. The same is true for organizational knowledge.

Diagnosing the Language Problem

The role of a clinical linguist involves observing how language breaks down. You use the tools of linguistics to dissect the unique pattern of communication, move from surface-level symptoms to a theoretical understanding of the underlying breakdown, and, in turn, drive precise and effective interventions.1

When I first became a ResearchOps professional, I couldn’t help but see similar patterns. I saw communication break down between teams due to incoherent processes and disconnected goals. Often, different teams were simultaneously and separately trying to solve the same problems, and research insights weren’t reaching the teams that needed them. Not just because of workflow issues, but because of siloed communication.

The real breakthrough came when I realized that teams weren’t just using different terms to describe similar meanings, they were operating with entirely different grammars to communicate about data, processes, and even value.2 And by grammars, I mean unwritten, foundational rules, structures, and logic. For instance:

• Product teams speak in the grammar of metrics, outcomes, and user flows. They need research insights that are tied to key performance indicators (KPIs) and roadmap decisions.

• Design teams speak in the grammar of experience, pain points, and journey maps. They need insights rich in context and emotional resonance.

• Engineering teams speak in the grammar of constraints, requirements, and edge cases. They need insights that are specific, actionable, and technically grounded.

• Leadership teams speak in the grammar of strategy, market positioning, and business value. They need insights that connect customers’ needs to a competitive advantage.

These grammars aren’t wrong per se; they just vary depending on the role of the insights consumer. But when a research finding is documented in only one grammar—say the grammar of a product manager—it becomes invisible to everyone else. This isn’t a training problem or a process problem, or even a tooling problem; it’s a translation problem.

This is where an understanding of linguistics comes in handy. Linguistics gives you frameworks for understanding how language works across three dimensions:

• Syntax (Structure). How elements are organized and related to each other.

• Semantics (Meaning). What those elements signify.

• Pragmatics (Use). How meaning changes based on context and who’s communicating.

You needn’t have a master’s degree in linguistics to leverage this understanding. You can start applying a linguist-informed approach by exploring the following questions across dimensions:

• Syntax. Consider all the sources of customer feedback your organisation collects, such as customer support tickets, feedback channels, and social media, and identify the patterns among them. Questions to ask:

  • How is data currently organized in your systems?

  • How are insights tagged, categorized, and linked to each other?

• Semantics. “Engagement is down,” can mean different things for different teams. To a product manager, it could mean a drop in activation, average session time or retention rate. For designers, it could signal a usability issue. For customer relationship management (CRM) and marketing teams, it could mean lower email open rates or fewer social media interactions. All of which leads to the next point. Questions to ask:

  • What does one common word or term mean to one group versus another?

  • What does ”customer satisfaction” or “usability issue,” for instance, mean to your colleagues in product versus design versus support?

• Pragmatics. If you’re presenting findings from discovery interviews to a product team, you might include concrete recommendations for features to add and pain points to address. If you were to present the same findings to leadership, you might want to focus on business value, market share, and long-term product strategy. Questions to ask:

  • How does the same finding need to be presented differently depending on who’s receiving it and the decision they’re making?

By exploring these questions, you’ll stop treating the “language problem” as a “tooling problem,” or as something that only happens between internal teams, and start seeing knowledge exchange (and research impact) as a systemic property of how knowledge moves through an organisation. And once you have a linguist’s eye for syntax, semantics, and pragmatics, you can apply it not just to how insights are communicated, but to how they are collected, stored, and surfaced in the first place. In other words, you’ll be able to map the hidden architecture of your organization’s language—the often invisible structure that shapes how customer realities either get amplified or lost in translation.

Mapping the Hidden Architecture: What Linguists See That Others Miss

As research professionals, customer language is our data. It flows in from every channel: support tickets, in-product feedback, survey verbatims, app store reviews, and social media mentions, to name a few. The goal of every ResearchOps professional should be to architect a knowledge system that doesn’t just count keywords but understands the underlying messages, concerns, and emotions of customers and end users within the constant stream of words—written and spoken.

Research (and the operations that make it tick) is about transforming fragmented, raw text and dialogue into structured, contextual insights that teams can act on, ensuring the customer’s true voice is never lost. But here’s what most organizations miss: organizational data is inherently variable. Just as sociolinguists understand that language varies systematically (not randomly) across demographics, regions, and contexts, a ResearchOps professional needs to understand that customer data varies systematically across sources, channels, and collection methods. For example:

• Customer support tickets typically capture problem-focused language. Support requestors are often stressed or frustrated, so the register is often transactional, the urgency is high, and the context is reactive.

• Survey responses capture reflective language and are collected in a structured environment. So the register is more formal, the urgency is lower, and the context is evaluative.

• Social media mentions use conversational language, often performative or community-oriented. The register is informal, the authenticity varies, and the context is public.

• User interviews use narrative language that’s cocreated with the researcher. The register adapts to the interviewer’s style, the depth is greater, and the context is exploratory.

Each of these sources provides a different “dialect” of customer truth. And just as a linguist would never claim that one dialect is “correct” while another is “incorrect,” a systems linguist (that’s you!) must recognize that each source provides legitimate but only partial insight. This variety of dialects needn’t be read as a hindrance, but as an opportunity to build knowledge systems that enable the pairing or triangulating of data sources to provide a more complete picture of the customer experience. More data isn’t always better—that’s not the lesson here—but linguistic diversity in your data ensures that you’re capturing the full range of how customers express their needs, frustrations, and desires.

Data diversity is especially important if you’re integrating AI into your knowledge stack. And who isn’t? Studies on language models3 make one thing clear: the variety baked into the training data―its words, grammar, and topics―sets a ceiling on how varied the model’s own language can be. Any model essentially mirrors the specific dialects and registers present in its corpus (a large, structured dataset), so voices that never make it into the data remain invisible in the model’s responses.

The AI Imperative: Why This Perspective Matters Now

It’s near cliché to say it, but the industry is consumed by talk of AI. To prepare your knowledge systems for the future—the not-so-far-away future—it’s important to see through the AI hype by understanding the mechanisms underlying LLMs. In the simplest terms, current AI offerings are Large Language Models (LLMs), and the solutions they provide are based on the data on which they’re trained.

So, what happens when we apply this understanding to AI-enabled research knowledge systems that span the entire organization? LLMs are fundamentally linguistic technologies: they learn patterns in language use and generate text based on those patterns. When you deploy an AI tool to help stakeholders find insights in your research repository, in a way, that tool is learning the language of your organization, or more accurately, the language of the context you’ve provided it with for that search. But here’s the challenge: if your organizational data is siloed, inconsistently structured, or dominated by only one type of source (say qualitative interview transcripts), the AI will learn a partial, biased language. It will excel at answering certain types of questions while remaining oblivious to others. It will perpetuate existing silos rather than break them down.

Research on LLMs makes this clear. A sociolinguistically informed approach to curating training data can improve the social impact of language models. Linguistic insight can inform the broader development and application of modern LLMs, including reinforcement learning—when LLMs learn by interacting with users through trial and error—and prompt engineering, all of which are ultimately grounded in patterns of language use, or data.

Translated to ResearchOps: your research repository is training data. Every time someone searches for insights, tags a finding, uploads a study, or links studies together, they’re teaching the system (and any AI tools built on top of it) what matters and how things connect. Without understanding the sociolinguistics of your organization—who speaks what language, what gets prioritized in which contexts, what voices are systematically excluded—AI tools will:

• Miss nuances that matter

• Perpetuate existing silos

• Reflect biases in dominant data sources

• Fail to serve teams whose dialect wasn’t well-represented in the training

This is why your role as a systems linguist isn’t just about organizing knowledge; it’s about curating the linguistic diversity of your organization’s learning system to ensure that when AI tools are implemented, they serve not just the loudest voices, but everyone who needs to understand user needs and accurately represent the user.

Building the System: Practical Applications

So what does all of this actually look like in practice? There are three key steps to take a systems linguistics approach to ResearchOps. First, you must partner with the product organization, then you must work with data teams, and, finally, you must close the feedback loop—a common callout when it comes to research operations.

1. Partner with the Product Organization

First, you’ll need to work closely with the product organization—even better if you partner up with ProductOps. Partner with these teams to create a shared vocabulary for what insights are needed, when they’re needed, and in what format. Remember that the goal of research isn’t only to produce research, it’s to build a common grammar for how research integrates into product decisions. ResearchOps is a team sport, and identifying knowledge gaps doesn’t have to (and shouldn’t) be a one-person job.

ProductOps professionals explicitly understand the operational cadence of product development—the rhythms of planning cycles, launch timelines, and metrics reviews—and they’re fluent in the language of the product organization. Do everything you can to leverage this, by:

• Cocreating taxonomies that make sense to both researchers and product teams

• Aligning research tagging systems with how product teams actually organize their work

• Building bridges between research findings and product briefs, OKRs, and roadmaps

You’ll want to work with data teams, too, to help you understand the existing data-related ecosystem driving your organization, and identify the right dots to connect.

2. Work with Data Teams

I don’t often hear ResearchOps folks talking about data teams as allies. Data (platform, analysis, and engineering) teams have a wealth of knowledge about what data is being collected, how it is collected, and how to access it. Data teams understand user behavior patterns, engagement signals, and the technical structure of how information flows through systems. There are so many opportunities for ResearchOps professionals to partner with data teams, I can’t list them all! So, I’ll stick to highlighting those most relevant to this article. Data teams can help you understand:

• Where data quality issues might introduce linguistic noise: elements in open-text data that create a hindrance in data analysis, such as typos, misspellings, filler words, or cynical and sarcastic remarks.

• How different data sources can be integrated without losing context.

• What metadata needs to be preserved for insights to remain meaningful.

• How to ensure that your data sources are diverse and representative of your customer base.

As mentioned earlier, the data you collect from different sources must be paired with metadata to triangulate it. When research and data analysis teams have access to enriched data, they can form more meaningful insights and models and support continuous learning.

Once you’ve defined a common language and understand the flow of information, it’s essential to close the loop to maintain both data quality and focus.

3. Create Feedback Loops

As AI systems become more integrated into research workflows, it will become essential for you to build validation mechanisms. A validation mechanism is a feedback loop that encourages researchers (or people who do research)—your linguistic experts—to check AI-generated summaries, suggested connections, and correct automated categorizations. The system needs to learn your organization’s language over time, which only happens if there’s a continuous cycle of:

1. AI suggesting patterns or connections

2. Humans validating or correcting those patterns and suggestions

3. The system learning from validation and correction

4. And so, accuracy improving over time

This is exactly how computational linguistics, an interdisciplinary field concerned with the computational modelling of natural language approaches and model refinement, can make your research repository continuously (and almost automatically) smarter and more effective.

The Interoperable Future: From Fragmented to Fluent

There’s something deeply compelling to me about the idea that research—in some form—can be done by anyone with a serious commitment to intellectual inquiry.

—Celine Nyungen, Designer and Writer

For research to be impactful, it must be understandable and relatable, which means it must be contextual, complete, diverse, and accessible. It also needs to feel approachable, like something any team member with a genuine curiosity and a serious commitment to intellectual inquiry can engage in. This is the promise of a systems linguistics approach: to build research systems that don’t just store information—but instead actively translate information across the different languages, or grammars, practised in your organization. When it works, the payoff is transformative across disciplines:

• Researchers find the information they need without the requirement of knowing exactly where it came from or what it was originally called. The system understands synonyms, related concepts, and contextual meaning.

• Product teams understand insights in their context, connected to metrics they care about, framed in terms of product decisions, and linked to relevant roadmap items.

• Engineers can trace decisions back to the data that informed them, understanding not just what users want but why, with enough specificity to inform technical implementation.

• Leadership sees the through-line from customer voice to strategy, understanding how insights connect to business outcomes and competitive positioning.

This represents a fundamental shift from reactive support to strategic architecture, from tool management to systems design, and from research gatekeeping to researchers functioning as organizational translators. The research repository stops being a place where research goes to live (or die), and, instead, becomes a living system—one requiring continuous care, maintenance, and translation across the linguistic communities in your organization.

Zooming out and viewing my ResearchOps role as a systems linguist’s role helped me translate research across researchers, data engineers, and product teams to build a more integrated, meaningful, and impactful research practice. You don’t need a degree in linguistics to adopt this perspective; you only need to develop linguistic awareness and uncover opportunities to integrate it.

The challenge facing ResearchOps isn’t whether we’ll evolve, it’s whether we’ll learn to speak the language of the systems we’re building. As AI becomes more and more embedded in organizations’ customer learning practices, the quality of that learning will depend entirely on the intentionality and sophistication of the underlying linguistic systems. Systems we’ll build.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

In November 2025, we published The Universal ResearchOps Career Ladder, an industry-defining asset that’s already become a go-to reference for ResearchOps professionals, hirers, and managers worldwide.

Jared Forney, the ResearchOps Principal at Okta, caught up with to talk about The Ladder, why he's envious of ResearchOps newbies who now have this industry-defining asset to guide their work, and why it's important. The punchline? It makes obvious the growing role of ResearchOps as strategists, dot connectors, and system designers—not just as administrators.

On the topic of ResearchOps as strategists and system designers, if you haven’t already, make sure to listen to ResearchOps 2.0, “EP #3: Taking a Platform Approach to ResearchOps.” It’s a deep dive into the fast-moving evolution of ResearchOps, which Jared refers to in this minipod.

The Universal ResearchOps Career Ladder

The Universal Researchops Career Ladder

16.7MB ∙ PDF file

Download

Download it. Explore it. Print it (if you like).

Download

Credits

The Universal ResearchOps Career Ladder was produced by , with contributions from the following Cha Cha Club members: Wyatt Hayman, Saskia Liebenberg, Rodrigo Dalcin, Jared Forney, Lauren Galanter, Caitlin Faughan, Stephanie Marsh, Stephanie Kingston, Kalee Dankner, Leah Kandel, Jamie Williams, Jenna Lombardo, Christen Penny, Luana Cruz, Alma Krezla, Carolyn Morgan, Lydia Iana, and Rebecca Dennigan.

Brought to You By

User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

In November 2025, we published The Universal ResearchOps Career Ladder, an industry-defining asset that’s already become a go-to reference for ResearchOps professionals, hirers, and managers worldwide.

One might assume that a career ladder, or a career progression framework, is purely useful for writing accurate job descriptions, hiring the right people, providing a clear pathway for professional growth, advocating for promotions, and managing performance, which includes, dare I say, firing underperformers. While that’s a very good list, there’s one more way The Universal ResearchOps Career Ladder, in particular, can help you.

In this seven-minute podcast, Rodrigo Dalcin, Staff User Experience ResearchOps at Wealthsimple, shares why the Ladder is also an invaluable tool for assessing the maturity of research and ResearchOps in your organisation and pinpointing where growth opportunities lie.

The Universal ResearchOps Career Ladder

The Universal ResearchOps Career Ladder

16.7MB ∙ PDF file

Download

Download it. Explore it. Print it (if you like).

Download

Credits

The Universal ResearchOps Career Ladder was produced by , with contributions from the following Cha Cha Club members: Wyatt Hayman, Saskia Liebenberg, Rodrigo Dalcin, Jared Forney, Lauren Galanter, Caitlin Faughan, Stephanie Marsh, Stephanie Kingston, Kalee Dankner, Leah Kandel, Jamie Williams, Jenna Lombardo, Christen Penny, Luana Cruz, Alma Krezla, Carolyn Morgan, Lydia Iana, and Rebecca Dennigan.

Brought to You By

User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

Your team is drowning in research requests, stakeholders are getting impatient, and no matter how loudly you advocate for more headcount, the team isn’t growing fast enough to meet the demand. These challenges likely sound familiar—and they’re exactly why self-service research programs, also known as democratized research programs, have become so popular. These programs are meant to empower non-researchers to autonomously access insights and make decisions without constantly pulling researchers away from complex, high-impact work. But do they actually achieve that goal?

In the past five years, I haven’t worked with a single company that hasn’t had some version of a self-service research program. In that time, I’ve noticed that most research teams operate at one of two extremes, both of which create problems for self-service research. Once you understand these extremes and why they prompt most research teams to deliver self-service programs that don’t quite hit the mark, you’ll be able to achieve a better-balanced and more impactful self-service program in the long run.

The Fortress and the Free-for-All

One extreme of research is the “fortress model,” in which every research study must involve a researcher. Before the pandemic, in Brazil at least, many companies had a centralized research team responsible for planning, executing, and sharing research across the company. In this case, researchers were the exclusive guardians of research, and, as such, the only people who received or responded to research requests. Regardless of the research team’s size, it was expected that every researcher knew what research was happening, when it was happening, and how every study should be done. From an operational point of view, it was common to see excessively controlling (not necessarily useful) systems and processes, and the infamous kanban board (see Figure 1) displaying all the research requests to guarantee visibility (and, again, sometimes micromanagement) of all the research that could be done, was being done, or was supposed to be done. There is such a thing as over-operationalizing!

The other extreme is the “free-for-all model.” In this case, the company believes that research is easy or unspecialized, so everyone can—and should be enabled—to do it. This sounds democratic and empowering, but it’s a fallacy. I believe research can be democratized, but it must be done intentionally. We must ensure that the research operations we build to enable self-service research account for people's varying levels of research proficiency, are cognisant of the company’s priorities, and include guardrails to deliver research of the right quality. Because, contrary to popular belief, research isn’t easy, and it does require specialist skills. (If you’re a researcher, you may be nodding your head wildly.)

So how do you build a self-service program that strikes the right balance and actually works? Let’s look at the analogy of dining out, where your choices are: á la carte, all-you-can-eat, or pay-by-weight.

À la Carte

In the restaurant world, the à la carte service model is the gold standard. You sit down at your table, look at the menu, and choose your meal. A short while later, your meal arrives, then you eat and pay, all from the comfort of your table. This experience is comparable to a full-service research experience: a stakeholder submits a research request to the research team. The researcher maps out the study to understand the effort required and the potential impact, then executes it and delivers everything necessary to satisfy the request—hopefully before the stakeholder has lost their “appetite!”

This model often works well until the number and complexity of research requests increase (see Figure 2), whether due to greater product complexity or more stakeholders requesting research, or, to go back to the restaurant analogy, stakeholders ordering more than they can eat and then leaving the appetizers, drinks, and dessert on the table. You know the drill.

Even if you’re advocating for research and research operations headcount daily, it’s common not to grow at the same pace as demand—in recent times, layoffs mean that your team might even shrink in the face of growing demand. Consequently, researcher-to-research-study ratios can become surreal: 1:10, 1:15, 1:30, and beyond. In this context, even the most effectively run research teams—those with the most sophisticated systems—won’t be able to meet the demand. So, what’s a research or operations leader to do?

Just as you might find in a restaurant kitchen that’s backed up on dinner orders, the most logical and common next step is to choose which requests the research team will—and won’t—execute. In other words, the team sets up operations to triage requests. They prioritize. But then what happens to the deprioritized research studies? To address those, the next logical step is to either create systems that empower non-researchers to conduct deprioritized research (basic self-service research) with guardrails and support, or let deprioritized requests simply become unprioritized and stand by as people contact customers and conduct interviews solo. But without support or guidelines, the typical result is poor customer outreach, poorly executed customer research, and even poorer product decisions.

If you find yourself in this scenario, you’re not alone. It’s a common experience. If you do decide to set up a self-service program, there’s one crucial point that you must consider: make sure you’re not just scaling practices to accommodate as many people as possible for the sake of scale, and that your self-service program ensures high-quality research outputs. And for that to happen, you’ll need to build a system that provides value to the right people in the right parts of the business, and you’ll need to choose the right operating model.

Dining That Scales

In Brazil, we have several restaurant operating models. Two of them closely resemble self-service research programs: rodízio (similar to all-you-can-eat; rodizio means “rotation” in Portuguese) and quilo (“kilo” or pay by weight). At rodizio diners, there’s an island of amenities in the center of the restaurant, including salads, sides, and desserts, to which you can help yourself. But waiters also bring a variety of foods, usually meats, to the table throughout the meal until the customer signals that they’ve had enough. There are very few choices for diners (as stakeholders) to make, and, more importantly, they serve themselves. But the rule is clear: they can eat as much as they want, which guarantees that more food (or research and operations) must be available to satisfy their needs and goals. Often, diners wind up taking advantage of this model—they eat as much as they can eat, and more than they should!

All You Can Eat

In many of the self-service research models at companies I’ve worked with (both Brazilian and international), an “all-you-can-eat” research operating model was in place. Everyone could do all kinds of research, and everyone had access to everything. In restaurant terms, the most stringent rule was to use a plate and a plastic glove, and the latter was treated as optional! This is democratization in the truest sense of the word. If you operate in this way, you’ll find yourself creating and maintaining a massive amount of documentation, and endless possibilities for setting up and doing research from diary studies to unmoderated research, to field work and surveys, for an endless number of people. At this point, the natural response is to hold training sessions to try to teach (in just an hour or two) what researchers have learned over years of dedicated work and study.

This type of self-service program will keep you busy, and you’ll feel like you’re delivering a lot of value, at least initially. But there’s a catch: these sorts of programs create the illusion that everyone is doing research and is capable of doing everything required to do research well—or well enough. The truth is that research and ResearchOps teams often need to help organise the research and explain (and re-explain) the basics to people who couldn’t absorb the extensive training or documentation. As a ResearchOps professional, I’ve often ended up running recruitment for all of these studies because we didn’t want to open the door for people to cause damage, say by randomly calling clients without a specific scope or script of what they want to discover or, even worse, without checking if they’ve agreed to being contacted. We also regularly needed to upload research data to the repository because stakeholders failed to document research outcomes, let alone share them—an expensive and inefficient issue in itself.

In short, these kinds of self-service research programs create an illusion of self-service, with little self and a lot of service.

Pay by Weight

In a pay-by-weight restaurant, you still have the freedom to choose from a very wide variety of menu items, but you pay based on the amount, or weight, of the dishes you choose. Dishes can get absurdly expensive if you want everything, and the scale will shock you before you even take your first bite!

If you make every option and resource available for a flat fee—or no fee—people won’t think twice about using them, with or without intention. But if you make a wide variety of options and resources available, all with clearly associated costs and impacts, people tend to choose carefully, and they’re more likely to be intentional about finishing what’s on their plate. It’s this sense of responsibility and self-awareness that we want to make obvious to someone who isn’t (and perhaps never will be) familiar with research and all of its nuances…and costs.

“Research is easy” is a phrase that’s unfortunately become ubiquitous, perhaps in part because, as research and ResearchOps professionals, we’ve spent a lot of time taking responsibility for the hard part of running research. We make it look easy, making it possible for the people who are doing the research to smile and wave behind the camera at the participant. It’s on us to articulate and manage the sense of responsibility and cost implications of the systems we build. None of these self-service models is inherently wrong, but expecting a single approach to serve everyone or every situation is nearly impossible.

A Case Study: Different Menus for Different Diners

In 2021, I was working as a ResearchOps analyst in a team that was small and decentralized, and I faced a significant challenge: participant recruitment was hindering people from conducting research and forcing them to devise alternative methods for gathering insights. It was a time-consuming and costly process for my team; resources we couldn’t afford to waste. When confronted with a complex problem like this, my strategy is to simplify what I can, automate what’s complex (and automatable), and establish separate structures for teams with varying levels of expertise.

So, I first mapped out the system, identified the problems, and isolated the main pain points. This led to a solution with two distinct tracks:

1. The first track was tailored for my research team, the experts. It involved creating a sophisticated structure to manage and maintain our internal research panel, including different access levels and control mechanisms. As the panel grew, the focus shifted to acquiring the tools needed to scale.

2. Simultaneously, I developed a parallel journey that supported non-experts to utilize the same solution with reduced complexity and less direct control over its operation.

If you’re delivering a self-service program, the trick is not to simply create a dumbed-down version of the researcher’s self-service journey. Instead, or in addition, create a journey that’s specifically designed for those who will only consume the basics, or for those who can’t fit sushi, barbecue, and falafel on the same plate.

The solution I described ultimately saved approximately R$1,500 (US$275) per project, a cost that adds up when the organization is running hundreds of projects per year. The system gave people doing research the appropriate levels of autonomy and access to the participant panel we had created, which drastically reduced the recruitment time from two weeks to just a few hours, eliminating the need for full-service, hands-on recruitment support. We learned that acknowledging different levels of research maturity among teams is not a weakness but a chance to develop different ways of working that can strengthen the system and scale research.

Your self-service research program should mitigate an imbalance between capacity and demand. It should ensure that different research journeys can take place in the same environment, with various options for people with different needs and skills, and crucially, different budgets and levels of priority. Finally, while it may not be obvious, we can learn a lot from other industries and their models for scaling and satisfying appetites—even restaurants!

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

Imagine a hypothetical scenario in which a research team receives a request to conduct a study aimed at informing a stakeholder’s marketing plan. The stakeholder explains that they’d like the research team to conduct fifty in-person interviews, with the final results delivered within two weeks. The goals of the study are to measure audience size and brand awareness, understand brand perception in context to competitors, test new prototypes, and explore where end users seek information to find similar products. Seems straightforward enough, right? Well…aside from a few red flags:

• Mixed methodologies. Some of the goals are quantitative (metric-based), but they also requested qualitative research (in-depth interviews, topic exploration, prototype tests).

• Missing context. Apart from requesting both quant and qual methodologies, they’re looking for learnings from a significant number of interviews (fifty), without any context as to why.

• Inadequate timing. The turnaround time is infeasible; they haven’t considered timing for the project’s kickoff, design, participant recruitment, analysis, reporting, and more.

If you regularly receive research requests from stakeholders, this scenario is likely less hypothetical and more familiar. Some stakeholders don’t understand what makes a successful research project, well, successful. Because they’re not steeped in the research discipline, they often require guidance as to what the most effective or efficient methodologies are, how to appropriately scale and scope a project, what the process itself entails, why it’s important, and how a good research process amplifies the return on their research investment. Navigating the type of guidance you give as a research operations professional and how you handle these conversations is critical. If it’s not handled the right way, research (the process and the team) can come across as unapproachable—too complicated, expensive, and slow.

If you work in research or ResearchOps, I’m sure you’ll agree that balancing stakeholders’ needs with processes and boundaries, while ensuring practitioners aren’t overwhelmed and overworked, is a major challenge. In this article, I’ll share the ResearchOps strategies I’ve used to strike that balance. I work as a Director of Operations in an agency context, but the learnings I’ll share are equally applicable if you work in-house.

Managing Misalignment

Our research request scenario, with all the red flags, looks like a challenging project from the outset. I’ve seen a few tactics used to respond to outsized and misshapen research requests: some that foster partnership and some that chase stakeholders away. Let’s start by looking at the latter.

The most straightforward (and least ideal response) is simply to turn down the work and label the project as infeasible—or explain what is feasible but with little or no context as to why the rest can’t be done. This kind of response will likely cause the prospective partner some frustration and confusion, and lose you the business if you’re an agency, or the opportunity to build productive partnerships if you work in-house. Instead, I’ve learned to try to see the request as alignment in progress.

Budget and time constraints are common sources of misalignment. Typically, stakeholders and people who do research (PWDRs) alike want larger research budgets, and they want the insights they need delivered yesterday. But rather than explaining how the request could be clearer and more productive, researchers need to take the time to learn more about stakeholders’ goals, objectives, and timeline—and provide guidance for how to make the project more approachable for the people doing the research, while also setting the stakeholder up for a successful experience. You might also offer tiered recommendations: “best: plan A,” “better: plan B,” and “good: plan C” (see Figure 1).

By habitually taking an approach of proactive alignment, PWDRs can foster an understanding that stakeholders are doing the best they can with the information they have and vice versa. Rather than making assumptions or leaving stakeholders feeling ineffectual or confused, researchers can build relationships and educate stakeholders about good research practice. As a result, PWDRs can expect more consistent and effective requests in the future, and red-flag scenarios can become opportunities to deliver value and a positive experience. Even with a limited research budget and timeline, there’s usually an opportunity to think about (and negotiate) a feasible approach.

I call this crucial shift from a guarded or protective mindset to one that prioritizes alignment, the approachability mindset. While a mindset shift sounds easy, it doesn’t happen overnight—or on its own. But cultivating processes, habits, and culture that support PWDRs in proactively managing misalignments creates space for everyone to win.

Building Approachability Into Your Operations

Every research project can be a dream project by adopting an approachable mindset. Sounds great, right? But what does an approachability mindset look like, and how do you put it into practice? There’s popular yet somewhat stale advice out there that lacks nuance if your goal is to create lasting and transformative change.

The popular advice is to consider all the steps in your organisation’s research process and how you might standardize them. You can do this by involving PWDRs and stakeholders in a brainstorming session to understand the ideal research process, then create a roadmap for them to review and confirm (or negotiate) alignment. The goal is to confirm the expectations of core milestones within the market research process, what success looks like for a project, and the ideal study timeline from start to completion. Finally, you’ll build processes around this map.

Now, while doing this work is important, there’s a common pitfall that prevents process creation, and importantly, adoption. And, if everyone is paying attention, it will likely come up in your brainstorming sessions: the belief that every research project is too custom and unique from another, and that there’s no way to standardize the processes around them.

Consider these two examples:

1. You’re doing research in the medical field and need to conduct five in-person interviews to test new software for patient portals: a website or app for patients to access health information, such as results, communication with providers, and bills.

2. You’re running an online survey with 1,000 respondents to measure brand equity for a consumer packaged goods (CPG) brand.

These projects have completely different objectives, methodologies, and deliverables; as a research or ResearchOps professional, the many ways they differ are obvious. Developing an approachability mindset means we’ve got to shift our perspective to identify how these projects (and how all the other sorts of projects you regularly do) are similar, then create templates, processes, and document workflows that support those similarities, making research more approachable, systematic, and sustainable.

Approachability In Practice

As mentioned, I’m a Director of Operations in an agency context, so my work involves a significant variety across clients, methodologies, topics, and participants. My team has documented our unique processes and workflows from kickoff to completion. For example, we’ve created a research principles document which outlines our approach to client management from kickoff to completion, includes timelines and checklists for each step, and templates for key touchpoints (documents and corresponding email text). Having this document, along with supporting resources and templates, has ramped up our onboarding process by 50 percent. By adopting an approachability mindset, we’ve also been able to grow our client portfolio (with typically around half of our projects leading to returning clients), increase project size by two to five times, and stabilize workload efficiency across our research team.

Here are some of the steps in the market research process that we’ve standardized:

• Preparing for stakeholder or client meetings. Set up PWDRs for success by providing basic tips, guidelines, checklists, and a list of questions that need to be answered at the outset.

• Setting ideal timelines for each step of the research process. Provide a map of the most common steps, along with average or projected timelines and important aspects or milestones to consider at each point.

• Determining what to share at key touch points. Provide templates that establish a baseline for what information should be (or not be) included at key touchpoints, such as fieldwork progress, and even include reminders to send information updates. You might also include guidelines on how to position information and any nuances to consider.

• Preparing for an internal review. Provide an outline of the basic steps PWDRs should take to conduct an internal review before deliverables are shared with the client. This sort of preparation can help PWDRs build in capacity for more strategic value-add work, such as additional summary content or high-impact visuals.

• Sharing deliverables with a client. Provide a checklist of considerations PWDRs should review before sharing deliverables with clients—reminders that may help PWDRs feel more at ease when delivering insights. This could also include checklists for research design, programming, data cleaning, reporting, and presentations.

Remember, it’s not about following these processes and practices exactly for every single project. In fact, it’s better to allow for some variations; the goal is for PWDRs to consider the ideal process, and embrace an approachability mindset to navigate the nuances of each project.

Embodying Approachability

Embodying an approachability mindset brings the value—and the impact—of research into clear view, swiftly. When research professionals and projects are approachable, stakeholders not only see how effectively (and efficiently) their objectives can be met, they also tend to feel more invested in and trusting of the process. As a result, practitioners can spend less time architecting buy-in strategies and more time doing the quality work they are trained for. And stakeholders become true partners and advocates for the work.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

→ Brought to you by User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

→ Produced by Kate Towsey and the Cha Cha Club—a members’ club for full-time ResearchOps professionals.

Hiring a ResearchOps role, but not sure where to start? Advocating to build a ResearchOps team, but can’t get senior stakeholders to understand what a world-class ResearchOps team should look like? Perhaps you’re a ResearchOps professional pushing for a promotion, or you manage ResearchOps professionals, and you need a framework to illuminate the ideal career path? If you answered “yes” to any of these questions, The Universal ResearchOps Career Ladder (the Ladder) was made for you.

Download It. Explore It. Print It.

Download The Universal ResearchOps Career Ladder as a PDF or print it out. It is detailed, so you’ll need to get it professionally printed at A0 size.

The Universal ResearchOps Career Ladder

16.7MB ∙ PDF file

Download

Use it to write clear job descriptions, provide direction, advocate for promotions, and manage performance—build a thriving ResearchOps team that can supercharge research.

Download

But before you dive in, read on. I’ll share what a career ladder is, why the Ladder is an essential asset now more than ever, why this ladder is universal—a useful asset, whatever your team size, industry, or ResearchOps specialty—and how to use it as a springboard to create a ladder that’s custom-fit.

As a bonus, you’ll also get a sneak peek at some of the data and quotes from User Interviews’ forthcoming report, The State of Research Operations 2025, which will be published in December 2025.

But What’s a Career Ladder?

If you’re wondering, “But what’s a career ladder?”, wonder no more. In her recent article for The ResearchOps Review, “License for Maximum Impact: The Power of a ResearchOps Progression Framework”, senior ResearchOps leader, Saskia Liebenberg, put it best:

You might call this [a progression framework] a career ladder, performance matrix, skills framework, job architecture, or level document. In short, it’s a tool managers use to evaluate what success in a role looks like, and how to level their team members. And, of course, it’s also used to evaluate whether someone should be promoted (or not), which makes it an important asset for employee growth, especially when the role is niche.

ResearchOps is a niche role, and it’s evolving quickly. So quickly, in fact, that managers and hirers could be forgiven for not keeping up with the core competencies (skills, knowledge, and abilities) required to do the job well, let alone what good ResearchOps looks like. So, how has ResearchOps evolved?

From Administrators to Sophisticated Operators

Over the past fifteen years, ResearchOps has gone from scrappy teams of one focused mainly on administrative tasks to the point people delivering sophisticated research operating systems. While teams of one still predominate—according to data from User Interviews’ upcoming report, 41% of respondents with a ResearchOps function said they had one dedicated team member, 31% had between two and five, 17% had between six and 19, and 11% had 20 or more—the nature of the work has fundamentally changed. ResearchOps teams of all shapes and sizes are now less focused on administrative tasks and more focused on systems and service design, and business (or product or service) management. This quote puts it perfectly:

We are no longer just talking about scheduling interviews and sending out emails. Instead, we are seeing a focus on managing research programs, with a lot of service design and product management skills being required for these roles. This change from past roles makes me believe that we are moving towards a greater emphasis on management skills in these positions, rather than just the operational tasks typically handled by interns and junior-level employees.

—The State of Research Operations 2025 by User Interviews

With the focus on low-impact clerical tasks almost a thing of the past,1 mature ResearchOps professionals are instead designing and delivering systems that impact dozens or hundreds of people. As a result, they’re gaining the buy-in they need to grow their careers and their teams, and they’re trailblazing ResearchOps manager, senior manager, and even director or VP-level ResearchOps roles, whether as individual contributors (ICs) or as people managers. As part of this evolution, many ResearchOps leaders are, for the first time, learning how to hire, who to hire, and how to structure and advocate for their team.

In the midst of an economic downturn, this is all good news. But the speed and busyness of this evolution has meant that many ResearchOps professionals haven’t had time to define a career ladder, or a satisfying one, to guide their and their team members’ professional growth.

I don’t quite know where I’ll be in five or ten years’ time because I don’t see a career path that’s been clearly carved out for me.

—The State of Research Operations 2025 by User Interviews

Add to this the growing stature of ResearchOps, which means many companies are hiring their first ResearchOps team member—great news again—but with limited resources to refer to, they’re playing guesswork as to who to hire, when, to do what, as evidenced by the countless laundry-list job descriptions!

I wanted to change this (both the laundry-list job descriptions and the lack of a clear career path), so I teamed up with User Interviews and, with contributions from a crew of Cha Cha Club members, created The Universal ResearchOps Career Ladder. Now, whatever your team size, industry, organisation type, specialism, country, or ResearchOps expertise, you have a springboard from which to create a ladder that’s custom-fit, or to use as is, if your organisation allows it.

Using the Ladder as a Springboard

While researching The Universal ResearchOps Career Ladder, many of the ResearchOps ladders I reviewed2 included craft layers for the ResearchOps elements,3 such as participant recruitment, knowledge management, or ethics and privacy, as a requirement across multiple levels.

To retain the universality of The Universal ResearchOps Career Ladder, I chose not to list particular ResearchOps elements as a requirement at any level and instead described core ResearchOps competencies that can be used to manage performance whatever the employees specialism. This not only makes the Ladder universal across companies and countries, it also makes it universal across the variety of people that comprise a dynamic, articulate ResearchOps team.

Should you use the Ladder as a springboard to create your own career ladder for ResearchOps, I recommend you retain this universality. Here’s why: As your team grows in size and sophistication, you may hire people with deep expertise in one element, like knowledge management, communications, or finances, as I’ve done in the past. These people are unlikely to require deep expertise in other ResearchOps elements to succeed in their role, so an overly specified ladder won’t represent their journey or stand the test of time as your team evolves. In short, your ladder should be specific enough to guide growth across specialities, but not so specific that you need multiple complex ladders, or constant iterating, for it to remain an accurate reference for performance and growth. Keep this principle in mind as you customise The Universal ResearchOps Career Ladder to help your ResearchOps team thrive.

Share Your Feedback

If you would like to share feedback about the Ladder, please leave a comment.

Leave a comment

Brought to You By

User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

Credits

The Universal ResearchOps Career Ladder was produced by , with contributions from the following Cha Cha Club members: Wyatt Hayman, Saskia Liebenberg, Rodrigo Dalcin, Jared Forney, Lauren Galanter, Caitlin Faughan, Stephanie Marsh, Stephanie Kingston, Kalee Dankner, Leah Kandel, Jamie Williams, Jenna Lombardo, Christen Penny, Luana Cruz, Alma Krezla, Carolyn Morgan, Lydia Iana, and Rebecca Dennigan.

These articles were a valuable reference:

• “Career Ladder from Junior to Director—Guidance for UX Professionals” by Jing Jin, Bootcamp

• “License for Maximum Impact: The Power of a ResearchOps Progression Framework” by Saskia Liebenberg, The ResearchOps Review

• “Defining UX-Career Progression: What Practitioners Say” by Rachel Krause, NN/g

• “The 5 Stages of UX-Career Progression” by Rachel Krause, NN/g

Subscribe now

Brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

For most people, 2025 disappeared in a blur of AI feature releases and news of layoffs, at least in the professional sphere. It’s been a funny-not-funny old year! Were you to do a sentiment analysis of the future of research and ResearchOps on LinkedIn, the mood would be sombre. I know because I’ve done that poll; in fact, I’ve done two:1 only 11% of the 250-odd people who responded to those polls were optimistic about the future of research, which implies ResearchOps, too—at least to a degree. On the face of it, that’s pretty bleak. But it’s not all bad news.

A recent The Economist article (paywalled) perfectly explained something I’ve been pondering: “Some suggest that an economy needs the occasional downturn to stay healthy. Joseph Schumpeter, an Austrian economist, argued they provoke ‘creative destruction.’ Failing firms exit the market, capital moves to more promising technologies and workers move to more productive jobs. The result is short-term pain and long-term gain.” The article goes on to share a further Schumpeter quote: “‘Depressions are not simply evils, which we might attempt to suppress,’ he wrote. They represent ‘something which has to be done’.”2

This year, ResearchOps professionals across the globe have embraced Schumpeter’s “creative destruction,” know it or not, and they have learned to adapt. As a result, ResearchOps has greater potential and scope than ever before—and, ideally, more jobs when the economy picks up.

To create this “Year in Review,” I asked Cha Cha Club3 members, all full-time ResearchOps professionals, to send me videos and quotes sharing the biggest trends they experienced in ResearchOps in 2025 and what they expect in 2026. Five core themes emerged, the first of which should come as no surprise.

The Biggest Theme? No Surprises, It’s AI.

As Eric Levy, Director of Insights Operations for US Pharmacopeia, so wonderfully wrote, “2025 is clearly the year that AI ate common sense. Everyone is anxious to deploy some type of AI use case to show they’re keeping up and to see if the fuss is all that.”

There are endless news articles about the AI bubble bursting, at least from an economic point of view. Still, as far as ResearchOps folks are concerned, AI is here to stay, and they’re proactively figuring out how to implement it not just as a siloed technology but as a capability that’s integral to how research operates. Noël Lamb, the Senior ResearchOps Manager for ServiceNow, put it perfectly:

This year, I’ve learned firsthand how important it is to think about enabling AI not just as a technology, but as a program. One that requires intentional structure, clear ownership and strong change management to truly bring teams along and meet them where they are in their own adoption journeys.

Jared Forney, the Research Operations Principal at Okta, Inc., calls this intentional structuring and change management “meta work.” He said, “I’ve spent more time in the last three months collaborating with our privacy and product legal partners on implementing this new tooling than I have in the last year, prior to the rise of all of this AI functionality. And I think that presents a ResearchOps practitioner with unique opportunities to interface with teams that they don’t spend as much time with, generally speaking.”

A common complaint across disciplines in 2025 has been the notion that AI will solve everything—typically a hopeful, cost-cutting call “from above”; from the executive. Generally speaking, it seems people are waking up to the fact that this isn’t true—at least not yet, and perhaps it never will be. But these notions have been thematic, so as ResearchOps professionals have started to wrap their arms around AI, including understanding what it can and cannot do, they’ve also found themselves helping stakeholders to understand its strengths and limitations.

Stephanie Marsh, the ResearchOps Lead at the UK’s Ministry of Justice, shared a research-specific example. They said, “If we don’t have the data, like when you’re talking about underrepresented groups, we can’t use AI to generate that data. We need AI to use the data to generate insights, which I think is a pretty common misconception: that it’s just going to create new stuff rather than synthesise what’s already there.”

Who would have known? We may still need researchers after all! (In case you didn’t pick it up, that was sarcasm.)

Finally, Stephanie Kingston, a UX Research Program Manager at Cisco, pointed out something promising, and, again, a sign of Schumpeter’s “creative destruction” at play. Stephanie shared the potential of AI “to accelerate and free ourselves [that is, ResearchOps] up for more of that creative, strategic work that we are so good at” and “we can automate the parts that...you know, probably aren’t giving us a lot of ‘work joy,’ and I think it’d be really exciting to see what sort of amazing, creative things that people can come up with when we’re not always like in the ticky-tacky weeds. So, really looking forward to the future on that.”

As Schumpeter wrote: “Depressions [or perhaps disruptions] are not simply evils, which we might attempt to suppress, but—perhaps undesirable—forms of something which has to be done.”

How Companies Operate Is Changing—So ResearchOps Must Change, Too

Post-pandemic economic shifts and AI have impacted all layers of society, including how organisations are designed—in other words, how they operate—and ResearchOps is not immune. Jenna Lombardo, a Senior ResearchOps Manager who’s worked most recently at Workday and LinkedIn, shared the following:

One of the most prominent and disruptive themes impacting ResearchOps this year has been the radical restructuring of organization design for both research and operations functions. I’ve observed a stark polarization: on one hand, once-mature, centralized operations teams are facing significant consolidation or dissolution, with core functions often being offshored or absorbed. On the other hand, we see a recognition of ResearchOps’ strategic value among emerging teams. These organizations are aggressively vying for budget allocation to establish their first dedicated ResearchOps role, signaling a clear understanding of its necessity for scalability and quality control.

I’ve also witnessed an accelerating shift away from traditional, decentralized UX research models toward hybridized research structures. For example, several major organizations are merging their user experience and product research capabilities with market research teams. It will be interesting to see how these shifts play out in 2026.

Jenna has done such an excellent job of expressing this theme that it’s hardly worth adding anything, except to say it will indeed be intriguing to see how these shifts play out in 2026. Watch this space.

Democratisation Is Still a Big Theme, but It’s Shifting

As budgets have shrunk and researchers have been laid off, an intriguing theme for ResearchOps has emerged: often the ResearchOps team, which could be a “team of one,” is retained with the mission to either continue or start setting up operations that support research democratisation—a term that barely needs explaining these days. Rodrigo Dalcin, Staff User Experience Research Operations at Wealthsimple, offers a pointed example: he is Wealthsimple’s only research hire, and research is entirely democratised. Far from a one-off, this is an emerging theme that research and ResearchOps leaders should be aware of.

Rodrigo shared: “I’m in a very unique position where I work in a company where research is 100% democratised, and helping the people who are doing research figure out things that are usually linked to the expertise of dedicated researchers has been a big theme. And that includes, for example, using creative, clever ways of getting them to make a decision around a research approach based on the time that they have to do research, based on how much knowledge they have over a problem space, or how much risk they’re dealing with has definitely been a big thing for me.”

What’s striking about Rodrigo’s story is that there are now opportunities for research operations professionals to own research entirely, which begs a big question: Should we own research entirely? I think research expertise is crucial, so either research leaders need to become better operators or ResearchOps folks need to become better research methodologists—and ideally both.

Finally, on the topic of democratisation, Luana Cruz, a ResearchOps specialist at Itaú Unibanco, makes a compelling case to think about how you deliver self-service programmes as you turn the page to 2026. She says:

I think the trend is that people are just finding out that self-service isn’t just a program or a document you’ve done once and will be forever useful. No. I think people are just finding out that self-service is about making people closer to research, either by doing it by themselves or by supporting their local researcher.

So for 2026, I hope we crawl back to the beginning when we were trying to understand how to scale research and ask ourselves: Are these self-service programs that we all grew fond of the answer for scaling research? Or is it just a palliative solution, and it was meant to end in the near future?

My gosh, it’s another excellent question! Write it at the top of your 2026 must-consider list and let me know when you’ve got the answer.

The Relentless Search for a Job

This article would not be complete without addressing the major theme of layoffs and joblessness. I’m sure I wasn’t alone in assuming that layoffs would peak in 2022 and that things would then get back to “normal.” Instead, it’s 2025 and layoffs are still happening. At this point, it’s almost trite to say that times are tough. That said, there have been success stories, such as Eric Levy, Director of Insights Operations for US Pharmacopeia:

For me, 2025 was a year of new beginnings. I’d been looking for full-time work since getting RIFed [RIF being “reduction in force”]. More than two years of active job searching—that was a lot of heartbreak.

If you’ve experienced that heartbreak, you’ll be heartened to know that others who’ve run the unemployment gauntlet have found work, too. Kasey Canlas, a UX ResearchOps contractor currently working at Amazon, is one such story. Kasey shared her story:

I spent the first seven and a half months [of 2025] unemployed after being let go, and it really crushed my spirit. What I learned about the ResearchOps job market is that it’s confusing. Organisations think they know what they want, they throw everything under the sun in the job description, and then you get to interviews and they don’t know how to interview for an ops role, and then you get to final rounds, and you ask for feedback, and you’re met with silence. Or we just found someone who was a better fit.

A misunderstanding of the ResearchOps role is certainly a problem for job seekers (and for hirers hiring the wrong people for poorly defined roles). Still, job descriptions are gradually improving as ResearchOps becomes better defined, and thanks in part to The ResearchOps Review and various Cha Cha Club productions, we’ll no doubt see continued improvements in 2026 and beyond.

Learning on the Job

If you thought AI had been covered, it rears its em-dash-loving head in the jobs market, too. Not only has AI revolutionised how talent acquisition teams operate, for better or worse—most stories point to worse, at least for job seekers—it’s also revolutionised the types of skills companies are including in job descriptions. I’m sure that statement is hardly a revelation, but this article would be incomplete without it.

UX ResearchOps Leader and job seeker Lydia Iana shared how her job-seeking experience has shifted over the past year. She said:

I feel like every job description now includes AI. They want you to have experience with AI and to automate tasks using it. ...And it’s a little bit difficult because all of these job requirements want you to have AI experience, but yet AI is still pretty new, so it’s kind of learning on the job, right?

It is a conundrum. Perhaps a short course on AI for ResearchOps professionals is needed to help bridge that gap? It’s not on my to-do list, but it should be on someone’s.

A Light at the End of the Tunnel

If you’re job hunting, Eric and Kasey’s stories have shown that there is light at the end of the tunnel, even if it’s in the form of a not-to-be-sneezed-at contract. And if you’re in the depths of job-seeking heartbreak or have a job but you’re worried how long it will last, here are some practical words from Stephanie Kingston.

I think the biggest thing I learned about ResearchOps this year is that we are very good at what we do, and there’s a lot of joy and a lot of pain in that, because you’ve seen a lot of elimination of ResearchOps roles this year. And I do hope, and I believe, and I think that the pendulum is going to swing back because ResearchOps people are creative and strategic—we are force multipliers.

We do so many things that aren’t apparent until we’re gone. And I think we are going to see a reversal of this negative swing that we’ve seen over the past year. And so, I’m very hopeful for that because there’s a lot of really incredible people out here doing this work, and we deserve all the love and support because we’re really good at what we do.

More than Ever, Community and Connection Are Essential

Finally, the theme that’s come up time and again during the tumult of 2025 is the importance of community and connection. As Kasey Canlas shared:

What really turned everything around for me was that I went to a conference and I got to speak with others who are in our field, and it really reminded me why I love what I do, and I love helping people. And it made me remember I’m not alone.

The Cha Cha Club, the members’ club of which this article’s contributors are part, is predominantly a virtual environment, but it gives members a space to connect. It helps them feel less alone, whatever their context or need. I often say to new members: “If you’re a team of one, you’re now a team of 200!”

Looking Ahead

From AI to layoffs and radical organisational changes, to an evolution in the scope of ResearchOps, 2025 has, without doubt, been a year of ‘creative destruction.’ But ResearchOps professionals are a motley crew of highly adaptive and inventive people. Over the past fifteen years, we’ve collectively, if not consciously, used the rapid scaling of research, the rise of the research technology sector, and the growing focus on data privacy to expand our remit in organisations. And with advancements in AI and the organisational changes we’re seeing in how products and services are built and delivered, we’re doing it again. So, here’s to an even more productive (or perhaps creatively destructive) 2026!

Brought to You By

This end-of-year wrap-up was made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

Participating in user research can sometimes be uneasy or even downright nerve-wracking. Whether it’s baring their soul in an interview or fumbling with a confusing interface, research participants are often asked to be vulnerable and honest in front of strangers. Sometimes they’re asked to describe a highly personal experience, which makes the process even more delicate. Imagine sharing your innermost thoughts about a sensitive topic, like financial hardship or mental health. How would you feel? And how would you want to be treated?

According to a study called “​​Emotional Risks to Respondents in Survey Research: Some Empirical Evidence,”1 individuals asked to report on emotionally distressing topics can experience psychological risks such as anxiety, shame, or an altered sense of self. This study reminds us that what might seem like a routine study to a researcher can have a profound and lasting impact on the participant. Earlier this year, a UX researcher friend told me, “We need to remember that for [research participants], it’s not just ‘research.’ It’s their life, their experiences, their feelings.”

Even seemingly low-risk usability studies can evoke unintended emotional reactions. As someone who manages teams recruiting thousands of participants, I’ve observed countless research sessions, and I’ve seen firsthand how participants can internalize design flaws and feel like it’s their failing if they don’t understand the design or what to do next. They might leave feeling inadequate or frustrated, which can impact their confidence—not to mention their perception of your brand. Sometimes, we even hear participants apologize after the session. Aguayo, a boutique firm specializing in user experience design and technology consulting, talked about this in their article, “Identification of Emotions: Forge Deeper Connections with Users through Emotion-Driven UX.”2 In it, they emphasized that “Emotions are a fundamental aspect of the human experience, and they play a pivotal role in our daily lives. When it comes to digital interactions, emotions can be the driving force behind user engagement, loyalty, and satisfaction.” This thesis confirms that, like any other action we take as humans, there’s an emotion attached to every digital and interpersonal engagement, and there’s always a risk that these emotions may be processed negatively. Sensitive topics, such as financial struggles or health challenges, can amplify these risks, making the need for thoughtful participant recruitment processes critical.

Implementing Empathy as a Strategy: A Little Goes a Long Way

So, what can we do to ease this emotional weight? We can start by going beyond the usual ethical checklist of consent forms, NDAs, and privacy clauses and create an environment of psychological safety throughout the research process. The UK’s Department for Education’s User Research Manual suggests the following:

• Screen for Emotional Risk. Carefully consider the potential emotional impact of your study and, during the participant recruitment process, exclude high-risk individuals from participating while making sure you’re not unfairly excluding marginalized voices in the process. As part of screening, ask open-ended questions about participants’ comfort levels discussing the topic, and discuss in advance what participation entails. For accessibility participants, inquire about accommodations that would facilitate comfortable participation.

• Train Moderators in Empathy. Equip your team with the skills needed to recognize signs of distress (e.g., hesitation or agitation) and respond with compassion. Sometimes, a simple acknowledgement of a participant’s feelings can make all the difference.

• Allocate Time for Debriefing. Verbally acknowledge and validate participants’ experiences and any challenges they faced during the research activities. You can prepare scripts or talk tracks to clearly communicate and affirm that any difficulties encountered are due to design issues, not the participant’s abilities.

By prioritizing participant emotional well-being, we can create research experiences that aren’t only ethical but are also more meaningful for everyone involved.

Building Relationships, Not Databases

Long-term studies teach us a powerful lesson: participants are not renewable resources. If all we do is keep returning to a group of participants without regard for their fatigue or trust in the system, we’ll erode both the quality of their feedback and the relationship. Think of your research participants as members of your community—you can’t build a strong community by treating people like they’re disposable.

And trust isn’t built overnight. It requires consistent care, open communication, and a genuine commitment to honoring participants’ time and contributions. In an article titled, “What Is Prolonged Engagement?”, qualitative software company, Qdacity, emphasized: “Prolonged engagement enables researchers to establish rapport and build trust with participants. By spending substantial time in the field, researchers can create meaningful connections and foster a comfortable environment for open and honest communication. This trust facilitates participants’ willingness to share personal experiences and perspectives, resulting in rich, in-depth data.”3

This principle is crucial for UX research (and research operations) because when participants trust us, they move beyond surface-level responses to share genuine frustrations, unfiltered reactions, and vulnerable moments of confusion—the exact insights that lead to meaningful design improvements.

In “Designing for Trust: The Crucial Role in Digital User Experiences,”4 Experience Design & Innovation Executive Vandhana Bhaskaran wrote that, “trust is a cumulative outcome of consistent and reliable experiences across the user journey.” She stressed the importance of creating a cohesive narrative across multiple touchpoints to foster trust over time, rather than focusing on isolated interactions. To move beyond superficial interactions and cultivate authentic relationships, here are some tried-and-true strategies:

• Track Engagement History. Maintain detailed records of how often participants are involved in studies. If this can be integrated into your participant management tool, all the better! This will help you prevent burnout, ensure fresh perspectives without overburdening the same individuals (and avoid sending them too much compensation in the form of thank-you gifts, which can lead to tax complications for everyone).

• Humanize Follow-Ups. Don’t just send a generic thank-you note to a participant. Rather, share how their contributions have specifically shaped product decisions. For example, “Your feedback helped us simplify our checkout process for millions of users!” This shows them that their voice truly counts.

• Make Consistency a Priority. Whenever possible, assign the same researcher or recruiter to interact with recurring participants. You can also leverage relationships within the organisation if you’re working with partners or suppliers. This helps build rapport and fosters a sense of familiarity, which can make all the difference.

As Kate Towsey detailed in her book, Research That Scales (Rosenfeld, 2024), “before getting lost in the minutia of scaling participant recruitment, knowledge management, or research ethics, to name just a few of the jobs of research operations, it is essential to exchange the jargon, trends, and clichés…for a pragmatic and comprehensive understanding of what these business words mean—really mean—both broadly and in the context of research.”5

Putting robust systems in place for recruitment, engagement tracking, and documentation isn’t about bureaucracy or checking boxes; it’s the practical foundation for building trust and sustaining participant wellbeing at scale. Thoughtful, operationally sound frameworks enable UX practitioners to move beyond ad hoc encounters to truly respectful, long-term relationships with the people behind your data.

Identifying Who’s Missing: The Problem with Exclusionary Practices

Despite best intentions, typical recruitment processes often exclude individuals with disabilities or those from underrepresented communities. Inaccessible forms, rigid session formats, and a lack of accessibility accommodations, such as screen readers and keyboard-only navigation, send a clear (and often unintended) message: “It’s okay if we don’t hear about you—or from you.”

It’s time we actively address and reconstruct this message.

Accessibility consultant Amber Qualm of the A11y Collective highlights the importance of keeping accessibility practices in mind. She emphasizes that accessibility is critical from the start of the UX process, not just as an afterthought. Ensuring accessibility in signup forms and research sessions allows people with disabilities to participate, fostering inclusivity and improving the usability of products for all users. In “How to Integrate Accessibility into UX Research,” Amber wrote, “Use the WCAG-EM methodology to check your work against accessibility guidelines. While automated tools like WAVE or axe can help spot basic issues, they’re just the starting point—not the whole story.”6

To create a truly inclusive research environment, you must start with a commitment to accessibility and a willingness to adapt processes to meet the needs of all participants. Here are some actionable next steps you can take:

• Design Accessible Invitations. Use plain language, captioned videos, and flexible scheduling options to make participation easier for everyone. As much as possible, consider offering multiple communication channels (e.g., phone, email, video call) to accommodate different preferences and needs.

• Normalize Accommodations: Don’t wait for participants to ask for help. Proactively offer adjustments, such as quiet rooms, extended session times, or remote participation options.

• Partner with Advocacy Groups: Collaborate with organizations to reach diverse populations. These groups can provide valuable insights and help you connect with participants who might otherwise be overlooked. Here are some examples:

  • Accessibility User Research Collective (AURC)

  • Knowbility

  • AbilityNet

  • People for Research

  • The A11y Collective

  • International Association of Accessibility Professionals (IAAP)

  • American Association of People with Disabilities (AAPD)

  • Accessibility Standing Group (Internet Society)

It’s also worth finding other country-specific accessibility groups relevant to your work, as well as local disability advocacy groups that represent specific disability communities. Know-the-ada.com offers a comprehensive directory of 25 Essential ADA Advocacy Groups you can reference.

Closing the Loop: Feedback as Respect

Imagine pouring your heart and soul into a creative project, only to have it disappear into the void without a single word of acknowledgement. Frustrating, right? That’s often how participants feel after contributing to user research. They generously share their time, thoughts, and experiences, but rarely hear how their input made a difference. As a result, many feel undervalued and disengaged from future participation opportunities.

Inclusion is foundational to ethical research, but ethics extend beyond recruitment. They also encompass how we close the loop with participants after studies conclude. Just as Kate Towsey wrote in Research That Scales:

“You should do more than simply lay out behavioral ideals in a code of conduct or give participants a form to sign. Instead, you should aim to make ethical and compliant practices part and parcel of how the research team rolls…The goal is not just to tick regulatory and ethical boxes, it’s also to empower researchers to do their best work, and participants and observers to take part, in ways that feel good for everybody.”

A 2024 study released by Aguayo’s editorial team found that participants who received updates about how their feedback influenced decisions were 63 percent more likely to participate in future research. Simple gestures like sharing product updates, thanking them personally, and sending a personalized thank-you email or gift can go a long way toward building goodwill.

This is not only ethical but is proven to be beneficial. An article by Mathew Sunil George, PhD et al, clearly discussed this: “sharing results can also increase participants’ sense of ownership of research outcomes, improve trust between researchers and participants and encourage participation in future research. Studies have also shown that participants consider receiving research results as a right.”7

Ready to show your participants that their contributions matter? Here are some suggestions about how you can create meaningful feedback loops that foster connection and build goodwill:

• Share Product Updates. Use email templates to share anonymized findings and explain how participant insights were used to shape product decisions. Be as specific and as transparent as you’re authorized to be.

• Celebrate Contributions Publicly. With obtained participant consent, you can highlight specific changes inspired by their feedback in newsletters, blog posts, or product announcements, where possible—giving credit where credit is due builds trust and reinforces the value of their participation. At Booking.com, we’ve also infused traveller and partner panels into live intra-company events, ensuring we’re able to plug customer centricity to the widest audience.

• Say Thank You Genuinely: Go the extra mile and create a personalized thank-you note, whether in email or in person. Personalized notes acknowledging a participant’s unique contributions make a great impact toward making someone feel seen and appreciated.

Making It Real: Creating Effective Feedback Loops

My fellow UX practitioners, we are more than just data gatherers. We are the guardians of human experience, especially during this AI boom! It’s time we remember to look beyond the personas and see the person, too. Whether it’s the parent juggling childcare during an interview, the student navigating accessibility barriers, or the survivor sharing their story in hopes of making a difference.

As researchers and recruiters, let’s acknowledge that categorizing people, using demographics, behavioral archetypes, or other labels, is often necessary to make sense of data and enable recruitment systems to function effectively. But when we treat the entirety of a person through the lens of simple labels—reducing individuals solely to corresponding categories for analysis’ sake—we risk obscuring not only their essential humanity but also the invaluable, nuanced insights hidden beneath seemingly surface-level interactions. The challenge, then, is to consciously build empathy and respect into these necessary systems—to proactively ensure our operational frameworks don’t strip away the human connection that yields both ethical practice and a richer understanding.

By embracing empathy, prioritizing psychological safety, and building authentic relationships, we can transform user research into more than a transactional exchange. This not only serves as a force for good but fundamentally shifts and improves how we source high-quality research participants—the ultimate driver of meaningful research outcomes. More than just the right thing to do, treating individuals ethically and respectfully is a strategic advantage. It unlocks the potential for transformative insights, cultivates high-performing, collaborative teams, and builds a truly customer-centric and successful business. It elevates our practice.

So, I challenge you to measure success not only by the number of sessions conducted or by how well the recruited participants align with the stratified criteria, but also by the positive impact our products have on the lives of the people who share their stories with us.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

Think back to activities you enjoyed as a child, such as puzzles, word searches, and connecting the dots. These activities trained your brain to view the bigger picture, spot the problem, then recognize patterns and build connections to solve them. What you may not know is that your love for activities like these has taught you to think in systems. In his book The Fifth Discipline, Peter Senge defines systems thinking as “a discipline for seeing wholes…a framework for seeing interrelationships rather than things, for seeing patterns of change rather than static snapshots.”1 And as a systems thinker, you focus on how the puzzle pieces work together to create a complete picture—how combining letters in a word search forms words, and how connecting a series of seemingly random dots produces an image.

In operations, it’s common to witness inefficiencies, duplicative efforts, siloed teams, and a lack of established processes. Teams often find themselves spending too much time and money with minimal return on investment, leaving hard work unnoticed or underutilized. I frequently hear shared pain points and frustrations expressed across multiple teams within an organization. Although everyone is (or should be) working toward the same end goal, it can seem as if teams are paddling in different directions instead of rowing as a unified force (or system) with a shared purpose.

I’ve worked in research operations or similar roles in many organizations—roles that have allowed me to inspire change and foster new ways of thinking about research. By intentionally connecting with different functions, I’ve identified opportunities for research operations to support and enhance collective efforts, ultimately improving the visibility, confidence in, and impact of research. Perfectly put in her book Research That Scales, Kate Towsey wrote, “Your primary work is gathering and coordinating existing expertise.”2 But it all begins with stepping back to view all the expertise and resources, and approaching them creatively—or designing—better ways for them to work together.

In this article, I’ll share key steps for leveraging systems thinking to solve ResearchOps problems and make a greater impact in your organization. These concepts are broad enough to help you work systematically and cross-functionally, and practical enough to apply and adapt to the challenges unique to specific contexts—and make lasting change.

Approaching the People Puzzle

In the early days of a new role, my introductory conversations with new coworkers can feel like therapy sessions. After a few earnest questions, trying to understand their experiences, these conversations often turn into long venting sessions about what’s currently not working for them. From there, I can’t help but want to jump in and fix everything! But to effectively solve any problem, I know I must first gather all the relevant information and understand what I’m dealing with in terms of the issues, the impacted teams or results, and any resources I might have available to optimize a solution. So, I go on a listening tour.

Go on a Listening Tour

I’m an introvert, so meeting and getting deep into conversation often feels daunting at first, but working with others and sharing skills and knowledge is ultimately energizing. I love getting to learn more about my coworkers. I start by learning about their professional backgrounds, how they came to be in their roles, what their priorities are, and what our opportunities for collaboration are—and I manage to glean some fun personal pieces of information, too. By the end of these chats, I’ve found a way to connect with each stakeholder on some level, whether it’s about the similarities in our needs and pain points or a shared vision for the future. I learn who my supporters are, who’s willing to collaborate (and occasionally, those who aren’t interested in starting something new together)—and all of it’s okay! This process helps me prioritize focusing my efforts towards the people and teams that will be most productive to partner with.

Whether you’ve been in your role for months or years, it’s never too late to embark on a listening tour. Whether it’s one of the first things you do, or you weave it into your role over time, you’ll be glad you did. Maybe you kick off your listening tour to understand what is and isn’t working for your stakeholders and cross-functional teams, or perhaps you simply drop casual coffee chats into calendars to introduce yourself and research operations. The goal is simply to start talking to people.

Connect with the End-Piece People

You know when you’re working on a jigsaw puzzle, and you make a beeline for those end pieces: the obvious first pieces that fit together? In the world of systems thinking, there may be teams that are obvious to engage with, like your direct partners, or product, design, and marketing groups. But the real key is to also connect with the outliers: the teams you may not identify as your immediate stakeholders or beneficiaries, but may offer undiscovered collaborative opportunities.

During one of my listening tours years ago, I met with the market research team, which, at the time, wasn’t working closely with the user experience research (UXR) team. It was through an outlier meeting that I discovered duplicative initiatives, including multiple teams working independently to build research participant panels for the same purpose. Granted, it was a huge organization, but this sort of doubling of efforts is equally common in small and mid-sized organizations. Through this realization, our teams decided to work together to build a mutually beneficial panel, sharing resources and budget to make it happen. Win-win!

Beyond your direct partners and stakeholders, I suggest meeting with other data or insight functions like:

• Consumer insights and market research

• Customer support and success

• Data analytics

• Data science

Engaging with these teams will help you gain a comprehensive understanding of the data available within the organization—a complementary and vital piece to strengthening the impact of insights in an organization. Then, meet with the engineering, creative, or sales teams. And don’t forget to connect with internal partners in privacy, legal, finance, IT, talent, and human resources, too. These centralized functions often have a more holistic overview of the organization, so it’s important they know who you are and what you do (and vice versa).

These teams can also help connect you with other potential partners. Some of my best partnerships and shared initiatives have emerged from outlier conversations. So, here’s a quick tip: after introducing yourself, ask everyone you talk to for recommendations on others you should meet, too. You’ll expand your web of connections and broaden your research system wider and wider.

Connect the Dots with Care

Once you’ve made connections with traditional and outlier stakeholders and started building bridges to connect the dots, it’s time to take action with the information, resources, data, and technology you have at your disposal. Here are a few ways to kick that collab into action:

• Build trust and close the loop. Openly and clearly document what you learned during your listening tour and report back to your stakeholders, highlighting themes, duplicative efforts you uncovered, and proposed solutions.

• Share the wealth. Share what you know and what you have that others can benefit from, like customer insights, tools, or resources you can make available to help everyone create efficiencies.

• Expand the sharing network. Seek out or build a community of practice to share strategies, findings, and resources more widely.

Find Communities of Practice

I first learned about the concept of communities of practice (CoPs) while working in research and impact measurement at a nonprofit organization. Anthropologists Jean Lave and Etienne Wenger-Trayner define communities of practice as “groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly.”3

While CoPs are common in the social sector, they’re also used (and useful) in the private sector, and they’re equally valuable in ResearchOps. Examples of ResearchOps-oriented CoPs I’ve run in the past include “insights coalitions,” “research enablement teams,” and champions for “research ethics/privacy,” and “accessibility in research.” What’s common among these examples is that they include a group of people with shared interests, collectively working together to accelerate a shared vision. Whether the collective work looks like dividing and conquering participant recruitment, sharing a templates database, or being particularly passionate about all things to do with accessibility in research, community practitioners all recognize the larger benefit from shared activities—and shared workload.

Build Communities of Practice

To establish a community of practice, align participants on shared goals and define what collective success looks like. Identify ways in which you can share your capacity to enhance your velocity and impact. In tech, your community of practice could be your insight coalition (multiple insight functions working together to provide holistic insights), “tiger team” (experts from different functions working together on a shared product/feature), or a working group. In the same article, Etienne and Beverly Wenger-Trayner describe different use cases or activities for communities of practice, which I’ve tied to some specific research operations examples:

• Request for information. Building a research repository (a place to find your insights/reports) and participant panel (a place to find details about your user base).

• Reusable assets. Developing assets for multiple teams, such as method templates, insights, and research guides, could benefit both researchers and people who do research (PWDRs)4 running research.

• Coordination and synergy. Consolidating resource needs, i.e., purchasing vendor licenses or credits in bulk, or leveraging a joint enterprise plan to preserve budgets across teams and functions.

• Building an argument. Sharing data to build stronger cases for getting things done or securing greater confidence in decision-making.

• Identifying gaps in competence. Leveraging individual skills and resources to fill gaps and source solutions, i.e., bringing in team members with coding or data analysis talent to automate or expedite manual tasks.

Use these community- and partnership-building opportunities to share your resources and insights with the people who can benefit from them most. Establish a regular touchpoint, open up your platforms, prioritize transparency, and introduce continuous visibility. Ideally, by working this way, the teams around you will learn that keeping all the puzzle pieces to yourself yields multiple weaker structures, while sharing and combining them allows you to build a system (or picture) that’s stronger and expandable.

Collaboration That Scales

Okay, so you’ve put the puzzle pieces together, connected opportunity dots from your conversations, and you’re building bridges with new functions. You’ve established shared platforms and knowledge, and coordinated initiatives to work on together—as a collective. Now it’s time to use all that work of coming together…for the greater good.

“The whole is greater than the sum of its parts.”

—Aristotle, a Greek philosopher

For ResearchOps teams, the mission is to scale the impact of research and insights across an organization. For research, the mission is to understand user behaviours and needs to support strategy and help the organization make data-driven decisions that grow the business. Regardless of the team or function, the shared objective is to make a meaningful impact on business priorities.

And there’s no time like the present to take initiative and identify opportunities to make an impact in different areas. Many insight functions lack operational support, which presents such an opening to fill that gap. For me, it was making these connections with other insight functions that led to shared tools (and cost savings), shared initiatives (like a newsletter), better collaboration (through an insights coalition) and more meaningful results for the business through optimizing mutual interest, goals, and common ground.

Stepping up to this challenge may add more to your workload, add some new recurring meetings to your calendar, and expand your stakeholder relationships, but if the end goal is to increase the overall reach and impact of ResearchOps—and therefore of research—it’s a puzzle worth solving.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

In the ever-evolving field of research operations, automation can be a real game-changer. Long before AI became the technology du jour, automations have been leveraged in the ResearchOps world to streamline processes, increase efficiency, and boost organizational awareness of past, present, and future research initiatives.

It can be tempting to use an automation tool to take care of everything that feels burdensome and repetitive—I’ve certainly succumbed to this temptation. Struggling to follow up with people who do research (PWDRs)1 on the status of their research projects, I’ve employed a Slack automation only to realize that Slack bots are just as easily ignored as me! (More on that later).

As the saying goes, “When all you have is a hammer, everything can look like a nail!” But automations aren’t a panacea: they take time to build, need maintenance to continuously operate well, and lack the warmth of human interaction. But by learning how to identify the right problems to solve through automation, not only can you save time and money, you can also help research deliver more business impact as a result.

Automate the Right Things

The day-to-day chunks of back-and-forth, mindless administrative research tasks can sometimes lead to tunnel vision. And I speak from experience here: it took me accidentally sending out a recruitment email to a batch of research participants using “To:” instead of “Bcc:” (and causing a minor data breach as a result) to realize I could use Gmail’s mail merge feature to build a spreadsheet-based mailing list and avoid the mindless copying and pasting altogether. This taught me to always prioritize automation for tedious, repetitive tasks that take a lot of time but don’t require a lot of focus, which can lead to mistakes—not to mention wasted time and talent.

In an age of what seems like a perpetual UX research reckoning, automating these tasks can not only significantly reduce the time and effort (and money) required to kick off a research project, but also free up the bandwidth of UX researchers, managers, and other valuable team members for strategic and influential work that generates measurable business value—a crucial point at all times, but especially in the current economic climate.

There are loads of things that, if automated, could improve a research process: recruiting a large pool of research participants, running internal surveys, following up with PWDRs on the status of their ongoing research projects, collecting contextual information in preparation for a research project kickoff, or importing raw, unstructured customer input into a research repository for further feedback analysis. But before you try to automate all of these, consider the following questions:

• Does the process you’re trying to automate involve a significant number of manual, repetitive tasks or steps that take up time that could be dedicated to high-level, strategic work?

• Is it part of a recurring ritual or cadence, usually taking place after specific activities, or on the same day of the week, month, or quarter?

• Does it require connecting or updating information across different sources, forming a base or starting point for more complex work?

If the answer to any of these questions was yes, then you likely have a good research automation candidate on your hands (see Figure 1). Otherwise, you’re probably looking at inefficiencies rooted in a different issue, such as too much organizational red tape or lack of adequate tooling…which might still be a great problem to solve, but may require a heavier lift than implementing a simple automation. Besides, automations aren’t just about machinery; they’re also always about people.

Consider the Human Factor

While leading research operations for an identity management SaaS company, I replaced post-research debrief calls (short meetings with everyone involved to review how the research study went, how the insights were used to inform product and business decisions, and to identify gaps and opportunities for improvement in the research process) with automated Slack surveys, thinking I’d save hours of work each month. Needless to say, the response rate plummeted. It wasn’t until a product team member told me that those debrief calls made them feel like their input really mattered, that I realized what the issue was. I’d optimized for efficiency but had forgotten that sometimes the human connection behind “meetings that could’ve been emails” (or Slack surveys) is precisely what made the process work. So, before you move forward with any automation work, consider the following question: Does this task involve human interaction that, if eliminated, would negatively impact the level of engagement required for the task to be effective?

While automation can bring numerous benefits, it can’t replace human interaction where it matters most. The most successful automation strategies in ResearchOps will be those that strike a balance between efficiency and personal engagement, leveraging technology to support and amplify human expertise rather than trying to replace it. The same can be said for emerging technologies like AI.

Work with What You Have

Now that you’ve identified the perfect automation candidate, the next essential step is to think about how to automate it with the tools at hand. Automation platforms like Workato or Zapier can help you integrate with existing platforms in your company’s tech ecosystem, but even if you don’t have access to these automation tools, you can still build automation into your workflows. For instance, you can use:

• Built-in Automations. Commonly used tools like Jira and Slack come with customizable workflows that can be used to automate tasks. This is particularly useful if they’re already largely adopted within the organization, requiring less friction and change management for users.

• Scheduling. Using your company’s scheduling tool of choice to automate booking of research sessions with research participants and observers, or to set up recurring reminders for tasks like following up with research participants or submitting research reports to the library.

• Templating. Any knowledge base or workspace suite like Confluence, Notion, or Google Workspace can give you the ability to create templates for research plans, interview guides, outreach emails, and reports, all while making them easily accessible to your team.

• Knowledge Management. AI platforms like Google’s NotebookLM and Glean can significantly reduce the toil involved in compiling different sources of knowledge into simplified documentation, such as a research methodology playbook. You can use them to reference slide decks created for internal training or workshops, as well as video recordings. Just remember to give credit where it’s due when referencing external sources.

• Sharing Research Findings. Many companies struggle with ensuring that customer insights reach the right people at the right time. Automated processes can help by:

  • Standardizing the format of research summaries and reports

  • Distributing findings to relevant decision-makers in your organization based on predefined rules (e.g., by themes, teams, customer segment or revenue)

  • Showcasing key research metrics and findings over time (e.g., using dashboards or reports)

• Coding. Google Apps Script in Google Workspace can be used to automatically populate a research tracker spreadsheet when a new study is initiated, generate and send personalized email invitations to study participants, or create a new project folder structure when a research request is approved. Learning programming languages with simple and readable syntax like Python can also be useful to create scripts and automate repetitive tasks like file organization or data cleaning, such as preparing raw survey data for analysis (I highly suggest starting with Al Sweigart’s Automate the Boring Stuff with Python, available for free here).

While each of these automations requires various degrees of commitment and expertise, they also present excellent opportunities for skill development, especially when it comes to mastering new tools and use cases.

Harness Automation as Strategy

Beyond the most obvious use case of reducing the burden of endless tactical work, research automation can become a powerful currency to obtain buy-in from tough stakeholders, establish cross-functional partnerships, and help boost the importance of user research in your organization—work that can elevate ResearchOps from a purely tactical role to a more strategic practice.

In one of my previous jobs, I used automation as a ‘partnership currency’ to enrich our research insights repository with feedback from various sources of customer feedback across the company. By proposing an initiative to gather all existing feedback data into a single, centralized place using integrations, I quickly obtained buy-in from multiple stakeholders willing to partner to unsilo customer insights, making them easily accessible to a greater number of teams or domains.

By effectively harnessing both the tactical and strategic potentials of automation while maintaining the core principles of human-driven support, ResearchOps professionals can elevate their role while freeing up time and resources to align research practices with business goals. This work can ultimately enhance the value and impact of user research within product organizations, which should be the fundamental mission of ResearchOps.

Start Small and Iterate

As you embark on your own journey to automate aspects of your company’s research process, remember to start small and iterate. Ask yourself the right questions, choose one or two good sets of tasks to automate initially, learn from the experience, and then gradually expand your automation efforts. This will allow you to build confidence in your approach and give your team time to adapt to any changes resulting from it.

And the journey is ongoing. As new tools and technologies emerge, there will be more opportunities to refine and improve how research is done—and how repetitive tasks are automated. The key is to remain adaptable and always question how to work smarter (not just harder) to support and elevate the research practice in your organization.

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally’s robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

ResearchOps 2.0 is brought to you by User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

In just ten years, ResearchOps has transformed from an obscure Silicon Valley speciality into a vibrant global profession. Despite economic headwinds, ResearchOps roles are emerging across industries far beyond tech, and the field is evolving at breathtaking speed. But where have we come from, and where are we going?

In this five-part audio documentary, we’re exploring the past, present, and future of ResearchOps—and it’s exciting, fascinating, and, at times, pretty mindblowing stuff! Each episode features the voices of Cha Cha Club members, senior research leaders, and the smart minds behind User Interviews.

To scale up, tune in!

In This Episode

In this fifth and final—”awwww”, we hear you say—episode of ResearchOps 2.0, we’re turning the spotlight on the people of ResearchOps: the curious minds, problem-solvers, and system-builders who’ve made this profession what it is today. We’ll explore who they are, where they’ve come from, and what drives them to transform how organisations learn from their users.

If you’re a ResearchOps professional, this episode will make you feel seen and heard. If you’re a leader looking to hire a ResearchOps role, this episode will help you think differently about who might hire. And if you’re looking to transition into a ResearchOps career, this episode will give you a great sense of the skills you need and the incredible profession you’ll become a part of. Here’s what this episode covers:

(1.05) About this Episode
(2.04) From Primate Welfare to ResearchOps: Daniel Gottlieb
(4.58) From Fishery Engineering to ResearchOps: Luana Cruz
(6.12) From Anthropology to ResearchOps: Garett Tsukada
(7.17) A Smart Start at Adobe: Tim Toy and a Three-Piece Suit
(9.38) A More ‘Traditional Route’ with Jared Forney
(11.23) ‘Hired by a Detective’ with Mia Mishek
(14.00) Levelling Up: Shaping Career Growth in ResearchOps
(16.13) The (Soft) Skills That Make Someone Successful in ResearchOps
(22.26) We Have a Lot to Learn from Product Management
(24.28) ResearchOps Pros Iterate—Constantly
(28.00) The Art of Convincing and Selling
(30.40) The Reality of Burnout (And Ways to Manage It)
(34.16) Knowing When to Say “No” AKA Strategy
(39.29) Ask for Help
(41.00) The Problem of Invisible Work—or Glue Work
(43.08) Making the Invisible Visible: Marketing Tips and a Case Study from Okta
(46.33) Everyone Has Impostor Syndrome—Even the Pros
(54.00) End

This episode features Daniel Gottlieb, Head of Research Operations for Microsoft’s CoreAI; Luana Cruz, Research Operations at Itaú Unibanco; Garett Tsukada, Head of Customer Connect UX Research Operations at Intuit; Tim Toy, the Senior Manager for ResearchOps at Adobe; Jared Forney, Research Operations Principal at Okta; Mia Mishek, Senior UX ResearchOps Manager at Target; ResearchOps specialist, Lydia Iana; Carolyn Morgan, ResearchOps and Enablement Manager at Cisco; Sam Gager, Senior Director, XD Research—Enterprise, Developer, Associate, & Accelerator, Capital One; and Erin May, Chief Marketing Officer at User Interviews.

Things Mentioned

• Cha Cha Club—a members’ club for full-time ResearchOps professionals

• Lenny Rachitsky and Noam Segal. “How Tech Workers Really Feel about Work Right Now.” Lenny’s Newsletter. May 27, 2025.

• Research That Scales: The Research Operations Handbook (Rosenfeld, 2024) by Kate Towsey

• Tanya Reilly. “Being Glue.” No Idea Blog.

• Emma Boulton. “The Eight Pillars of User Research.” Medium. The ResearchOps Community, July 11, 2019.

• Kate Towsey. “A Framework for #WhatisResearchOps.” Medium. The ResearchOps Community, October 24, 2018.

Brought to You By

A Cha Cha Club production, sponsored by User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

Credits

Produced and narrated by . Co-produced with Cha Cha Club manager, Glenn Familton, and ResearchOps experts, Jenna Lombardo and Renato Venter.

Aria, the robotic voice, was generated by Soundly. Explore the music and (most) sounds featured in this episode via this Epidemic Sound playlist.

Subscribe now

The ResearchOps Review is brought to you by Rally—scale research operations with Rally's robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack.

If your most recent workday involved managing bookings, getting customers what they need, organizing tasks with your coworkers, creative problem solving, and maybe cleaning up a few messes…then you probably work in a restaurant, a front desk, a storefront…or in research operations.

Before I moved to research operations, I spent fifteen years working in the food service industry—from fast food to fine dining! (That’s me taking the below photo.) I didn’t own clothing that wasn’t coffee-stained, and I learned how to love food that had gone cold because it was the only food I’d get to eat that day. I also worked with incredible, passionate people who could run circles around most corporate project managers (see Figure 1).

If, like me, you’d like to make a change from a career in hospitality, whether in a restaurant, hotel, hostel, kitchen, retail store, or at a front desk, while still doing what you love, this article is for you. I’ll explain how the things you love about working in hospitality can translate to a meaningful career in ResearchOps. And if you’re a ResearchOps professional who’s hiring, I’ll prove that the hospitality industry is full of talented folks with the ideal attitudes and skill sets to thrive in your team.

Three Core Areas

So, where do you even start when the thought crosses your mind, “Wow, I’d love a job where I can go to the bathroom whenever I want?” It turns out that people who can get stuff done are always in demand. But the gulf in industries—the big, yawning chasm of not having “office” experience—can seem vast and unforgiving. When you’ve spent most of your career in a hospitality role, it can feel like you’ll never find work doing anything else.

Here’s the best career advice I ever received (and sometimes the most depressing): three things can help you change your job or career, and you need at least two of them to do it: skills, knowledge, and luck. So you either need to be skilled and lucky, knowledgeable and skilled, or lucky and knowledgeable. On bad days, I refer to them as the “Unholy Trinity,” but today is a good day, so I’m going to call them “Core Areas.”

Skills

Let’s start with skills because, know it or not, you already have them! If you’ve ever handled reservations, inventory, schedules, service times, side duties, cash tills, tip pools, and many, many more daily hospitality duties, then congratulations, you already have plenty of research operations skills! You can apply those skills to common ResearchOps processes: learn how to make and manage meetings, explore the free version or YouTube tutorials of common tools, and sign up as a participant to user research websites to see the process.

Think about the things you like to do best at work. Does the sight of a well-timed reservation flow fill your heart with satisfaction? You should look into participant recruitment. Are you the person who reorganizes the entire store room? You might be interested in research knowledge management. Are you the person who always gets paired up with trainees because you know how everything works? You would probably enjoy program management. And plenty of other skills carry over with no translation needed, such as time management, communication skills, flexibility, and more (see Figure 3).

Consider the things you enjoy doing in your current role and how you might apply those same skills in research operations. You can do this at any stage in your career, as Emily Wever shared in her ResearchOps Review article “I Knew I Was Done When They Gave Me a Cash Drawer: My Mid-Life Pivot to ResearchOps.”

Knowledge

There are two main areas of knowledge you should be familiar with if you’re trying to break into the research operations industry.

The first area of knowledge you’ll need to study is UX research, for which, luckily, there is a myriad of free and affordable information available to watch, listen to, and read. Take online courses, watch videos, and read books. Absorb all the information and test it out or put it into practice wherever possible. I suggest starting with all the other articles in The ResearchOps Review, then move on to the recommendations at the end of this article.

The second knowledge area I recommend getting familiar with is service design. Service design has always been part of research operations, but it’s fast becoming a core component of these roles. If you get a good grasp of service design, you’ll even have a leg up on many current research operations professionals—and have the option to explore other careers that use service design, too.

To dig a little deeper, service design is the practice of considering all the parts that make up the whole of a service, how the parts interact, and how they come together to provide the customer (or researcher) with what they need, while also serving the business’s interests. This can sound a bit daunting, but if you work in hospitality, you’re probably already doing it. Here are some real examples from my life in hospitality that turned out to be service design all along:

• Figuring out the most efficient way to polish coffee cups so we didn’t run out during service—and the staff got to go home on time (see Figure 4).

• Assigning people to take charge of certain tasks throughout a brunch service so that everything gets done and nothing gets neglected.

• Standardizing how frequently we ran a contest so customers didn’t miss their chance to enter.

• Implementing standard procedures to mitigate allergies, so all diners could enjoy their meals (without ending up in hospital or curled up in a ball).

If you’ve ever looked at the way something was done and thought, “Hmmm, I bet we could make this easier, more efficient, or do it faster,” then you’re thinking with a service design mindset. Hospitality jobs often foster quick, iterative thinking that makes us great ideas people. Hold on to that way of thinking and use service design to turn those ideas into a structured reality—you’re doing the same thing, just in the field of user research.

Luck

Luck is ephemeral, unquantifiable and unpredictable. In my case, luck looked like this: I happened to chat with a research manager who was scoping out a ResearchOps role and knew that my receptionist experience would carry over. I was in the right place at the right time, and I think about that every day.

Luck includes finding yourself in front of the right person at the right time; But you won’t hit gold every time. You can find some incredible mentors and cheerleaders out there who will never be in a position to hire you. Or you can apply for a job at a company over and over, but never have your resume hit the desk of somebody who understands hospitality work. That’s the brutal truth.

Chasing luck can lead to a constant feeling of missing out or of not doing enough. It leads to the voice in your head saying, “What if I don’t apply to five jobs a day and I miss out on the one that would have hired me?!”

The good news is that you can make your own luck to a certain degree—or at least improve your odds. The bad news is that making your own luck takes a lot of energy, effort, and vulnerability. So take this next section with a heavy side serving of self-care, because it’s very easy to burn yourself out chasing what could be around the next corner.

The less brutal truth is that to increase your chances of finding yourself in front of the right person—increasing your luck—you need to meet as many people as you can. Networking is incredibly cliché, but it can also be the best way to do this. Start with people you know; the more somebody knows you, the lower the risk it is for them to take a chance on you.

And networking doesn’t have to be limited to ResearchOps people; use the UX knowledge you’ve picked up and start talking to designers, researchers, product managers, engineers—anybody who will give you their time. Every conversation is a learning opportunity. Augment that by talking to people who work in corporate or office environments; these environments are massively different from hospitality work and require a kind of relearning of their own. Use LinkedIn, participate in online communities like this Substack and ADPList, and check out local meetup groups.

Putting yourself out there can be grueling work, but it’s the best way to increase your odds of finding the person who will hire you. I don’t want to sugarcoat the realities of the research operations job market: it’s tough, but there are more roles every year. ResearchOps is a small but growing field. As you work on this transition, be gentle on yourself. It’s challenging, but worth it.

You’ve Got This

Research operations is a field that takes some of the best parts of hospitality—the pride of a well-executed service or making life more manageable for the people around you—and pairs it with the exquisite joy of being able to sit down or stand up whenever you want. Do I still sometimes eat lunch that’s been sitting out for hours and gone cold? Yes. But it’s because I got distracted working on something I love. Am I still joyfully baffled when I can just walk away from work at the end of the day? Yup! And I hope you get to feel that way, too.

Recommended Resources

1. Research That Scales: The Research Operations Handbook (Rosenfeld, 2024) by Kate Towsey

2. Just Enough Research (Mule Books, 2024) by Erika Hall

3. Good Services (BIS Publishers, 2020) by Lou Downe

4. Google UX Design Certificate

5. The ResearchOps Review (This publication!)

Sponsor and Credits

The ResearchOps Review is made possible thanks to Rally UXR—scale research operations with Rally's robust user research CRM, automated recruitment, and deep integrations into your existing research tech stack. Join the future of Research Operations. Your peers are already there.

Edited by and .

ResearchOps 2.0 is brought to you by User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

In just ten years, ResearchOps has transformed from an obscure Silicon Valley speciality into a vibrant global profession. Despite economic headwinds, ResearchOps roles are emerging across industries far beyond tech, and the field is evolving at breathtaking speed. But where have we come from, and where are we going?

In this five-part audio documentary, we’re exploring the past, present, and future of ResearchOps—and it’s exciting, fascinating, and, at times, pretty mindblowing stuff! Each episode features the voices of Cha Cha Club members, senior research leaders, and the smart minds behind User Interviews.

To scale up, tune in!

In This Episode

In this fourth and penultimate episode of ResearchOps 2.0, we’re exploring a timely topic: how to build enduring research systems even when change seems to be the order of the day—every day. You’ll hear top tips from experts who’ve managed to ride the winds of change to deliver successful, responsive research operations. Here’s what this episode covers:

(1.08) About this Episode
(2.12) Change Isn’t the Exception, It’s the Rule
(4.52) The Elephant-in-the-Room Topic: Layoffs
(11.55) Layoffs from an Economics Point of View
(16.30) But Layoffs Are Only One Form of Change
(20.18) A Real-World Transformation at LinkedIn: Taking an Initiative-First Approach
(24.05) Attach Yourself to Interesting Problems, Not Solutions
(25.25) You Must Deeply Understand the Business: ‘Read the Tea Leaves’ of the Organisation
(29.00) Work on the Highest Priority; The Biggest Bang for Buck
(31.24) Carolyn’s Top Tip: ‘Businessfy’ Your Work
(33.11) Enable People to Own Things on Their Own
(35.00) Build Adaptability Into Your Research Systems
(37.45) Setting Healthy Boundaries to Manage Constant Change
(40.16) Good Relationship Building Can Help You Manage Change
(41.18) Make Invisible Work Visible
(43.19) Managing the Human Cost of Constant Change: Building Resilience Within Yourself
(47.03) About the Next, Final Episode of ResearchOps 2.0
(48.35) End

This episode features Luana Cruz, Research Operations at Itaú Unibanco; Lexi Breitz, the Director for Research and Customer Insight at Headway; Mia Mishek, Senior UX ResearchOps Manager at Target; Carolyn Morgan, ResearchOps and Enablement Manager at Cisco; Lydia Iana, a ResearchOps specialist; Noel Lamb, the Senior Manager for ResearchOps at ServiceNow; Tim Toy, the Senior Manager for ResearchOps at Adobe; Rodrigo Dalcin, the Staff User Experience ResearchOps at Wealthsimple; Kalee Dankner, the Senior Manager for ResearchOps at LinkedIn; Carina Cook, Director of Product Insights and Operations (ESPN BET/theScore) at PENN Entertainment, Inc.; and Dennis Meng, the co-founder and CPO of User Interviews. What a lineup!

Things Mentioned

• Cha Cha Club—a members’ club for full-time ResearchOps professionals

• ‘The 2025 Research Budget Report’ by User Interviews

About the Next Episode

The next and final episode of this series drops on October 14th, and it’s dedicated to the people of ResearchOps: the diverse, smart, and incredibly authentic people who make ResearchOps what it is. We’ll cover major themes like burnout, making invisible work visible, and layoffs—the human stuff that’s defined our experience of ResearchOps over the past decade.

Subscribe to The ResearchOps Review to get smart thinking all about ResearchOps delivered straight to your email inbox.

Subscribe now

Brought to You By

A Cha Cha Club production, sponsored by User Interviews—the only solution you need to recruit high-quality participants for any kind of research.

Credits

Produced and narrated by . Co-produced with Cha Cha Club manager, Glenn Familton, and ResearchOps experts, Jenna Lombardo and Renato Venter.

Aria, the robotic voice, was generated by Soundly. Explore the music and (most) sounds featured in this episode via this Epidemic Sound playlist.