Ask a researcher what they did this week and you might hear: chased participant incentives, rebuilt a consent form from scratch, hunted for a study someone ran last year, negotiated a tool renewal, and, somewhere in the gaps, did some research. Research operations, usually shortened to ResearchOps, exists to take everything on that list except the research itself and turn it into infrastructure.
The simplest definition: research operations is the people, processes, and tools that let research happen reliably and at scale. Researchers still do the craft. Ops makes sure the craft is not constantly interrupted by logistics, and that what gets learned does not evaporate when the project ends.
What research operations actually covers
ResearchOps is broader than most people expect. In practice it spans:
- Participant recruitment and panel management · sourcing, screening, scheduling, incentives, and the unglamorous work of keeping a panel healthy rather than over-contacted.
- Governance and ethics · consent, data protection, retention rules, and knowing exactly where every recording lives and when it gets deleted. Under GDPR and its cousins this is not optional paperwork; it is the licence to operate.
- Knowledge management and repositories · making past research findable, so the same study is not run three times and insights outlive the deck they shipped in.
- Tooling and vendors · choosing, buying, and administering the research stack, from transcription to testing platforms, so individual researchers are not negotiating contracts alone.
- Process and templates · discussion guide templates, briefing formats, quality standards, and onboarding for new researchers and for colleagues who run their own studies.
The ResearchOps Community's "eight pillars" framing is the best known map of this territory, but the shape is consistent everywhere: everything around the research that is not the research.
Why ResearchOps emerged
Two pressures created the discipline. First, research scaled. Teams that once had a lone researcher grew to ten, and the things a single person held in their head, where the recordings live, which participants are fresh, what we learned last spring, stopped scaling with headcount. Every researcher was rebuilding the same machinery, badly, on the side of their actual job.
Second, more research is now done by people who are not researchers. Designers and product managers run their own studies, which multiplies output and risk at the same time. Someone has to make the safe path the easy path.
There is a worthwhile historical footnote here. Market research has had operations for decades: fieldwork managers, panel companies, tabulation houses, strict codes of conduct. The agency world industrialised all of this long ago. What we now call ResearchOps is largely in-house UX research rediscovering that infrastructure, with repositories and self-serve research added on top. The two traditions differ in plenty of ways (market research and UX research answer different questions to begin with), but their operational needs converge on the same four things: participants, compliance, knowledge, and tools.
When a team actually needs it
Not every team needs dedicated ops. The honest signals that you do:
- Researchers spend a large slice of every week on logistics rather than thinking
- You have discovered, more than once, that a new study duplicated one from last year
- Consent forms and recordings live in personal drives, named inconsistently
- Every project starts from a blank page: new screener, new guide, new folder structure
- Colleagues outside the research team are running studies with no guardrails
Notice that the trigger is research volume, not researcher headcount. A four person team supporting heavy self-serve research can need ops before a ten person team that runs a handful of studies a quarter. The question is not "how many researchers do we have" but "how much research happens here, and what does it cost us when the machinery fails".
First hire or distributed ops
There are two workable models, and one common failure mode.
The distributed model: each researcher owns a slice. One maintains the repository, one owns the panel, one keeps templates current. It costs no headcount and keeps ops close to practice. Its weakness is that ops becomes everyone's second job, so it gets done in the gaps, unevenly, and it collapses whenever delivery pressure spikes.
The dedicated hire: a research operations manager or coordinator whose whole job is the machinery. A first hire usually pays for itself fastest on the participant pipeline, because recruitment is the most frequent and most painful bottleneck in most teams. Repositories and governance tend to follow.
The failure mode is hiring ops as an admin and giving them no authority, so process changes never stick. Ops is a practice discipline, not a booking service: a good ops person designs systems, negotiates with legal and procurement, and shapes how research is done across the organisation.
And if you are the lone researcher reading this, you are already doing ops, just invisibly. Make one piece of it explicit this month: a template folder, a consent checklist, a simple log of past studies. Future you will be grateful, and so will whoever joins you next. It is also exactly the kind of craft-adjacent problem worth comparing notes on with a wider community of researchers, because almost every team has solved some corner of it already.
The quiet argument for research operations is that craft deserves infrastructure. Nobody questions that engineering needs build pipelines or that finance needs controls; research earns the same treatment the moment its output matters to the business. Get the plumbing right, and researchers get to spend their attention where it belongs: on people, not logistics.
People of Research is a community and newsletter for UX researchers, market researchers, and the ops-minded people who keep research running. Join us and get the good stuff in your inbox.