When to (and not to) build an Ops-first Research Practice
In Part 1, we covered why you should do it, and in Part 2, we got into the details of what we’ve done and how we’ve done it so far at Auth0. This surprise 3rd part will discuss things to consider if you want to go the Ops-first route.
When I set out to write these blog posts, I planned for two parts: why and how. What I realized as I reflected upon my time at Auth0 so far and wrote those two posts is there’s more to the story than that. It’s one thing to sell the dream, but sometimes that’s not the right fit for where you, your team, or your organization currently is.
This, what I’m calling “sneaky part 3”, will discuss factors to consider if you want to build an ops-first research practice and include some tips of how to approach whatever situation you find yourself in if you decide to go down this route 🛣
Research Operations is a flywheel
One of my favorite metaphors when discussing the impact of research operations is that of a flywheel. According to Wikipedia…
A flywheel is a mechanical device which uses the conservation of angular momentum to store rotational energy; a form of kinetic energy proportional to the product of its moment of inertia and the square of its rotational speed.
…which, unless you’re a physicist or mechanical engineer, probably doesn’t mean much 🙈 Instead, it’s much simpler to look at the “flywheel effect”, a concept popularized by Jim Collins. Here are the two key qualities of a flywheel:
- It takes a lot of effort to get it started.
- Once it’s going, it’s incredibly efficient.
Hopefully now it’s clear why this is one of my favorite metaphors for Operations work 🧰 You will likely put a lot of effort in at first and it might not seem like you’re getting anywhere, but little by little, you keep pushing and you start to build that stored energy.
Eventually all of that effort will pay off, but this leads us to one of our key factors to assess before you start pouring effort into operations.
Maturity & Literacy
Maturity is one of those concepts that seems to come up often in strategic situations. I was asked very early on (within my first 90 days, in fact) to develop a Research Maturity Model and to assess our team on it. Maturity Models are useful frameworks to help take an honest assessment of where things are right now and to identify primary areas for improvement 🕵️♀️
Nielsen-Norman Group has a great model for overall UX Maturity, which is an evolution of the original 8-stage model Jakob Nielsen himself developed in 2006. Their model contains 6 stages, each with challenges to overcome to progress you to the next stage. While there isn’t one champion Research Maturity Model, this is a great place to start when developing yours. Combine NN/g’s with the 8 Pillars and you have yourself a powerful tool to understand where your current organization is.
NN/g UX Maturity Model +
ReOps 8 Pillars of Research == 😚👌
However, you need to be mindful of two things:
(1) how you assess maturity and
(2) what the organization’s literacy level is with respect to Research.
One mistake I made at Auth0 was I didn’t go deep enough. All of my conversations with leadership indicated a high level of maturity and a large appetite for Research (including my introdutions to the CEO and CPO, both of which said something along the lines of “Ah, yes, we’re happy you’re here. We need you.”). It’s certainly important to have the wind at your back, but you need to get everyone on board in order to make good headway 🌬
Make sure everyone is on the same page
I took those ringing endorsements at face value and assumed there was alignment top-to-bottom within the company and the Product organization (where Research currently sits), however that wasn’t the case. After rolling out things like a Research Engagement Process, a few playbook entries, and building up a recruiting pipeline, we weren’t seeing the outpouring of research from our product teams as we had expected. What gives? 🤔
It turns out: not all People Who Do Research (“PWDR”) are totally comfortable doing research even if you give them the tools. Even with guidance from our Research and ResearchOps teams, teams were hesitant to dive in without real-world examples of what Research “should” look like. Only after we executed a few of our own projects and shared all of the assets (research plans, screeners, Miro boards with notes and analysis, etc) with the team did we start to see broader adoption to match the interest in research. Many teams still use copies/versions of those original assets we shared: they’ve become unofficial templates 📝
Decision Point
Before moving forward, make sure you have an accurate picture of the overall Research Maturity at your organization. If you’re wondering how to do that, go back to Part 2 and read about the Listening Tour.
Once you have this, it’s time to make a decision:
- Is the overall maturity low or high?
- What’s your resource situation?
That second question, while we haven’t covered it much, is crucial: if you’re a team-of-one (perhaps brought in to build this function from scratch 👀), how you approach this and what you can accomplish is vastly different than if you're inheriting a small/new team. If you’re inheriting a large team, there will likely be a lot more work required to overcome the inertia of how things are currently working. You’ll need to focus on identifying key pain points and solving those to slowly turn the tide toward being operations-first.
You can visualize this along two axes:
Low maturity, team-of-one
When you have neither maturity nor team size on your side, if you focus exclusively on operations, you’re going to be fighting an uphill battle 🧗 You’ll have limited resources and nobody will understand/see the value in what you’re doing. The best way forward is to deliver one or two high impact studies right out of the gate. This will accomplish two main goals: make them hungry for more and provide a model of what impactful, high-caliber Research looks like.
If you’re wondering how to know what to research, there are two easy ways to figure this out. The direct way is to simply ask a lot of people what the biggest concerns/questions are and to pick the one that is the most common or the scariest to you. Go as far up the chain as you can with your asks: if you can get to the CEO, great! 🎉
The indirect way is to pay close attention and identify blind spots/opportunities yourself. Remember the “Listening Tour” we discussed in Part 2? This is an excellent opportunity to identify those opportunities.
If you focus exclusively on operations without first demonstrating the value of Research, you’ll get stuck. Organizations with low maturity don’t understand what they’re missing out on, so they see you delivering enablement as a win (versus recognizing the opportunity cost of having a dedicated research team).
I believe this is a key mistake I made when joining Auth0, and we’re still working on making up for that 📈
Low maturity, small team
If you find yourself in a situation where you have a small team but the team isn’t being particularly efficient or impactful in their delivery of Research, operations can help you here as well. First, take the time to do a retrospective on what’s been going well and what hasn’t (maybe even use the 8 Pillars as a framework), then use that to focus your initial operations effort.
Have the entire team spend a week or three identifying the best fix for the most painful operational issues (often: recruiting, tooling, consistency, knowledge management) ♻️
Once you have a clear vision forward you can divide and conquer. One person (usually the team lead) can continue to chip away at operational improvements and crafting a narrative around Research Operations while the rest of the team can shift back to delivering research and showing the impact of operations first-hand 💪
The increased efficiency allows your team to focus more effort on making sure their work is strategic and impactful. You may be tempted to switch over to enablement, but don’t: the best way to raise maturity is to let people see the value of high-caliber Research 🏆
High maturity, team-of-one
Walking into a high-maturity situation helps immensely, but you haven’t made it to shore just yet ⛵️ Instead of focusing on delivering research and proving its value directly, you’ll need to spend a lot of time taking a hands-on role supporting teams. This means getting tightly integrated with the existing product development process and figuring out where research fits in 🧩
Because there’s only one of you, this also means learning where and how to set boundaries. Scalability has to be your #1 concern: there’s only one of you, you can’t possibly support every team and every request (at Auth0, there were 15 product teams and 1 of me; we’re now up to 25 teams with 2 dedicated Ops people).
Building self-service capabilities and ensuring everyone knows how and when to use them will likely be your best bet. After all: you don’t actually have a tool/capability unless your team knows how to use it.
You haven’t successfully onboarded a tool/capability unless your team knows how to use it.
High maturity, small team
In case it wasn’t obvious leading up to this point, this is likely the most ideal situation to walk into. If both your organization and your team are bought into the value of Research and the vision of Research Operations, you can really get things moving quickly. That being said, with a team, the way you approach this is slightly different.
If high-maturity, team-of-one is all about self-serve and getting hands-on, this is almost the opposite: don’t get sidetracked by jumping into every little fire drill 🚒
Instead, you should focus on education, evangelism, and building cross-functional partnerships. Your Research practice will be limited not by what you can support but by what you decide to support. Let your team take on the day-to-day support needed in a democratized research practice while you focus on driving strategic conversations. Research @ Auth0 is currently in the process of making this transition 🔀
One thing to be mindful of if you find yourself in what otherwise seems like an ideal situation: why hasn’t this happened already? If there’s a team of folx and the organization seems to want it to happen, what was holding them back? What do you bring that they didn’t already have? Being aware of these will help you avoid previous pitfalls and unlock full growth potential 🔓
Stay true
One of the things I warn all of my mentees and peers about when discussing how to navigate these situations: in Jakob Nielsen’s original UX Maturity model, the recommendation at Stage 1 is to leave the company (versus fight the uphill battle):
If your company is at the hostility stage, you can forget about promoting user experience. People have to want to change before there’s any chance of helping them do so. Once the company’s been sufficiently hurt by its Neanderthal attitudes, management will be ready to consider usability and enter the next stage.
As you work yourself through the decisions around how to approach your organization and the current situation, remember check in with yourself regularly and to be true about what you want and why you’re there 🔍
I was drawn to Auth0 for two main reasons:
- Due to the nature of the product, we have the opportunity to do research that can have an impact on the entire tech industry.
- After 2 years of mind-altering engagement with the ReOps Community, I wanted to get in at the ground level with a company and prove the model.
Of course, unless your company is brand new (and Auth0, founded in 2013, certainly was not), you’re never actually starting from scratch. But when things get tough (and believe me, they will), going back to those two things helps me remember why I’m here and why this work matters.
Celebrate your wins and keep track of your progress: remember, it’s a flywheel. It might not look like you’re making much/any progress at first, which can be demoralizing. As much as I hate to borrow sports metaphors 🏈, I can’t help but echo my hometown Buffalo Bills’ head coach, circa 2017:
Trust the process.
Keep your eyes on the prize, get feedback early and often, make adjustments, and use your mission and vision as your North Star. Building a new function (or transitioning an existing one) operations-first isn’t easy, but it’s worth the effort if you can stick to it. And if you can’t fully invest in ops-first: it’s not the end of the world. Any work you put into operations is going to help the team down the road, whether that be onboarding new talent, supporting multiple projects/initiatives, or amplifying the impact of your work 🎯
Hopefully this post (along with the previous two) helps shed some light on what this whole Research Operations thing is and is about, what we’ve been doing here at Auth0 to prove the hypothesis, and how you might be able to do something similar at your organization (or your next!).
Keep an eye on this blog for more about our Research team (including our next post about the evolution of our insights repository) as well as other great posts from the Auth0 Design Org as a whole, and don’t hesitate to comment here or reach out directly if you have feedback! 💬
