Why we’re building an Ops-First Research Practice
Back in March 2018, after #ResearchOps on Twitter had gained some momentum over the previous ~6 months (Louis Rosenfeld may’ve been the first to adapt the term from academia in September 2017), a single tweet by Kate Towsey sparked a movement that became a worldwide phenomenon and has fundamentally reshaped the way teams think about Research:
Since then, the ResearchOps Community has grown to over 7700 members 🤯, spawning dozens of Medium posts, a handful of local meetup groups, presentations at Research events and conferences, and even a Research Ops Day at the UXInsight Conference. While I missed the initial tweet, I managed to join the community in April 2018 and was immediately surrounded by other people who were thinking the same things and having the same discussions I was: how might we make Research more efficient, more impactful, more ethical, and more scalable.
If we go down the rabbit hole for a bit, my passion for Research Operations is a direct evolution of my academic background. I didn’t set out to be a User Experience professional, but I couldn’t’ve picked better opportunities in undergrad to prepare me for it (so much so that I’m now working with my alma mater to create a certificate program to help students enter the UX profession 😉). When people ask me how I got into the field, I have to go all the way back to being 17-years-old, trying to figure out what I wanted to study and where I wanted to go for college.
I decided, at that point, I would study Psychology and Computer Science, because I wanted to understand people and make video games 🤓 I wound up at the University of Rochester because they were the only school I talked to that said “Sure, come here and study both. Our students double-major in unrelated fields all the time!”.
I spent the first two years mostly studying these two fields in isolation, focusing on Social Psychology, Motivation, and Research in Psychology and Artificial Intelligence in Computer Science. It wasn’t until Dr. Carman Neustaedter taught an Introduction to Human-Computer Interaction class as an adjunct that I discovered HCI (the academic side of UX), and similarly to when I discovered ReOps, something clicked.
In retrospect, it’s a natural fit (which reminds me of Steve Jobs’ Stanford Commencement Address story about connecting the dots). My training in Computer Science gave me the inclination to think like an engineer and to focus on efficiency, modularity, elegance, and repeatability. My experience working with the Approach-Avoidance Motivation Group and in the Honors Program in Psychology gave me a rich, thorough, and practical understanding of how to design, execute, and analyze Human Subjects Research.
One way to think about Human-Computer Interaction is the intersection of technology and humanity; one way to think about Research Operations is the intersection of engineering and research.
That’s a great story…but what _is_ Research Operations?
Shortly after Kate started the ReOps Community, we began to have conversations internally to figure out exactly what everyone’s definition and understanding of Research Operations was. This lead to the community’s first major project: the #WhatIsResearchOps (WIRO) global workshop series. Research Operations was (and, in many ways, still is) in its infancy, and the community that formed around it was taking strides to define this new discipline. Being a community of Researchers, of course the way we did that was to conduct research (surveys, interviews, workshops) and analyze the results to produce the Research Ops Framework:
The above diagram is a map of all of the different things that support Research. If your first reaction is “wow, that’s a lot”, that’s probably the right reaction 😂 It turns out there are all sorts of things that go into Research. This includes some of the common/obvious things, including the methodology itself, recruiting (the bane of all researcher’s existence 🙅), and tools. It also includes things that may not immediately come to mind when you think about supporting Research, such as data governance, knowledge management, and resourcing.
This is the definition we came up with as a community. I often describe the work I do as “trying to automate myself out of a job”. It’s not an inaccurate description, as the time I save through automation, templatization, consistent process, etc., I can repurpose for more impactful work.
I’m passionate about Research because ultimately it saves time and resources when building products, and produces better experiences for end-users. I’m passionate about Research Operations because it saves time and resources for People Who Do Research (PWDR), ultimately leading to more research (or more impactful research).
ResearchOps people have one mission: helping researchers do their best work.
— Brigette Metzler
Why build operations-first? We need Research now!
If your company is like every company I’ve ever worked with (and there’re ~40 of those), there’s probably a lot of pent-up demand for Research. You’re going to face opposition if you get hired into a Research role and tell everyone your #1 priority is anything but “do research”. Hopefully this section will prepare you to make the argument that ops-first is the way to go.
There are three key benefits to this approach, which we’ll cover in more detail below:
- Ops supports your current People Who Do Research (PWDR).
- Ops makes it easier to hire & onboard new Researchers.
- Ops is inherently strategic.
Democratization of Research
In most cases, your company is already doing Research. They might not call it Research, they might not have a Confluence space, a dedicated team, a Center of Excellence for it; whatever 💁 There are people who gather feedback from current and potential customers and users, and they use that feedback to make decisions.
Your job, as a ResearchOps champion, is to support those people by creating repeatable processes, giving them additional tools, helping manage the knowledge they generate, and increasing the quality of the research they do.
What I’m talking about here has become a hot topic in the Research world lately, and maybe even a bit of a dirty word: democratization.
Democratization of UX research is an approach that centers on empowering various teams within an organization to conduct UX research, analyze the results, and take action on them.
— John Kille, UXMatters.com
As an Ops person, I see democratization as an inevitability. Research isn’t a job title: it’s an activity. Instead of trying to hole ourselves up in our ivory tower and build walls around the garden of Research, what if we see ourselves as the ones that facilitate that process?
Those that take a hard-line against anyone but Researchers (which…who gets to determine who’s anointed as a “Researcher”? 🤔) doing research is more worried about job security than what’s best for their organization. Does that mean we don’t need Researchers at all? Hardly. Instead, we should be clear about what things our teammates can do themselves and what they need additional expertise and support for.
Proper democratization is about freeing your most experienced, talented, and dedicated Research practitioners to focus on more impactful and more strategic work instead of being caught up executing tactical research. Jen Cardello has an excellent talk from the 2019 Design Leadership Summit that provides more detail and explains everything with more elegance than I could ever hope to 😁
Investing in Operations can vastly increase the throughput of your People Who Do Research. We’ve seen an 8–10x increase in the amount of research being executed across all of Auth0 per quarter since I joined, and almost none of that is research my team is executing first-hand.
This goes for headcount, as well. Most people, if given headcount, will go out and hire Researchers, growing the Research team from 1 to, say, 4 (a 4x increase! Put it on your resume! 🙄). If you’re supporting 200 teammates, you’ve certainly improved your ratio of Researcher to Supportee (1:200 → 1:50), but what if you used that headcount on Operations hires instead?
If you convert only 1 out of 4 of those Supportees into People Who Do Research, those 3 hires would shift the ratio to 1:4. Even if those PWDR operate at 1/4 capacity of a dedicated Researcher, your ratio still improves to 1:16 (a ~3x improvement over just hiring Researchers 💥).
Scaling your team
When talking about why operations-first is the way to go, I often borrow a metaphor from one of my mentors, Tomer Sharon. Research is like a freight train: it has a lot of power, force, and momentum, and the ability to create change. If you go out and hire a handful of Researchers, they’re all going to come in with their own strategies, tools, methods, frameworks, and processes; you’re hitching more cars to that train and maybe adding a few extra engines as well. However, you haven’t built any stations or laid any rails, so the more people you add, the larger the train wreck 🚂
Instead, we build those stations and lay those rails by preparing a baseline strategy, process, toolkit, and playbook (among others) for new hires to walk into. Every new hire will bring with them ideas on how to improve it, but by having a common onboarding experience and centralized, existing resources to work from, nobody spends any time reinventing the wheel 🤸
There another hidden bonus to this: your playbook serves as educational material for individuals who are newer to Research (dedicated hire or PWDR). Imagine walking into a new company where they have a set of guides for not only how the company does research, but a number of new methods you’re unfamiliar with. Now you can self-direct your learning without as much time and oversight from your more-senior teammates 🎓
Ops is inherently strategic
A common conversation you hear at design/research conferences, meetups, or Slack communities is the struggle to be seen as a strategic partner or resource and instead are relegated to tactical support. There are no shortage of thought pieces about how to get a “seat at the table”. Instead of adding to that noise, let’s try a different approach by focusing on operations.
- Operations is inherently strategic because it cuts across projects, teams, and domains.
- By democratizing the tactical work and gaining efficiencies through operationalization, you free up your team to tackle more impactful strategic work.
If you do everything right™️, your product teams will have the resources and support they need to do their own tactical research, and they’ll be inclined to do so because it’s going to be faster and easier for them to just do it themselves than to engage with the Research team.
By freeing up your team both from the busywork associated with Research and from these smaller research tasks, you create space for the team to take on larger projects and to shift their focus to earlier in the process. This also creates a virtuous cycle: the impact you create by moving up the pipeline is felt more broadly and deeply, and the company wants more of that, leading to additional resources and more strategic initiatives 📈
Okay, I’m convinced. How do I do it?
I’m glad you asked! Unfortunately, you may’ve noticed this post is already getting a bit lengthy, so we’ve decided to split this up into a 2-parter! Check back in a few weeks for the second half 😇
In the meantime, make sure you follow Auth0 Design for all of our other updates and check out our current job openings!
🚨 You can now view the following posts in this series:
