By Aaron Fulmer
How do operations mature over time? One practitioner at Microsoft shares his perspective.
It’s an exciting era to be working in research operations. Over the last year, practitioners have emerged to define the discipline and establish a community. The question #WhatIsResearchOps is being asked on a global scale, and we all have answers to share. Mine takes into account my journey at Microsoft, where I’ve seen Research Ops move from a reactive orientation to a place of powerful capabilities.
Nine years ago, when I started working in Research Ops, my organization’s research team was running about 300 studies through our labs each year, involving 12,000 participants. Our researchers had been doing a great job multitasking, but as our operations scaled up, they had less and less time. We decided that we needed researchers to focus more on customer needs, partners, and research design. For the rest, we needed Research Ops.
To fulfill our mission of elevating the research discipline, the new Research Ops team began by addressing our biggest pain point. With everyone spread so thin, studies had been starting late, which put us at risk for poor results. The immediate causes included participants being hard to find and arriving late, technical issues in lab spaces, and staff not having the materials or guidelines that they needed.
We boiled these down to three main problem areas:
· Participants
· Support Staff
· Lab Space
On the framework that the ReOps community recently shared after conducting a series of global workshops, these components map most closely to Recruitment, Onboarding New Staff, Guidelines & Templates, and Research Spaces.
To optimize our testing rhythms, we started cleaning up internal processes related to these areas. We believed we would be an industry-leading Research Ops team if we could create a system that wove together these three variables.
Toward a durable research ops model
As we dug into the problem, we started to notice how our pain points interconnected—a productive step, but it was easy to get lost in the details. We needed a way to envision the basic components of Research Ops at Microsoft and how they could work together.
We kept our model simple, minimalist even, adding to it only sparingly. The framework helped us stay focused as we organized our efforts and communicated with researchers about our role.
By keeping this model high level, we were able to identify those components that would be common to different research teams within the organization. The framework has proved durable. Today, eight years after building it within the Games division, we still use this model over in Research + Insight (R+I), and many other divisions use it as well.
Our durable Research Ops model reminds us how important it is to consider the entire picture of what’s required for any given test. It also shows how the top logistical layer (which includes participants, space, and staff) works on a foundation of processes and finance. The bottom layers always underlie the restrictions we experience in the top layer, though they are less visible.
On a macro level, this model illustrates how Research Ops team members use their expertise to deliver solutions. When our research partner comes to us with an aspiration like running a particular study, we use our understanding of how all the components of Research Ops work together to meet their request. The researcher no longer needs to be concerned with all the logistical details.
Enabling powerful capabilities upstream
Using our model, we were able to work with our research team and get operations into a more systematic state, with tests running on time and other pain points starting to resolve. Because we were always thinking about the big picture, we started asking questions like, «What work have we been doing, and why?»
We shifted more time and energy farther upstream, engaging in high-level conversations about topics like research curation and finance management.
In the global ReOps community’s framework, these upstream areas map most closely to Budget Management and Knowledge Management.
To address research curation, one solution our research team has focused on is creating an insight database. By getting our reports into a curated repository where anyone at Microsoft can access them, we’ve eliminated redundant work and made our insights timeless.
Rather than beginning by asking, «What kind of study do we need to run?» We are now equipped to ask, «What do we already know?» Sometimes, once we’ve tapped into our database, we find there’s no need to run a study at all.
Our involvement in the research team’s finance decisions has also unlocked powerful capabilities. Over time, the Research Ops team at R+I has taken on more management of the various contracts, licenses, and other costs related to testing. This allows us to save money by negotiating with suppliers and to measure the impact of our operations in terms of finance. We’ve seen that impact increase the farther upstream we’ve been able to travel.
What Is Research Ops?
With this journey in mind, I feel that Research Ops is defined by its most powerful capabilities. To me, we are a community of specialists who elevate the research discipline by reducing the burdens on researchers — a mission we fulfill best when we engage with our partners at the highest levels of practice.
How has your team organized and adapted to create a foundation for the research discipline? Follow @MicrosoftRI and tweet us your thoughts, or like us on Facebook and join the conversation.
With over 10 years of experience leading teams, Aaron Fulmer manages the Studio Management Office for the Customer Insights Research team. He believes in empowering the research discipline and creating solutions for businesses and operations. He fosters a trusting, respectful, empathetic, and inclusive culture and community.