Creating impact with Research Ops — leveraging the power of communities

We love Research Communities!

I gave the keynote talk at the ReOps community conference in New York in June 2022. In this talk, I shared how you can encourage your own Research community to run programmes of work to support the team. I’m sharing an updated version of the full transcript and slides for this talk in this post.

***


Being a Research Leader can be tough going and this past few years has been utterly exhausting. Our already overloaded researchers have taken on even more tasks. We’ve pivoted from in person research to remote research, we’ve had to on-board new tools, new processes and new people. All whilst working remotely with the fear of illness. We’ve gone through reorgs, the great resignation and now layoffs. As leaders we’ve had to hold it all together and carry the burden of poor team health. This has led to many of us burning out.

Work Life balance? What’s that?

Whilst we have been supporting our teams who has been supporting us as Leaders or Ops people? What or who has been our constant companion throughout all of this?

Communities! The UX community, the Research Community, THIS community!

The ReOps community logo

Now you may not work with any Research Ops people or you may only have one or two supporting a large team. Even if you have a centralised Ops team, there is still always too much to do!

Communities

Which way do I turn?

Cast your mind back to 2018. 5 years ago now. It feels like a lifetime doesn’t it? I was actually laid off at the start of 2018. I had spent almost 10 years working in UX by this point, running a successful design studio with my husband as well as a side publishing business. In 2014 our studio was acquired, and I worked in-house as the Research Director for the company that had acquired us. After a few years, the company pivoted and my role was no longer required. I’d gone from forming a team, creating a great culture, building a sustainable and successful business, selling it on, for it all to be gone. I felt used, burnt out and thoroughly directionless.

Step forward the Research Ops community!

I joined at the start and very quickly met some wonderful people. We ran our global workshops to understand what this emerging profession of Research Operations was all about. A few of us formed a board and we started sharing what we had found out.

All the while I was trying to rebuild my career. I live 3 hours away from London where most of the jobs were being advertised and senior roles were hard to come by. I wrote some articles, I rebuilt my network and started being asked to do talks again. I still couldn’t find a job but at least I was starting to get some paid freelance work via a couple of agencies. 18 months later, I was finally offered a role.

This community and the people I met via this community literally saved my career. If it wasn’t for the people I had met here and the things I had learnt, I wouldn’t have got that role or the next one at Meta and I certainly wouldn’t have been opening the conference in New York!

Of course many of the conference attendees and readers of this post were there at the start 4 years ago now, when the Slack group was created by Kate. From there, things have grown so much and we’re now a community of over 16,000 people! Many of us have benefited greatly from being part of this group. It’s through this open sharing of ideas and dialogue that we continue to push the industry forward together.

Communities — helping researchers to learn and grow

Operational Impact

So as we’ve heard, research communities can help support and enable researchers and even research leaders to do their best work. Why is this important?


Impact.


Research is not in service of vanity. We do User Research to help bring the voice of the customer to decision making and product development. So how can Research Ops help with impact?

Let’s remind ourselves of the definition of Research Ops.

Research Ops is the mechanisms and strategies that set user research in motion. It’s not the craft, it’s helping researchers focus on the craft. Research Ops provides the roles, tools and processes needed to support researchers in delivering and scaling the impact of the craft.

But how? Let’s remind ourselves what types of things Research Operations is concerned with. You are probably familiar with these Eight pillars that I wrote about.

The Eight Pillars of User Research

You will recall that all of these eight areas have a set of tasks that are associated with them. These tasks often fall to Researchers to do. You will also recall that if we bring in Research Ops as a layer, these tasks move upwards off the shoulders of our researchers…

Creating a Research Ops layer

GREAT!

Where do they go though? We pile them onto our lone Research Ops person! If we only think of Research Operations as something Research Operations people do, we quickly create a new problem. We transfer the pressure onto a single point of failure.

Carrying the heavy load of Research Operations

This is not sustainable! This is not the way to scale impact. What else can we do?

Impact is talked about a lot at Meta. There is a clear expectation matrix for both individual contributors (ICs) and managers. Impact is a key part of the expectation matrix. Impact is measured in two ways — your impact on the product and your impact on the community.

Product Impact is about helping product teams make better decisions — for example delivering actionable insights that result in real changes in the experience of end users.

Community impact is equally important — for example, getting involved in a Diversity Equity and Inclusion initiative, mentoring other researchers, sharing best practices or organising social events.

The mission at Meta is to support and enable communities so employees are actively encouraged to build community. How can we leverage this power?

Leveraging Research Communities

Let’s think about some fairly typical representations of Research teams at different companies.

Research teams at different companies

Team A have no Research Ops support, Team B have an embedded Research Ops person — perhaps a Research Program Manager or Research Ops Manager and Team C have a centralised Research Ops team.

This version is a little like Meta. There is a centralised Research Ops team as well as embedded Research Program Managers that sit within teams. This is called the Hub and Spoke model and it’s been spearheaded by Emily Becklund, a Director of UX Research and Research Ops.

Research teams and Research Ops at Meta

