ResearchOps, The carousel effect.

If you want to grow enterprise researchOps, then it's time to stop going around in circles.

This is a 10 minute+ read. Opinions are that of my own.

Recently I had the privilege of discussing enterprise-level researchOps (rOps) with some friends in healthcare. rOps is a hot topic, as is the "ops" trend in general within UX & HCI. Whether you subscribe to the collective notion of research being embedded within designOps or a separate entity, nothing is more clear that as an industry we're at the beginning of a unified collective maturity cycle that has seen the rise of "ops".

As someone who leads a team and has direct responsibility to grow research and designOps within an enterprise science-driven healthcare company, I'm not precious (quite yet) about how underlying philosophies of relatively new(ish) models of organizational UX design and research delivery drive my decision making. Like many practitioners in large companies, coming to terms with, defining and scaling "ops" is no easy feat and requires consistent commitment, (re) evaluation, and adaptation to be even marginally successful at the beginning. This is no blasé approach, rather an acknowledgement that it's just plain hard and whilst there's plenty written about these areas there's no one size fits all approach and maybe like many of my peers, a mixture of rigour, trial and error and "feeling" my way through things has been exceptionally helpful in building my knowledge base and understanding the scope of delivering successful ops.

It's fair to say that having a dogmatic approach to applying rOps at an enterprise level is akin to trying to take a pet cat out for a walk, yeh it's possible, but the cat doesn't like it, people stare at you weirdly in the street and the net result is an unhappy feline who remembers with their claws.

A softer approach that is more equitable is that of principle-driven rOps, collective wisdom that includes knowledge from social and psychological sciences, applied HCI/UX practice, and generally what the industry has to say. In my recent talk, a number of areas, in particular, surfaced that resonate in my current situation and may in yours too.

Of course, the above graphic doesn't include every variable that makes up rOps, there are more complexities than can be drawn on a Miro slide, but as can be seen, even a modest smattering of practice and organizational based components begin to mount up in conceptualizing this area. Of particular interest to me is that of knowledge building, the impact it has, and the peculiar, but not uncommon carousel effect that often ensues.

Let's all get off the merry-go-round (or don't get on it)

We've established that rOps is difficult, it's a multi-dimensional phenomenon that goes way beyond that act of research itself. In-particular, knowledge building is an area that, throughout my enterprise career has often been problematic in the research context. How so? Enterprise companies are socially and organisationally complex and we've fought hard to establish (mature) UX functions that through applied research and design practice bring value to stakeholders and resulting outcomes. But it's only a small fraction of the problem.

To illustrate this let's talk about amusement parks by the sea. I can remember vividly as a child in Wales with my Dad, I'd spend my time running around the beach, eating ice-cream then insisting I must go on the carousel. Of course, my dad knew better, and the ensuing ride often resulted in unpleasant velocity based ice-cream "incidents" that weren't pleasant for patrons or my Father. Like many small children, I insisted on going again and again. My experience was so gratifying I just wanted the same thing until I'd had my fill, lost interest or my Dad needed to get back for the football scores on the radio.

Like me, you too may have experienced this effect in enterprise situations when it comes to research and it's constituent parts. Examples, where multiple functions are doing the same types of research to attempt to understand and solve the same types of problems, is not new. Each research project gets on the carousel, each research project gains velocity, each research project gets off, each research project disappears faintly into the night. Granted there are no "velocity-based ice cream incidents" but the effect is the same. The experience of an org learning and feeling something new from research data is gratifying, humbling, and exciting, but can come at the expense of building incremental knowledge that is pivotal for product development, decision making, and learning.

Perhaps you've experienced this yourself, department y is doing research that is similar or identical to department x. What can be done? rOps promises to unify and tackle these problems, but the practitioner needs principles to be able to operationalize successful knowledge building when these problems arise.

In an attempt to avoid the carousel effect (top left) three principles feel like a sensible starting point in addressing this problem. Remember the basic aim:

We want to avoid cyclical research efforts that provide little to no incramental knowledge value to the project, product or org.

How can these principles help?

Accessibility

In its simplest terms, accessibility refers to equitable access to research. This includes processes where research is being designed, actioned, and disseminated. This is not a software problem. We don't solve the carousel effect by creating a repository and expecting everyone to magically access it. Sure, technology inevitably will play a part, but the problem is inherently social, psychological, and organizational. Accessibility includes pro-active involvement of and co-discovery with the right people to understand where cross-pollination and reduction or removal of research efforts lay. Ownership and group dynamics are always going to come into play here, the wise rOps practitioner respects boundaries but challenges norms where ownership and research "stereotyping" (our research vs their research) comes into play.

Right time, right place

We should learn from experience. Hindsight gives us the opportunity to evaluate research outcomes and implications from previous endeavours. Our brains are wired to see patterns and although this is a gross (neuro) psychological simplification, it gives us a platform to develop a level of foresight. For example, you might observe a stakeholder or a group making research decisions that you feel are incompatible or add limited value to overall knowledge. Armed with sufficient insight from observation, outcomes, and experience you are in a position to attempt to create an intervention at the right time and right place to influence rOps that fundamentally drive incremental knowledge. This isn't easy, our own perception, stakeholder management, and business timings are but a few variables that the rOps practitioner needs to overcome to be effective. This leads us nicely to the last point...

Collaborate effectively

My favourite jargon word. Collaboration. In its essence it seems like a simple concept, actively engaging with a group of people working towards a common goal (even if that goal is hotly contested). But collaboration is a tricky, nuanced activity that requires a deft touch. The effective part implies planning, consideration, and measurability of outcomes (e.g. did you achieve what you set out? What was the impact?) When done properly, collaboration is a wonderful thing. In our context, collaboration should enable the rOps practitioner to engage with the right people in a research context continuously. Our current global situation has pushed online collaboration to new heights and limits, changed the behaviour of sceptics, and created consistently connected spaces where we now have the opportunity to be hyper-visible in our research intent. Collaboration is continuous, often messy, and should be measured. Remember, we're aiming to effective at all stages of research with the fundamental aim of ensuring we build incremental knowledge, avoiding going around in circles.

Building bridges or something (probably lego)

You may have by now noticed that I've not offered a comparative model for avoiding the carousel effect. Honestly, I was thinking about bridges and other suitable metaphors to contrast the idea of cyclical non-knowledge-building research efforts. Lego comes to mind, it's incremental, flexible, and knowledge-building, it has an end goal (usually) and opportunity to scale at a relatively low cost. You may however feel like another suitable description works for you, whatever it is bear these points in mind:

• rOps should aim for incremental knowledge building, not cyclical repetition
• This is only a small, niche area of the problems rOps creates and aims to solve
• Incremental knowledge building should be considered through the lens of organisational, social, and psychological factors, technology plays a part, but it's not the driver
• Incremental knowledge means just that, start small and grow-as-you-go
• A knowledge building rOps approach can save time, money, efforts and drive more efficient collaboration
• Avoid dogma, a principle, knowledge-based rOps approach is always more flexible

A final thought

Many of these ideas or problems exist in companies that are not just "enterprise". Sometimes they can be even more profound in smaller ones! Whatever the size of your org, remember that thinking about rOps now (or whatever it's called in 6 months...) will give you some structure and clarity, even if you're a team of one.

Like many practitioners, I'm still learning and I certainly don't hold all the answers, only what my experience has taught me so far, let me know what your biggest blockers or learnings have been working with rOps at any scale, especially when it comes to knowledge building!