From Participant Recruiter to Research Ops: The Evolution of Research Operations at Spotify
Nine months ago, a posting on our internal job board caught my eye: “Research Participant Recruiter.” At that point in time, I had been at Spotify for a year and a half managing the Sales support team and operationalizing workflows, and was hungry for a new challenge. As the title suggested, this Participant Recruiter role was meant to provide logistical support to Spotify’s User Researchers in setting up research sessions. Historically, the Senior User Researchers and managers at Spotify developed processes to manage research setup — from recruiting, to lab calendar management, to participant compensation — while simultaneously designing and running research sessions. However, as the team grew over time, it became a challenge to upkeep these processes at a global scale. The idea behind this Participant Recruiter position was therefore to have a dedicated resource to develop and execute research setup processes, ultimately allowing the User Researchers more time to focus on their craft. Having worked as a Research Assistant in the Schacter Memory Lab and pursued undergraduate degrees in Psychology and Music while at Harvard, this role looked to be the ideal marriage of my work and educational experience. I was intrigued by the notion of blending my passion for research, process, and connecting with people, and decided to pursue the opportunity further.
Little did I know when joining the team in late January, this Participant Recruiter position would evolve into what we now know as Research Operations. My job over the next six months would therefore require defining what that meant for Spotify and then beginning to execute on that vision. It was through this exercise I’ve come to understand that the potential scope of Research Ops is vast, and therefore requires working closely with the team to understand their needs, and to develop and communicate a plan of attack that is both realistic to existing ops bandwidth, and flexible enough to evolve with the needs of an organization.
As with any new job, I spent the first few weeks engaged in discovery conversations with the team I’d be supporting. In the spirit of research, and in hopes of uncovering the existing landscape and processes that needed to be developed, I approached my initial conversations as in-depth interviews, or meta user research sessions, with the Researchers and their managers. Before each session, I sent a list of topics spanning the research lifecycle and asked each person to come prepared to discuss pain points, as well as how I could best help. After these sessions, I transferred quotes from my notes into a spreadsheet and completed a thematic analysis to identify common pain points across the team.
What I uncovered in analyzing these 30+ conversations was that while the team certainly needed help with recruiting and scheduling, the original job description had only scratched the surface of opportunity areas for operational support. My initial conversations revealed a vast array of additional challenges for the team that extended beyond research setup, ranging from vendor onboarding, to a lack of documentation and resources, even to a need for community and knowledge sharing. In other words, asking the simple question — how can I best help? — revealed that the scope of the ops role I was hired for only addressed a subset of the team’s needs.
As Kate Towsey so aptly mentioned to me in a recent conversation, any single focus area of Research Ops can only be thought of as a piece of a larger pie, in that discussing one piece inherently implicates one or several others. Take the topic of recording a usability session. On the surface, it seems simple — determine the best possible recording technology that suits the team’s needs and available budget, and then create documentation outlining how to use the tech. But, in breaking this topic down, we can see it opens a floodgate of operational questions that span the entirety of the research lifecycle. For instance, once the participants are recorded, their PII is retained, which therefore requires working with legal to develop a consent form for participants to sign, and even determining and documenting a digitized process for consent form signature. Then, once recordings exist, you’ll need a strategy for video storage and retention, and even a set of tools to analyze videos and share the insights generated. And, on even the most basic level, in order to record participants, you’ll need to find those participants, which points to a need for processes and best practices for recruiting. This exercise can go on almost indefinitely with each additional topic pointing towards another, demonstrating that each operational element of the research process is interconnected and therefore cannot be thought of in isolation.
My analysis and discovery period with the User Researchers quickly made it clear that in order to appropriately support the team from an operational perspective — or in order to address the whole pie — I needed to broaden the scope and function of my role — from Participant Recruiter to Research Ops.
This realization was equal parts thrilling and overwhelming, in that it meant defining how to approach this seemingly endless yet fascinating set of operational questions. I was lucky enough to be managed at the time by our Design and Product Insights Ops Lead whose expertise was integral in helping me to prioritize how I, as one person, could manage this torrent of questions. What we decided on was a phased approach, which we outlined in a Trello board. In the first phase, we identified the low-hanging fruits I could tackle in a 3–6 month timeframe, which would remove some of the time-consuming operational tasks that fell to our Researchers. For instance, when I joined the team, Researchers were still printing consent forms, which would then have to be scanned and uploaded to a contract management system. Researchers were also still handling recruiting, whether this was via a third-party partner, or reaching out to our own internal lists of users. In my first few months I therefore put in place processes to remove these time-consuming elements, including implementing digital signatures for consent forms and a Trello board for recruitment assistance.
But beyond these low-hanging fruits, there were questions that required more in-depth exploration to answer. To tackle these questions, I planned two additional phases of work. In these phases I would refine and document my initial processes, and then test and implement sophisticated solutions such as the best possible technology for our labs, or a strategy for video storage and retention. Although this phased approach was initially decided upon for prioritization purposes, in retrospect it was valuable in helping me to make a quick and tangible impact on the day to day needs of the Research team. By phasing out my approach, we removed pressure to get each process perfect the first go-round, while still leaving room for iteration and improvement.
Although this phased approach was helpful, I quickly realized in putting together the Trello board that even with this structure one person alone could not address every piece of the Research Ops pie. In an ideal world, ops could tackle the higher-level theoretical questions while simultaneously managing research setup for our 25+ User Researchers. But given that there is only one of me thus far, I have had to reconcile this ideal with the reality of our current team structure. In other words, I realized that as important as it was to establish where my work started, it was also critical to have clear guardrails of where it stopped. To accomplish this, in rolling myself out as a recruiting resource, I worked to define what types of studies I supported, the markets where I supported them, and how I would divide and conquer each of the tasks required with the research team. By starting with a tightly defined scope, I was able to simultaneously execute work setting up research sessions while also iterating on process improvements such as digitizing our consent form signature flow. This was not to say that the scope of my recruitment and setup support would not evolve over time. Rather, in being honest about my own bandwidth, I was able to emphasize to the Researchers and leads that although there were opportunity areas for expansion of ops support, this was a starting point that was manageable with our existing resources.
Of course, no level of planning can prepare a person for the ever-changing tech and research landscape. In my roadmap, I had planned to address the higher-level questions such as privacy and state-of-the-art lab technology much later in the year. As it turned out, however, updated European privacy standards and two new Spotify offices opening in London and New York meant that we had to be flexible and tackle our privacy and lab build strategies much earlier than expected. While initially challenging, these unanticipated timeline shifts emphasized that while having a plan of attack is helpful, it’s critical to iterate on the plan based upon the reality of the team and the company’s larger needs. This realization has helped me manage the expectations of leadership, the Researchers, and of myself while reinforcing the very real fact that deliverables, priorities, and even my overarching scope may shift over time based upon the needs of the organization as a whole.
The past 6 months have therefore been as much about defining and communicating the scope of Research Ops at Spotify as they have been about actually executing on team needs. And as much progress as I’ve made in defining my role, my understanding of Research Ops is ever-evolving. In early March, I had the pleasure of being introduced to the industry Research Ops Community on Slack. As the sole proprietor of Research Ops at Spotify, it’s been wildly helpful to socialize challenges and ideas with people who face similar questions. But, perhaps most importantly, these conversations have shown me that while my initial approach was designed around the needs of the research team, it was also entirely specific to the structure and function of our research org at Spotify. In other words, in engaging with members of the community, I’ve learned that though there are common areas we all work on, the needs of research teams we support may vary depending on the larger organization. For instance, due to the work of the Researchers and leads team before I joined, research is seen as invaluable to our product lifecycle at Spotify. The operational needs I face are therefore different from those of an ops person at a startup, whose main focus may be selling in the importance of embedding research in product development. It is only in coming together, then, that we’re able to get closer to a holistic picture of the role ops can and should play in various contexts. I look forward to continuing to partner with the community to share our experiences, and to further refine our definition of #ResearchOps both within organizations like Spotify and beyond.