Let’s think back to the Eight pillars again. These are common areas research teams need to focus on to operationalise research.

The Eight Pillars of User Research

The pillars on the left are about how research happens and what supports it. The context and the capability. The pillars on the right are about how research can be systematised and scaled. The core of ops. The Central Research Ops team at Meta support much of the four pillars on the right here as well as some programs to support the left hand side.

Now, even if you have a centralised Ops team and an embedded Research Program Manager to support you like many teams at Meta do, there is still too much to do! As the Team Leader, it’s my job to ensure my team are utilising the resources from the Central Ops team properly and work with our RPM to prioritise the highest impact projects. For other priorities, we use the Research community to run initiatives and this can be counted as impact when it comes to Performance review time.

When to centralise and when to embed Research Operations

Next I’ll walk you through how you can approach some of these Research Ops tasks in different ways. First let’s think about why you need to ‘centralise’ something or run it as a Research Operations program.

There are good reasons for ‘centralising’ your operations work rather than reinventing the wheel every time. It can be a lot more efficient when thinking about the kinds of tasks that fall into these four buckets:

  • Governance

  • Consistency

  • Maintenance

  • Scale

Here are some examples of these:

When to centralise

  • Governance: Where you touch upon legal, data privacy, procurement, risk management and Infosec. It’s pretty obvious to say but once defined, policies and processes for consent, safeguarding of participants and data privacy shouldn’t need to be changed or updated very often. Centralising the governance of these makes the most sense (as long as they are widely adopted by your team of course).

  • Consistency: Where you need a consistent approach or process — for example, recruitment of participants, panel management or documentation best practices. Duplication of effort and a poor participant experience are big risks when it comes to recruitment, so centralising makes the most sense.

  • Maintenance: Where there is a job to do managing or maintaining things such as tool licensing, software or hardware. At a previous company I worked at this was so much work and I was glad to find this work was centralised when I moved to Meta. At a larger company it’s so much more efficient to have a central team to deal with procurement.

  • Scale: When you reach a certain level and need to provide programs to support at a critical mass. For example, on-boarding, mentoring programs and community of practice events.

Now let’s think about the kinds of things embedded Ops or even Researchers themselves could do to support the Community of Practice.

When it comes to embedded Research Ops, here are the four buckets that you can use:

  • Quality

  • Visibility

  • Team Health

  • Connectedness

When to embed

  • Quality: What and how the work gets done and using the community of practice to help govern what good looks like. For example roadmap prioritisation, critique groups and peer review. You can improve your ideas and the execution of your research by sharing it early with your peers, rather than waiting until the point you review it with your manager or for official ‘sign off’.

  • Visibility: This is all about comms and ensuring you are raising the visibility of your work (and scaling the impact). This doesn’t need to be done centrally and as long as you’re co-ordinated can be more effective. At my previous company and at Meta, a small group of researchers organised a regular ‘Lunch and Learn’ to showcase their work.

  • Team Health: ‘Show care’ is a manager behaviour at Meta and something managers are encouraged to do. Creating a ‘Sense of Belonging’ is really important for researchers to feel supported to do their best work. I would argue that this shouldn’t be down to managers alone to create of course.

  • Connectedness: Embedded Researchers in silos can mean disconnected insights and a fragmented narrative. You can use the community to develop a shared perspective and build organisational knowledge. At Meta we have topic based ‘v’ teams that come together to define a shared point of view.

Research Ops at Meta

So, you remember this from earlier? I said that, at Meta the central Research Ops team support much of the work needed for the four pillars on the right as well as some programs to support the left hand side. The pillars closer to what and how research happens are where our embedded Program Managers come in. We’re missing something here…

Our Research Community.

Supporting the Eight Pillars through the community

As you saw from the previous examples, researchers can help support across the pillars — particularly if you have a very small team and no Ops support. If you’re starting out, you might find that your team is supporting the core of operations on the right to begin with. As your team grows and matures you might find that the community are more concerned with the left hand side pillars (especially if you have been able to hire dedicated Ops support).

Closing thoughts

So, to recap:

  • Building and supporting research communities is as impactful as doing product work.

  • Research Communities can support and nurture researchers to be their best self.

  • Research Operations helps our User Researchers to focus on the craft.

BUT… loading unwanted admin and tasks onto our Research Operations people is not the way to scale impact.

Put on your own oxygen mask first

It’s easy to forget yourself in all of this. This is the silent work of Ops and the people who do the work of Ops. As soon as it becomes too much and you are giving more energy than you are getting back, you need to take a step back. Particularly now, three years on and in the middle of layoffs. You are not solely in service to your team. Don’t be afraid to say no.

Prioritise the highest impact projects to take on yourself and then ask your Research Community to lean in and support programs of work across the rest of the eight pillars.

Good luck!


***

This post was originally delivered as a talk at ReOps Conf, 8th June 2022, New York. Thanks to the Cheese Board and Learners for inviting me to take part!

Previous
Previous

So long and thanks for all the fish! 👋🏻

Next
Next

Is saying sorry a sign of weakness?