Weeknotes SE02E25
These weeknotes are structured around the 8 Pillars of User Research — I use these to help me keep the scope of my role knowable, to me, and others. I use the Pace Layers Matrix to structure my research operations strategy in my everyday work.
What did you do?
Environment
Silos silos everywhere! Big organisations breed silos — even if the work culture is good, the sheer number of people and things to know can be daunting. One of the most effective ways to break down these barriers is through working together. Those small but mighty multidisciplinary teams (MDTS) are wonderful here, and in analysing where our successes have been over the past 7 months, having policy people embedded in your delivery teams wins, hands down.
The next thing, is to communicate, communicate, communicate. In order to do that at scale, you need a single, cohesive narrative to refer back to. I missed mentioning it last week, and so I’ll point it out here, huge kudos to Jordan Hatch for getting an official blog post out about the program of work on Transforming Australia’s Agricultural Exports, and my everlasting admiration to Gabby Quirk for working with stakeholders across the department to achieve it.
Scope
As the export services teams move towards a single experience for people accessing our services, the need for coordination across the teams is increasing. We have a weekly sync and go through key items — one of which is each team’s needs for research. At this stage, for ReOps, it is just a matter of making sure everyone has access to the evaluative platforms that assist with research at this stage, and that they have analysis tools that suit their needs. Critically, comms within and without need to be spot on, and agreed by all. This flows through to research as we try to make sure the research participants know what they’ll be asked to do and why, and that all stakeholders understand what the aims are. Again, it has been wonderful to be in the hands of Gabby as she works her magic with the delivery teams themselves bringing in their formidable experience and expertise to the task.
Another aspect of doing ‘research as a team sport’ is making sure people across the design and delivery cycle have access to research in a way that suits their needs. Ruth Ellison and I had more catch ups this week with the DevOps and Integrations teams on the topic of getting the right research to the right people in the right way. We are a long way from done on that, but it is a joy to be working with them on thinking through where we are trying to get to on that.
Organisational context
In the time that I’ve been working at DAWE, the number of teams working in or around user research (that I know of) has gone from 4 separate, mature teams of user researchers across the department to 31 of very variable maturity. Several things are happening in terms of organisational research maturity — we’re going through the pain of having scaled very fast — that building the plane while flying it thing is tricky indeed. But we are also seeing our maturity evolve. We now have policies across the department that support user research as a practice, and we have these concepts starting to be embedded into our standard policies and procedures. I know that the teams who were here long before me had done their own work maturing the practice (the fact I am here at all is a testament to that, and to their having identified that research operations was the next step on the path to maturity!), but they also tell me that having an operations function has allowed a focus on those broad overarching policies, and that’s been a critical factor in this evolving maturity. It’s hard to spot the value of ReOps sometimes, and it is good to be able to hear that reflection from those more mature teams.
We’re also at the point where we can start to think about research operations as a centralised function — the symptom being that there’s a growing need to consider a centralised budget and a centralised team to support researchers to have access to the tools, templates and guides as and when they need them. We’ve not made all the decisions we need to around this yet — there are several models for operations teams, and each carries pros and cons. The appropriate response is to sit back and quietly evaluate. But I mention it here, because it occurs to me that it is a positive, and expected sign, that evolution is happening, and we are growing, not going backwards.
People
Alongside our maturing user research practice within the department, the past week carried with it some conversations about how might we best utilise our scaling practices to look at user research, and research operations career paths. I won’t say we have any tangible outcomes on this at the moment, but it is popping up in conversations — a further symptom of that pleasing evolution of our maturity. Watch this space.
In the meantime, our Research and Design Guild chat is growing every day, and the the Busting Congestion guild fortnightly meeting continues to help us evolve our practice as we learn from each other, and take deep dives into what we’re learning across the program. This past week, Hannah Mattner took us through some developing work on archetypes (here’s a good article on why we weren’t talking personas), and workshopped with the guild on their needs — what do questions do researchers want to be able to answer about our users, who do they want to know about, what they are looking for (insights, vignettes, key stories), and what do those words mean (to each researcher). From a creating the library taxonomy perspective, it was absolutely gold, and I hope to keep working with the End-to-End team through our weekly catch ups on this. I feel as though our success in this space is intimately tied together.
Recruitment and admin
Huge shout-out this week to Summer Field-Sinclair for her help in doing a bit of guerrilla testing on a scheduling tool. We’d done a test of a single type of subscription before and had identified issues with it managing calendars of multiple researchers while also protecting their identity. What would happen if we changed to a more expensive subscription? After 6 different kinds of tests, we found the scheduling tool was not doing what we needed, and we abandoned the tests. Onto the next platform!
Data and knowledge management
Not much movement on this this week, as it takes a lot of quiet, deep thinking time to do this work. Bill has been away (missed a lot!), and I’ve been doing interviews for onboarding new practitioners in the program (not research!).
I did meet with the client feedback team this week, and we discussed the potential for a monthly download of the qualitative feedback data. I had a look at their IA and data fields, and think having access to the de-identified data could be invaluable for us as our program matures and we start to want to see changes in the things people contact us for. It’s a good quick flag for the changes we’re wanting to see in UX, and so I’m excited to progress this with a data architect in Digital Trade Initiatives.
You see this a lot in building dashboards for UX (or at least, in the ResearchOps Community I have) — these are the places Voice of the Customer Programs spring from — that need to bring all insights together from across disciplines and across research and data spaces to make sense of them broadly. Will be interesting to see what emerges here over time.
Governance
I didn’t personally do much in governance, ethics, or consent spaces this week!
Tools and infrastructure
As mentioned, Summer and I did a series of tests on a scheduling tool this week, which was an interesting exercise in resilience….thanks Summer. We also found some support in the department for the project we’re starting next week (this week as I type, as I got this post out late!) on whiteboarding tools. Looking forward to just gaining clarity, writing up, and making decisions on that, as we also have evaluative research platforms decisions to be made, along with research recruitment platform/vendor decisions to be made as well. It would be nice to get these all knocked over by end of year, but with just one of me (while Bill is away), and the end of year fast approaching, I sure am glad for the times when we can make ReOps a team sport as well!
What are you thinking about?
Scaling practices and the overwhelm of that mid-point
I’ve spent a lot of the past four years thinking about how research happens, and working with the ResearchOps Community to map out the progression from getting started to having a fully functioning discipline in place. It’s a terrible irony to see oneself going through the sorts of struggles you’ve a) been through before, and b) have even written about in the past. A little bit like the stages of taking care of a baby and watching it grow, knowing a stage is a stage is helpful, but doesn’t stop one having to go through the stage. Back in 2019 I wrote:
I don’t think this has been said clearly before, that what ResearchOps is, is the lever to the promise of a tightly drawn and fully articulated revolution — a conductor for the orchestra of mixed-method research.
But it is a fine, fine line and the paths are not laid clear. The profession is not a linear, well-worn path. And so the lines, those silver threads of risk are not always obvious and easy to cross. Taking on Ops as a role means embracing this- there’s nothing to be done with it- it is taking the risks and pressures researchers bear individually, and placing them all squarely on the shoulders of one, two, maybe, hopefully more people. Like a stiletto becomes dangerous solely due to that bringing down of an acceptable weight onto one tiny spot, ReOps is the same.
I wanted to share with you all this sense of overwhelm at all the things to do, because if we only talk about the good stuff, how can you know that what you’re going through is normal? I think it is important to see the rocks in the road, and accept them as a part of it.
I also thought it was worth sharing here for a couple of reasons. Firstly, to reflect that there is this stage of research operations where you are scaling so fast that you can be so caught up in busy work, that it feels impossible to progress. If that’s you, please know, this is totally normal, and it is a stage. Just as your baby will one day sleep through the night, your operations processes, functions and ways of working will one day be second nature. You are at a critical juncture though, so don’t suffer in silence. Talk to your leadership team early, talk often. Don’t leave it ‘til you get to a state of overwhelm (she says to herself :) ).
Operations is operations because if it doesn’t get done, everything stops. Like the operations of moving people through airports or of preparing food in fast food chains, the tiny moving pieces all matter. That need for things to be done now can mean you fail to get the time to design the right systems and processes, or you struggle to prioritise them because you are running from one fire to the next.
I don’t know that there is a definitive answer to how to respond. I know at this stage in the process, (or what I think was that stage), Kate Towsey wrote a post about doing one thing well. For me, it is a physical impossibility to do only one thing well, and so that’s the reality I have to live in. It’s a tricky one. If I did one thing well, I’d not do it. That’s how I am made. In addition, to my mind, as I said before, if I choose to do one thing well, someone else is having to do the other things. And that’s actually fine, it just has to be a decision one makes and plans for.
Regardless, the very worst thing you can do at that point is to just stop without a plan — researchers have to trust that the operations tasks are better taken on programmatically, and that they will be done. Or they’ll just shoulder them again, and then their work won’t get done, or worse, they’ll each develop their own ways of doing things, and we end up duplicating effort and creating an environment where it isn’t possible to be strategic about your research or ops. But while you mustn’t stop, you also must find ways to make space for yourself because you have to have the space to make services and processes that are scalable (and largely, that means self-service). Researchers of all people know that delivering a good service takes good user research, good service design, process writing, and ultimately, service building (oh yes, it is very meta). In the meantime — you will undoubtedly, and unavoidably start with unscalable practices.
Getting off that hamster wheel is critical though. I think this is where your mantra of ‘research is a team sport’ becomes ‘ResearchOps is a team sport’. Find your team wherever you can, and get support. You will get those systems, processes, tools, templates, and guides in place if you do. Back in 2020, Kate Towsey wrote about having 1 Ops person per 5 researchers, whereas now, she is at the point of being able to service 80 researchers for every 1 Ops person. That difference is scalability, and that’s where you’re aiming. But that first year is person heavy — you’re flying a plane while building it. Don’t beat yourself up about it.
Do try to keep one eye on the horizon — your real job is the big ‘O’ ops stuff that takes a long, long time to get in place, so chipping away at that even during the overwhelm will help see this phase end. The simple, tricky reality is that if you are to get to the place of being able to see across the system, and alongside your research lead, be a conductor of the orchestra of mixed-method research, every piece matters — every string, every not-creaky seat. But so does the music. Don’t lose sight of the music. Practice will see you get there. Hold fast.
On leading through the overwhelm
The second reason for sharing is that I’ve been leading people for a long time (since 1997!), and I have some reflections on communicating overwhelm. Firstly, as a leader, if someone in my team tells me they’re overwhelmed— it tells me I’m a safe space for them, and so I always encourage people in my team to communicate with me, and do it early. Better that you communicate the overwhelm while it is something we can easily sort out. As a leader, I respond quickly, keep focused on the causes, not the effect, and try not to leave it for long, or take it personally. I don’t always succeed, but I do try.
If it’s you that’s overwhelmed, pick your people wisely (communicating up is usually best), be respectful, keep it about the work, and try to keep it positive when you can. I assume this is common knowledge, but we don’t talk about it, or it’s sibling — failure, much, so it seems worth articulating in any case. Sadly, overwhelm is uncomfortable, and for most of us, we push it down and down until we kind of snap. And so we often communicate when we are at place far from our best. It’s hard to think clearly and critically at a time like that.
Anyway, here are a few tips if it helps. No, I don’t always manage to follow my own advice :)
- Write it out. Don’t lay awake at night thinking about it. Writing it out will help you gain some clarity over the issues, the causes, and the effects. It may even help you find the answers. I reflect that I have managed to solve my own problems a few times this way. It’ll also help you stop thinking and start sleeping.
- If you do solve it yourself, don’t not communicate the overwhelm that got you there. Your leadership team, if they are a good team, need to know what’s got you to the solutions you’ve arrived at. That’s because you and your wellbeing matter more than the problems you’ve solved.
- Once you’ve written it out, sleep on it. You’re in a heightened state, and your communication will not be clear. Sleep solves a lot, as does a good long walk, if that is available to you.
- When you’ve slept on it, think about how you might communicate it in 3–5 key dot points. Even if you are going to meet and discuss it in person, your cognitive overload means you will not be able to communicate effectively no matter who you are. Overwhelm puts your mind into a state of scarcity, and so everything will be jumbled. Having your thoughts in order helps.
- Then, make a plan for how to communicate, when, and with whom. Pick your people well. It’s helpful if you know what you’re asking for. For me, a lot of the time it is that I have a problem that I need more brains to be put to the problem. I’ve exhausted my problem-solving capacities on my own. I like to think this is something I am extraordinarily good at, so it is usually my break point. I usually state what I need upfront because I write very long emails even when I’m trying not to :) (a kind of tl:dr for your reader!)
- Extra notes on neurodiversity, or diversity in general: If I’m with a leader I trust, they’ll get that awfully long email with all of my thought patterns sketched out. When you’re leading neurodivergent people, please let them be themselves. ND people can be an absolute gift and frankly a weapon for good, but the trade offs can be that their approaches to communication are just different from yours. You’ll also gain something different from what you’ve had from NT staff and so it’s a swings and roundabouts kind of deal. I’ve certainly been on the receiving end of long emails from my ND staff before too! Don’t be afraid to state your needs, and come to a way of working that suits you both.
The overwhelm doesn’t disappear of course, but talking about it can turn things around. I give vulnerability with safe leadership 4 out of 5 stars.
Anything else?
Speaking of vulnerability, this week just gone, I got to sit on a panel with some incredible storytellers, and talk about the art and science of storytelling as a part of the Digital Professions series, INNOV8 . It was definitely an imposter syndrome moment, where I had to lay it out — I don’t consider myself an actual storyteller — rather, a midwife for the stories themselves. I’ve not done much of that work yet at DAWE, but as we build out our user research library, I’ll get to stretch that capability again, with a lot of joy. It was wonderful to be able to reflect on the master storytellers I got to work with at Services Australia, such as the incredible Penri O’Rourke, and honour the integrity of her work and the work of the 50 or so other researchers I worked with regularly.
I may have waxed lyrical about working at DAWE, and working with leaders such as Jordan Hatch, because of the way they walk the walk, and are not afraid of the uncomfortable nature of user research — it (painfully at times) points out all the work we have to do to build a good experience. The point of that is focussing on the future we are trying to get to, and we can’t, if we’re going to be afraid of hearing what we need to do to get there. I give open and transparent government 5 out 5 stars.
As promised, we’ll blog post on it soon, and I’ll link to it in my weeknotes :)
Thanks again, Belle Hogg, Richard Hylerstedt, Libby Heasman, it was an honour to sit beside y’all and nerd out about stories.
