Building the Foundations of Research Ops at Okta.

We recently sat down with Jared Forney, UX Researcher at Okta, to discuss some of the challenges facing his research team as they scale and how embracing Research Ops has provided a path to meet their increased internal demand for research. Jared also has some poignant advice for researchers who find themselves making a case for Research Ops to executive leadership. Let’s dive in:

Sofia: Jared, could you tell us a little bit about the structure of the Research team at Okta and how you got started with Research Ops?

Jared: When I joined Okta, there was only one other researcher for the entire design organization of about 10. At the time I was working 50/50 as a researcher and product designer because of staffing needs. We needed to hire more product designers so I joined with the understanding that over time, I would be doing increasing amounts of research work and less design work as that happened.

Fast forward a year and a half –our design team had grown to almost 30 people meaning I could transition to research full time as we had enough designers. I’ve been in that role for about a year and there are now four of us in total.

Within the last three to four months, I’ve started to take on responsibility of our Research Ops strategy. I realized how much extra time we’ve been spending on logistics versus actual research work and recognized that we need to start thinking about ops, including everything from managing or organizing research insights to creating templates, in a more concentrated way.

Sofia: When do you realize you needed to start building the foundations of Research Ops at Okta? How did decided it was the right time?

At our size, we have a lot more demand for research coming in that we can scale for, but we’ve recently scaled the team considerably which is opening up a lot of bandwidth and possibilities for us.

I’ve also been influenced by the work we are doing in the design organization. We’re working on a big design system initiative within our company and a lot of that has come from the need to scale. Having gone from 10 designers to 30 designers in two years, we recognized the need to get them onboarded and familiar with the tools we use quickly, and figure out how to start building things more consistently and efficiently.

What I noticed after watching that effort in the design organization is that there are certain tools and things that we’ve rolled out, Figma being one of them, that were transformative for our design team because it allowed for a lot more efficient collaboration and workflows.For example, the minute we make a change to a component, it populates for everyone to use. There’s no more sharing binaries around, it all just happens.

The research team is small enough that we can think, test and iterate on how we operationalize these processes while we’re still small. We have so much demand for research internally that we need to start thinking about things such as: How can we automate this?

How can we make templates so we spend less time reinventing the wheel? How do we distribute insights more quickly, in a more timely manner? How do we recruit more effectively?

Another example: Our customer success team is having a lot of valuable interactions with customers, interactions that we could be learning from but unfortunately there’s no efficient way to capture those interactions into a repository, and they don’t always pass data down to us. We are trying to figure out how can we go and fetch it ourselves.

Having access to data but also providing access to insights is what will ultimately help us scale our efforts.

Sofia: When it comes to Research Ops and building a research repository, what is the problem you are trying to solve?
The question I have in mind is, how do we make the insights we are generating durable and actionable?

The way most research happens is that you have a research question, you do a study to answer the question, and the outcomes of the research tend to be useful in that moment in time. Based on that information we know what we need to do next but then those insights get forgotten, they sit for six months to a year and nobody touches it. Then later somebody, maybe a new PM or designer, comes back and says, do we have any research on X?

Once somebody asks a question like that, you have to dig around through your files and try to find that one report. The report kind of answers the question, but is not exactly what they are looking for. In the end, you end up doing a bit of manual work just to help a colleague find something useful. This happens over and over again.

Instead, we could have a process where anybody could come to us with data, note a pattern based on the research we have done, and then the research can take that data and direction and build off of it. This helps create really valuable research and data.

Sofia: If you are solo researcher in the organization, when is it a good time to start thinking about Research Ops seriously?

I’m going to reference Kate Towsey, who leads Research Ops at Atlassian, and her model for Research Ops. Her rule of thumb is that for every five researchers, you need one Ops person. At Okta, we’re reaching our threshold and I believe this is a good rule to follow.

However, it’s important to keep in mind that every organization is different, and as researchers start to get more specialized, you will likely have Ops people who are also specialized..Kate also talks about something called Cake ops, which is the idea of celebrating the little things — such as birthdays or special events — and things that will nurture your team culture. I think this often gets overlooked and I love that she like thinks about that as part of the role.

Sofia: Based on your experience, what are some of the challenges you think people will face when trying to build the foundations of Research Ops at their organizations?

One challenge people will likely run into is governance. Even if you don’t have a plan yet in terms of how you’re going to implement things, get people from your legal team, your procurement teams, your budgetary, your financial teams, etc. involved very early, especially if you think you’re going to need tooling.

The clearer you can illustrate why you’re doing something and how it fits into the larger model of how your organization collects feedback and how it implements it, and the impact it can have on your team to those teams from the beginning, the easier it will be to get their buy-in. You need to build relationships with all those stakeholders.

Sofia: We recently published an article about a survey we ran asking Design Ops teams whether they thought about Research Ops as part of the Design Ops org. What are your thoughts on that?

I work closely with our Design Ops team and I find a lot of similarities there. As much as Design is about tooling and thinking about architecture and taxonomies, at the end of the day it’s really about people, which is what research is about. So much of Ops work, despite the operations label, is about interfacing with people.

💡Recommended: The Ultimate Research Repository Checklist

🧠 Learn more about how EnjoyHQ can help your team centralize, organize and share all your research insights in one place. Build your Research Repository with EnjoyHQ