Hiring Isn’t a Scaling Strategy: Turning Research Expertise into Self‑Serve Infrastructure
by Lucy Sutton
Subscribe to get sharp thinking all about ResearchOps delivered straight to your email inbox. Thanks to our sponsors, it’s free.
The ResearchOps Review is supported by User Interviews, now part of UserTesting. User Interviews makes it fast, easy, and affordable to recruit participants so you can scale research without sacrificing quality.
Research operations is a peculiar profession. As ResearchOps professionals, we create value, and that value often creates demand that exceeds supply, squeezing the ResearchOps team’s capacity to support user researchers and creating a bottleneck. It’s not uncommon to be a victim of your own success.
I lead the ResearchOps team for the Department for Education (DfE) in the UK, where we’ve enabled hundreds of research studies and become adept at answering all sorts of questions on topics requiring specialist knowledge. A few years ago, I noticed that the better we became at answering researchers’ questions, the more dependent researchers became on us. They’d ask for sign-off on their participant consent forms, request help with their recruitment strategy, ask for suggestions on their discussion guides, and more. Providing guidance for methodological decision-making isn’t typically a ResearchOps responsibility, but they’d ask us anyway. If you work as a ResearchOps professional and you’re supporting your researchers in this way, you’re likely their best friend. But when the number of user researchers grows, and you’re unable to give them the attention they’re used to (and now feel they need), you’ll soon become their worst enemy: their perceived bottleneck.
Hiring more ResearchOps professionals to provide endless ad hoc assistance to more researchers isn’t a scaling strategy; it’s a staffing strategy. Increasing staff to continuously answer ad hoc questions isn’t a sustainable operating model. The real challenge for ResearchOps professionals is building infrastructure that works whether you’re supporting ten user researchers or 120 (which we do at the DfE as a two-person ResearchOps team).
To achieve this level of scalability, I had to shift from a support or service-oriented mindset to a system-design mindset. In this article, I’ll share how we stopped scaling one-on-one support, built self-serve infrastructure for repeat demand, made guidance not just instructive but actionable, redesigned processes when documentation wasn’t enough, and learned how to measure (and report on) researcher autonomy and flow, not just activity.
Stop Scaling Ad Hoc Support
In the DfE, the majority of our research collects data about people, for example: someone’s experience in school, as a parent balancing work and childcare, or being in foster care. Because our research often involves children, we take compliant and ethical data collection very seriously.1 Our community of researchers used to ask us countless questions about ethics and compliance, ranging from “Can we use this data to recruit research participants?” to “Do we need consent if they’ve already taken part in research?” and “What do we need to think about when we recruit vulnerable participants?” These questions were complex at first, and we answered them on a case-by-case basis. However, patterns quickly emerged, such as the most common circumstances, frequently considered researcher questions, and the most pragmatic approaches for resolution. Once I could see the patterns, I realised that the question-answer bottleneck wasn’t caused by the nature or scale of the questions. Instead, it was because the answers existed only in my team’s heads.
So I dedicated two weeks to writing a user research playbook on the General Data Protection Regulation (GDPR),2 the legislation that controls how personal information is used by organisations, including businesses and government departments, in Europe and the UK. Once the playbook was launched, we received fewer requests for support because people could make progress without waiting on us. But there was also a more subtle yet profound benefit. You can get away with less-than-perfect processes when you’re explaining them verbally, but written instructions are far less forgiving. In short, writing down instructions for how to use a system will help you find the faults in it—and force you to design better systems.
No longer requiring my time and attention, the GDPR user research playbook gave user researchers access to the guidance they needed when they needed it. Then several other UK Government departments contacted us to learn from and build on our processes. This success led us to work in the open and evolve the playbook into something even more impactful. In 2022, we created the DfE User Research Manual,3 a publicly available manual that contains all our policies, guidance, processes, and templates for consent forms and statements of work for participant recruitment. (You can make use of it, too.) As a result, DfE user researchers not only have a centralised place to review our research standards and learn how to improve their practice; they can also use it as a point of authority, showing less user-centred, design-informed colleagues why they do things a certain way. It’s a great way to say “this is how we do things here,” and evidence of the backing of their entire profession.
Build Self-Serve Infrastructure
It’s been four years since we launched the manual, and we’re continuously learning how we might support researchers more effectively. Currently, the manual is being rewritten so that its guidance is more actionable rather than simply explanatory: more “how to request a secure file folder,” less “consider the levels of encryption for your documentation.” We expect that user researchers already understand basic file storage, or can find out more about it on the DfE’s intranet. Instead, our guidance needs to be specific. For instance, it should tell them what the retention period for user research data is, who they can share data with within their team, and what to do if a participant requests that their data be deleted.
The point isn’t that guidance is good, and you should create lots of it; it’s that the systems you build should use your expertise, and your researchers’ collective expertise, as the infrastructure’s foundation. Aim to give researchers answers faster and in ways that increase their knowledge and confidence without draining your time—or their attention span. That’s a win for them, but it’s also a win for you: you’ll receive far fewer questions, saving time and reducing the need to task-switch. If the expertise is only ever in one person’s head, or the ResearchOps team’s heads, you’ve reached a hard limit on how much research can scale, and the value you can deliver. Knowledge is the infrastructure.
Redesign the Process, Not the Advice
Even excellent documentation will only get you and your researchers so far. Eventually, if your systems aren’t effective, you’ll need to stop documenting them and start redesigning them. This is where things move from focusing on the “research” (or the “researchers”) in ResearchOps, to focusing on the “Ops.” For us, that meant redesigning one of our key data protection processes: Data Protection Impact Assessments (DPIAs).
Legally, before a research study kicks off, we need to assess whether the research activity is high-risk and, if so, do an impact assessment. High-risk studies might involve thousands of people taking part in research, or collecting genetic or biometric data. Most DfE user research isn’t high-risk, but we still need a robust way of reaching that conclusion—it can’t just be vibes.
In 2019, the DPIA process was hard to navigate and use. It was written by people fluent in legalese, but it was meant to be used by people who were fluent in the practice of user research. For instance, a writer fluent in data protection would define “a high volume of data” as data collected from thousands of people. To a user researcher, “a high volume of data” might mean gathering data from twenty people in a single round of research. Both are accurate in their respective contexts, but only the first is accurate in the context of a DPIA. This discrepancy often led to seemingly endless back-and-forths between researchers and their data protection colleagues. Data protection colleagues felt like they were doing their best to implement a legal requirement, but researchers felt blocked. This is an example of an inefficient (and frustrating) system that couldn’t be fixed through better documentation alone.
Working closely with our data protection colleagues, we used the law, years of evidence on how research and data worked in practice, and service design techniques, such as creating service design blueprints and running co-design sessions, to redesign the process. We also provided the data protection team with user research and user-centred design (UCD) education, and invited them to attend research sessions. Now, what once took a researcher, on average, five hours takes minutes. Research is now more compliant, and ResearchOps rarely need to get involved.
Design for Absence, Not Availability
I’ll admit I’m not great at avoiding being the single point of failure, but unpredictable health has forced me to design for the day I’m unexpectedly out of action for weeks at a time. I had surgery last year and was away from work for three weeks, and, when I returned, nothing had burned down. (My ego took a bit of a hit, but I took solace in the fact that some of the things I had helped to create enabled that independence.)
It doesn’t matter if five or 500 people are reading the User Research Manual, following the DPIA process, or using one of our standardised consent forms; the process ticks along whether I’m there or not. Giving people the ability to act on their own is one of the most valuable (and scalable) process changes you can make.
In the rush to be helpful, many research operations teams inadvertently become experts at helping people navigate broken systems, hoping that one day they’ll have the time to fix or shut them down. But that kind of approach doesn’t lead to progress. The more valuable skill is to step back, study the root cause of the problem, then find the time, or make the case for the time and budget, to fix it. Identify ways to make the process self-serve, or at least low-support, assuming you can’t (or shouldn’t) fully automate it.4 For instance, rather than one-on-one sessions, run group onboarding sessions, pre-record a “hello” video, create an introductory pack along with a fortnightly drop-in session to welcome people to the team and help them settle in.
Take constraints as an opportunity to design systems that don’t create dependencies on you or your team, but instead give people independence.
Trade High-Touch for High-Leverage
Doubling the demand that’s placed on a system shouldn’t double the work that’s placed on you or your team. As a rule of thumb: design for ten times the number of researchers you have today. Not because you’ll necessarily reach that number, but because it forces you to build systems that don’t depend on heroic (unsustainable) effort, institutional memory, or a specific person’s availability to get the work done. Consider these criteria, too:
If a question is asked more than five times, it deserves a self-serve answer, whether via a playbook, template, decision tree, or automated bot.
If you or a team member is the only approver for routine work, you’re a bottleneck by design. Instead, replace sign-off with routing systems, standards, or audits.
If a relatively simple process takes hours, redesign it before adding more supporting guidance to a system that’s not working effectively.
This approach isn’t magic, and it won’t spontaneously solve the perennial problems of research operations. Instead, it requires a lot of prioritisation, which is sometimes uncomfortable. We can’t help individuals as much as we used to; I’ve had to cease services that provided value to individual teams because they didn’t offer enough value to the department as a whole, and our bandwidth is limited. (I don’t need to know you to guess that your bandwidth is likely limited, too.)
Instead, we prioritise investments in systems that maximise value across the department. Because our systems are designed to deliver to the masses, they’ve all got a bit of compromise built in, and they’re not seamless. But by delivering something that’s “good enough” for the many, even if not amazing for the few, we’re able to deliver more value to the DfE as a whole.
Measure Less Obvious Metrics
Eighteen months ago, our strategy was to embed a ResearchOps person within each area of the department’s work, such as schools, families, or skills, with my team acting as a “centre of excellence.” I never set out to build infrastructure for self-serve ResearchOps; I also didn’t set out to become a system or service designer, but it’s where my role as a ResearchOps professional has evolved.
It’s taken a long time to get to this strategy—around six years. In my first ResearchOps role, the list of needs was endless, and everything seemed to have the same level of urgency, so I prioritised whatever I could do quickest. I was also learning the ropes myself, so I did what was familiar. Six years on, however, I now have an extensive understanding of the role of ResearchOps and how it operates in government contexts specifically. So I regularly ask myself these three questions:
How does this specific part of the system fit into the overall researcher journey?
How will it benefit the DfE?
If the system does neither, it’s probably not the right call. If it does both, I then ask myself: How will we measure its success?
Now more than ever, it’s important to show a return on investment for research operations teams. To survive, your value must be made visible, but easy as that is to say, it’s difficult to do. Much of the work of ResearchOps is invisible and anecdotal. I have infinite examples of when things have worked or failed, but it’s not in the form of structured data. In the past, I’ve tried to do benchmarking surveys, but response rates are low, and the people who do reply are typically the most engaged and conscientious, skewing the data.
Activity Is Not Impact
To measure the impact of our research systems, I can do the glaringly obvious. For instance, I can do the simple maths required to calculate how much money we’ve saved by rethinking how we buy research incentives; I can average how long the DPIA used to take before the new process and multiply it by how many people have submitted the form that’s part of the audit trail. Last month, we saved user researchers thirty-seven hours (a full UK working week), without it taking a minute of our time.
Those are good metrics to track, but the ones I personally focus on are less obvious: maintaining a quiet email inbox, being able to easily answer questions, hearing “thanks, that’s so helpful!” responses from researchers, or spending an afternoon where I can ignore my notifications and crack on with something more strategically important.
The key point is that activity is not impact. I don’t measure tickets closed or requests completed, because they’re vanity metrics and don’t communicate a return on investment. For instance, giving someone a software license doesn’t necessarily mean that the software they can now access makes their job easier or more effective. I can respond to questions on the ResearchOps support channel, but answering questions doesn’t address the reason they were asked in the first place, or necessarily prevent them from being asked again. Instead, my organisation and I care about the amount of time saved, the number of inconsequential decisions removed, and the overall improvement in researcher autonomy and, therefore, velocity—the word of the moment. Researchers being able to deliver great research without needless friction is the true impact for me and my team.
Create True Scalability
Because we’re now working more strategically—and as system designers not system administrators—we’ve been able to address and resolve backlog issues that we know will deliver value to the DfE and make life easier for researchers. We’ve rewritten five guidance articles, made a video encouraging people to sign up to take part in research, and created both the process and capacity to deliver research incentives in-house. As ResearchOps, we’re now making progress on building core infrastructure rather than keeping our heads above water.
Scaling research isn’t about completing more tasks or hiring more staff; it’s about building systems that keep working when demand increases, priorities change, or when you or your team simply aren’t available. If your team can only deliver value because a particular person knows the answer, can approve the request, or remembers the process, your operations are running on dependencies. If research can continue to function when you’re not available, you’ve built research infrastructure that is truly scalable.
The ResearchOps Review is made possible by User Interviews, now part of UserTesting. With a vast participant network, precise matching, and fraud prevention, User Interviews can reliably fill any research study. Source, screen, track and pay participants, then move seamlessly from data collection to deep analysis, all in one place. → Learn more about User Interviews for ResearchOps.
While data collection and processing must comply with relevant legal, regulatory, and organisational requirements, these frameworks don’t always address broader moral considerations. Ethics provides an additional lens for decision-making and focuses on values such as respect, fairness, honesty, and integrity. While ethics guides researchers towards what ought to be done in a given situation, compliance establishes the minimum standards that must be met.
Data protection legislation controls how organisations, including businesses and government departments, use personal information. In the UK, data protection is governed by the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.
"User Research: Guidance and Support for Any User Researcher Working in Department for Education." User Research Manual. Department for Education, Accessed August 7, 2026. https://user-research.education.gov.uk/.
In “The Transformative Power of Automation: from Enhancing Research Efficiency to Catalyzing Strategic Change” (The ResearchOps Review, 2025), Rodrigo Dalcin shares a matrix to help decide when to automate and when a manual approach is more appropriate.
 | A guest post by
|