A Practical Guide to Structuring ResearchOps Through Organizational Change
by Carolyn Morgan
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 Kate Towsey and Katel LeDu.