Setting the scene
As Research Software Engineers (RSEs), we’ve often been used to seeing ourselves as collaborators, working alongside academics to solve a research problem. But what happens when you shift perspective, and start to see the people you work with as users of a service? The questions change. Instead of ‘how should we approach this together?’ you find yourself asking ‘what are you trying to do, and how can I help?’
For RSEs, this shift is quite significant, as it changes how we think about boundaries, the direction of value, and what success looks like. It’s not a shift that comes naturally, and it was a theme that emerged through conversations and activities at our recent event, From Overload to Clarity.
In this article, we share some of the ideas and insights that emerged on the day, and why we think they matter.
Why we did this
The idea for this event grew out of a recognition that there are real capability gaps within the RSE community—gaps that aren’t always visible from within. To understand what these might be, we started with some research, talking to RSE leaders and running a community survey. This helped us identify where to turn our attention first.
What emerged was a focus on developing a service mindset among RSEs, and specifically on introducing systems thinking and user-centric design as practical tools for doing so.
Bringing industry voices into the mix was an important part of the design. The connections that shaped the programme began at the 2025 Leeds Testing Atelier, where I delivered a short talk on ‘A glimpse of life as a Research Software Engineer in academia.’ This was partly about stimulating learning across different contexts – industry and academia – which I believe can be valuable in both directions.
Collaborator vs Service Provider: What’s the difference?
| Collaborator | Service Provider | |
| Roles | Shared, fluid | Clear and defined |
| Focus | Shared problem-solving | User needs at the centre |
| Value | Created together | Flows in one direction (to the user) |
| Boundaries | Informal | Explicit |
| Key question | “How do we approach this together?” | “What do you need, and how can I help?” |
The GOV.UK Service Manual’s guidance on understanding a user’s whole problem offers a useful framework for thinking about how our service sits within the broader landscape of tools and services that researchers navigate. See also: GOV.UK Design Principles — Principle 1: “Start with user needs.”
The GOV.UK Service Manual’s guidance on understanding a user’s whole problem offers a useful framework for thinking about how our service sits within the broader landscape of tools and services that researchers navigate. See also: GOV.UK Design Principles — Principle 1: “Start with user needs.”
The day itself
28 delegates, comprising Research Software Engineers and IT service professionals from 5 institutions, came together at Cloth Hall Court in Leeds, along with speakers from local industry.
The day’s programme featured a blend of talks and hands-on workshops. Sarah Turner, a senior business analyst and expert in user-centred service design at the University of Leeds, delivered an engaging introduction to the principles of user-centred design. Delegates were invited to explore how they might approach understanding user needs across a range of scenarios, and it was interesting to see the differences in approach emerge—particularly the tendency toward conversational methods, which fits well with consulting-style engagements. Sarah was keen to emphasise that there isn’t a single right approach; the key is selecting the method that best suits your context and constraints.
Chris Sherlock, a test engineer from Nimble Approach in Sheffield, brought a valuable technical perspective, showing how user-centric design principles are woven into technical delivery processes throughout the development lifecycle.
Royd Brayshay, director of New-Redo, an agile consultancy based in Leeds, led an interactive exploration of agile delivery through a systems thinking lens. Royd was careful to emphasise that principles should be the starting point rather than specific frameworks or methodologies, and that the core goal of agile is to deliver the most value from available resources.
Royd challenged us to apply a systems lens by playing a coin game. Participants move coins—representing units of value—through a system, each person responsible for their own section. The natural instinct is to optimise your own part of the pipeline. But when participants tried working in smaller batches, something interesting happened: their own section slowed down, yet value moved through the whole system faster. If we think of those coins as value to a user, it seems clear that a user would rather receive some value sooner than wait a long time for a large batch.
The game also surfaced other things: easy-to-miss system flaws, like the cracks in the table that made passing coins between sections difficult, and idle capacity when large batches left parts of the system with nothing to do. It challenged us to change the question from ‘how do I make myself stronger?‘ to ‘what’s actually better for the person I’m doing this for?‘ Another clear lesson was about pace. When participants tried to handle too much at once, the process became frantic and exhausting. Slowing down and focusing on one unit of value at a time made everything calmer and more sustainable. From Overload to Clarity, literally.
All images © Victor de Jesus 2026
What people took away
While limited, the feedback we received from attendees was positive, suggesting the event had been a valuable learning experience. People valued the opportunity to step back from day-to-day work and make space to reflect with colleagues on how they are operating.
Several attendees found Sarah’s workshop on user-centric design particularly insightful, saying it opened their eyes to areas of their practice they hadn’t previously considered. During Royd’s workshop, participants were given space to notice friction points or sources of tension in their services. Being able to name these, and recognise that others were experiencing similar things, was both validating and illuminating.
Why this matters for RSEs
The event surfaced several important and often overlooked capabilities that RSEs need but don’t always recognise. While these are talked about more often in industry contexts, they remain under‑developed in many research environments. The day reinforced how much these capabilities matter for navigating the ambiguity, complexity and demand patterns that shape RSE work.
Service mindset
As RSEs, we do collaborate with researchers—but that collaboration happens within a service relationship, not outside it. Recognising this helps make boundaries clearer: what we’re responsible for, what we’re not, and where value is actually flowing.
A service mindset doesn’t diminish collaboration; it gives it structure. It helps us ask different questions (“What outcome are you trying to achieve?”) and protects us from the overwhelm that comes from treating every request as a shared, open‑ended endeavour.
Systems thinking
The coin‑flow exercise really brought this to life. Academic environments often optimise for individual effort—our own efficiency, our own technical excellence, our own queue of tasks. But systems thinking shifts the focus to the wider flow of value: not the speed or volume of what we produce, but whether our work improves outcomes for the researcher and the broader research community.
For RSEs, this perspective is valuable. We work inside complex, interdependent systems—research groups, IT services, infrastructure, governance processes. Local optimisations (“I’ll answer tickets faster” or “I’ll take on more”) often worsen systemic bottlenecks. Systems thinking helps us spot where work gets stuck, where expectations misalign, and where small changes elsewhere could relieve pressure on us and our users.
User‑centricity
At the heart of this is the ability to sense and respond to what users truly need—not just what they ask for. Many RSE engagements start with a request framed as a technical solution (“I need more storage space”, “I need a dashboard”). The real need is almost always deeper, broader, or different.
User‑centricity gives us the tools to uncover those needs. It helps us design services that reduce friction, improve clarity, and make better use of limited RSE capacity. In many cases, it also helps us say no—with more confidence and more empathy.
What’s next
For us, this was just the beginning of an ongoing conversation. Some of the things we’re taking forward include defining clearer service boundaries, learning more about our users and their needs, and continuing to develop our thinking in these areas.
We’d love to hear from others supporting research about how you’re tackling complexity, applying these approaches in practice, or taking different approaches entirely. Get in touch by emailing RCTeam at the leeds domain.
Want to explore further?
If the ideas in this article have sparked something, here are some starting points:
Systems thinking resources:
- Untools. (n.d.). Systems thinking. https://untools.co/systems-thinking/
- The Systems Thinker. (n.d.). The palette of systems thinking tools. https://thesystemsthinker.com/palette-of-systems-thinking-tools/
User-centric design:
- GOV.UK Service Manual. (n.d.). Design. https://www.gov.uk/service-manual/design
- GOV.UK Service Manual. (n.d.). Map and understand a user’s whole problem. https://www.gov.uk/service-manual/design/map-a-users-whole-problem
- Downe, L. (2020). Good services: How to design services that work. BIS Publishers.
