Common Research Ops Questions Answered: How to Get Headcount for Research Ops
UserZoom recently invited me to speak at one of their webinars, so I shared my ever-evolving talk about the war stories and triumphs I’ve experienced in building Research Operations at Atlassian—along with a specialised team to make it all happen and keep it all happening. To give away the talk’s punchline, the biggest triumph is this: as a team of six, we’re now sustainably and scalably supporting 400+ researchers and Atlassians who do research (Designers, Content Designers, Product Managers, Marketing Managers etc.) in doing more efficient and compliant research on their own.
It must be said, though, that with the right resources and skills in place, we’d love not just to help Atlassians do more efficient, better, and compliant DIY research — more isn’t always better — we’d also love to help them 1. access extant research and 2. get professional research skills onboard. Research Ops isn’t just about making the doing of research easier and easier so that more and more people can do ever more research. Instead, it’s about operationalizing for efficiency — just the right amount of high-quality research done with respect, done well and used well.
During the UserZoom webinar, there were several audience questions that I didn’t have time to answer, and so arose the opportunity to write a series of three, quickly thrown-together blog posts to answer those questions one at a time. I hope the answers will be useful to you.
When you’re asking for headcount to hire Research Ops humans, what tactics have been effective in helping the business understand the return on investment of the headcount?
If you’re a researcher trying to argue the case for bringing Research Ops into your organization, my answer to this question is unlikely to meet your needs. I’m a Research Ops professional, so I’m always hired into a company where the leader already believes Research Ops is needed — they’ve reached out to me, after all. They might not have a clear idea of what Research Ops takes and how it should be delivered, so it’s my job to inform, educate, communicate and negotiate realistic expectations before I arrive (and continue to communicate them once I’m on board). If there’s one thing that’s true in Research Ops, it’s that it’s wildly underestimated — both in its individual parts and as a whole. So, assuming you’ve been hired to deliver Research Ops as a team of one, as is so often the case, my answer below should be useful to you.
Five tips:
1.Before you accept your role, make sure you’re being hired with the expectation that you’ll be empowered to deliver scalable Research Operations and not research administration. I talk about the difference between Research Ops and admin a lot—given half the chance, I’d talk about it until I’m blue in the face (and you are, too!) If you start by delivering full-service research admin and support e.g. delivering end-to-end participant recruitment as a recruitment agency would, you’ll quickly get stuck in the mud and never have time to deliver actual operations, which means your potential impact will be stunted. I speak from experience here. If you’re going to deliver scalable operations, you must start by delivering self-service operations — which may later include elements of full-service once you’ve got the maturity and headcount to support it, which could take years.
If you remember nothing else from this post, make it this: admin is not operations — though operations, like everything else, will eventually involve admin. Instead, when you hit the get-go button, start with self-service operations, then, once you’re scalable and sustainable, and if appropriate, include full-service elements where it’s needed most and for the people and projects that need it most. In time, this will help you show your return on investment and develop trust, which, in turn, will help you make the argument for headcount.
Tip number two…
2. Once you’re settled into your role, it’s wise to gain a solid understanding of the context for research in your organization and, while you’re at it, start building a solid network. Who does research in the organization? Who are you expected to support and how? What kind of research do you need to support? What is the state of research data governance and ethics? What do people (all the people who care about research) want fixed the most? The information you gather, and the network you build in gathering it, will help you decide and communicate the primary wins that you should focus on operationalising first and who could help you achieve it. Prioritisation is everything in Research Ops — Rome wasn’t built in a day, and neither will your operations.
Once you’ve identified the biggest pain points in the organisation, prioritised the easiest and most meaningful wins, and forged potential partnerships, you’re ready to make the case to deliver a manageable set of scalable (self-service) things. How does this help prove the case for headcount? If you can deliver reasonably quick, tangible, and meaningful wins that address your biggest stakeholders’ want-iest wants, you’ll have built confidence in the fact that you can affect positive scalable change without needing more and more headcount to do the job. Building trust won’t mean for instant headcount, but it sure makes the case much more compelling! With trust, you can much more easily argue: Just think what we could do with another headcount who could deliver xyz! And, because you’re already delivering scalable things, you’re not going to look like a constant money drain. Keep your cost-centredness low and your value-centredness high.
Here’s an example of an easy-ish win: if access to research participants is the biggest pain point — When is it not? — you’ll want to onboard a tool like UserZoom that offers built-in self-service participant recruitment as part of its core offering, or a dedicated self-service platform like User Interviews, Respondent or Askable. It’s highly unlikely that one tool or tactic is ever going to solve all your researchers’ participant recruitment needs — they’ll still be crying for recruitment to be fixed — but delivering something that satiates a portion of the need (and isn’t a huge time or immediate financial outlay — many of these tools are pay-as-you-go) is just what you need to show low-risk value from day one.
3.While you’re doing your networking and question asking, you may discover a strong call from other parts of the business to fix how things are working in research land, too. For instance, Privacy might be heavily invested in you delivering operations that support legally compliant research practices. Account managers may want you to better manage how customers are accessed for research. The wider business might want you to zone in on accessibility research. And so the list goes on. Here’s the tip: researchers (and people who do research) aren’t your only stakeholders, which means that researchers aren’t your only potential headcount investors, either. You may find that teams, like Privacy, if they care enough about the work you could do, may be able to either help fund the headcount you collectively need or, more likely, offer you a partnership to support the work — formal headcount isn’t the be-all and end-all — or, at the very least, help embolden your headcount ask.
4. So you’ve got things moving, you’re showing tangible and measurable value as a team of one or two, and you want to build the case for your next headcount. There are two scenarios: 1. you want to increase the scope of something you’re already delivering or spread the emerging admin and maintenance, as is often the case 2. deliver something completely new. Let’s look at them both.
Increase the scope of something you’re already delivering
If you want to scale or increase the scope of something you’re already doing or re/allocate the maintenance of it, it’s useful to show the measurable impact of it: we’ve helped lower the recruitment time from two weeks to one; we’ve supported x recruitment projects in x months; we’ve saved x amount of money; we’ve increased the quality of participants etc. — whatever is most meaningful in your context. As an example, at Atlassian, I’ve got an Ops person to AWDR (Atlassians who do research) ratio of 1:80. This means that for every 80 AWDRs I invite to use our Research Services, I need to hire one more Research Ops Admin to support it all. What we are offering is very scalable. As a result, I’ve got a valuable bargaining chip that’s based on past delivered impact, scalable operations that are being used, operational metrics, a healthy Ops to researcher ratio, and, last but not least, the need — people want what we’ve got and we could give it to them… if we had one more person to help…
Deliver something completely new
If there’s an ask for a new Research Ops element to be delivered from scratch, the story is a little different: it’s very rare that you can deliver an element of Research Ops sustainably without hiring a senior, specialized and dedicated headcount to look after that need — knowledge management, ethics and privacy, education, team care and so on, they all need specialist skills and knowledge and they’re all full-time jobs. In this case, don’t fold on headcount. Sit tight. You’ve built trust. You’ve got a great track record. You will only deliver disappointment if you don’t ask for the skills, resources and time you need to set yourself up for success. Be clear that you’d love to solve the problem, then empathetically allow the organization to feel the pain of that problem until the resources are found. People who work in Research Ops are often fixers — we love to solve problems — so we tend to want to fix things in whatever way we can even if the fix isn’t sustainable. Don’t do it. In the long term, that kind of approach means you’ll be putting too much capital into short-term satisfaction (candy floss Ops) at the expense of delivering truly durable work that proves it’s worth — and ultimately your and your team’s worth over time.
Last but not least…
5.Research Ops requires such a diverse set of skills to deliver, you can make excellent use of just about anyone who knocks on your door. I’ve got people with IT, marketing, procurement, and HR backgrounds on my team — I’m sure one day they’ll be superstars of the Research Ops world. So get creative: hire a contractor so you can show the value of the role, then work to negotiate a full-time role. Internal transfers and secondments are another way to grow your team. Working closely with promising juniors is yet another excellent (and fulfilling) route for getting the diverse set of skills you need onboard.
When I’m not managing Research Ops at Atlassian, I’m writing a book called Research at Scale, which will be published by Rosenfeld Media sometime in 2022.
