The Building Better Research Software workshop will take place over multiple days from Tuesday 5 May to Friday 8 May, from 9:30am to 1pm. There will also be a mandatory pre-workshop setup session on Friday 1 May from 10am to 12pm.
The Building Better Research Software course teaches tools and practices for producing and sharing quality, sustainable and FAIR (Findable, Accessible, Interoperable and Reusable) research software to support open and reproducible research.
The Intermediate Research Software Development Course will take place on 13 - 16 April 2026 at the University of Manchester. The course, which is based on material developed by the SSI, aims to teach a core set of established, intermediate-level software development skills and best practices for working as part of a team in a research environment using Python as an example programming language. The core set of skills is not a comprehensive set of all-encompassing skills, but a selective set of tried-and-tested collaborative development skills that form a firm foundation for continuing on your learning journey.
The workshop is delivered by EPCC (Chris Wood and Evgenij Belikov) with the help from SSI and Manchester RIT.
The Software Sustainability Institute, in partnership with King's College London, the University of Cambridge, and the University of Edinburgh, is pleased to announce the Digital Humanities & Research Software Engineering Summer School 2026, taking place at the University of Manchester from Monday 29 June to Thursday 2 July 2026.
Attendance is free, and limited bursaries of up to £650 are available by application to support those who need financial assistance to attend.
Who should apply?
The Summer School is aimed at postgraduate students, researchers, academics, and technical professionals who use code and data in their work and are looking to engage more deeply with Research Software Engineering (RSE) practices. Participants from a wide range of disciplines are welcome — including history, literature, linguistics, archaeology, art history, musicology, cultural heritage, and many more. Some prior coding experience is desirable, though a computer science background is not required.
In November 2025, the Digital Arts and Humanities Research Software Engineers Midlands (DAHRSE Midlands) community gathered online for its first meeting. The theme “Co-Creating DAHRSE Midlands: Vision, Voices, and Next Steps” was all about collaboration, inclusivity, and building momentum for Digital Arts and Humanities Research Software Engineering in the Midlands.
The DAHRSE Midlands community is growing as a collaborative space for Digital Arts and Humanities Research Software Engineers (RSEs) across the region. This meeting focused on shaping our shared vision, amplifying voices, and planning actionable next steps to strengthen our network.
This event was proudly supported by the Software Sustainability Institute (SSI) via their fellowship programme; their commitment to building sustainable software communities made this event possible.
Godwin Yeboah, from the University of Warwick and SSI Fellow, introduced the DAHRSE Midlands initiative, outlining its goals, objectives, and early activities. These were further discussed during the community discussion section, where members contributed ideas and feedback.
He also proposed a desktop study titled:
“Exploring the Landscape of Digital Arts and Humanities Research Software Engineers in the Midlands: A Preliminary Desktop Study and Working Paper.”
This study aims to explore the institutional landscape of DAHRSEs in the Midlands—mapping where Digital Arts and Humanities Research Software Engineers are based, particularly within universities, the GLAM sector (Galleries, Libraries, Archives, and Museums), and research groups. It will examine their contributions, especially those visible online, and highlight the roles these RSEs play within their respective institutions.
Working research question:
What is the current landscape of Research Software Engineers in the Digital Arts and Humanities in the Midlands, and how do they contribute to, and impact the field?
This initiative and the proposed study represent an important step toward understanding and strengthening the role of RSEs in the digital arts and humanities ecosystem.
Catherine Smith, from the University of Birmingham and SSI Fellow, demonstrated practical tools for manual accessibility testing of websites—an essential step beyond automated CI tools. Her talk highlighted how browser extensions can help improve accessibility compliance in humanities web projects.
Catherine reminded us why manual accessibility checks matter:
“Automated tools can only take you so far—manual checks are essential to check accessibility criteria are being met.”
She demonstrated browser extensions that make manual accessibility testing easier and more effective, helping humanities web projects ensure that there are no barriers for people interacting with the material and also that they comply with legal standards.
Tools mentioned:
Iain Emsley, from the University of Warwick, shared insights from a project using older mobile devices for AI mapping in urban spaces. His discussion raised critical questions about planned obsolescence, sustainability, and policy implications for Digital Humanities hardware projects.
Iain’s talk sparked a fascinating discussion on sustainability and innovation:
“Planned obsolescence creates challenges—but it also opens creative possibilities for reusing older hardware.”
He shared lessons from a project using old mobile phones for artificial intelligence (AI) mapping, raising questions about policy, testing constraints, and the skills needed to keep legacy devices in play.
The most dynamic part of the meeting was our open discussion. A clear theme emerged: start small, grow organically. Rather than chasing big, shiny ideas, we’re building momentum through doable, repeatable activities that help people connect and share.
We agreed to refine the “Join our community” page so it reflects the breadth of roles in our space—especially those without a formal “RSE” title who still write code, build workflows, or steward research software.
Guiding questions we’ll feature:
We’ll also conduct a desktop study (see above) to understand the regional landscape and publish blogs that share ideas and practice.
To improve visibility and make joining easier, we’re streamlining our channels and processes:
For those who prefer updates without formal membership, we’re adding a “Stay informed without joining” option on the website.
A big thank you to the Software Sustainability Institute (SSI) for sponsoring and supporting this meeting and overall initiative. Their work in promoting sustainable software practices continues to empower communities like ours.
Thanks also to DAHRSE community members Catherine Smith and Iain Emsley for their insightful talks and contributions to the discussion. We would also like to acknowledge SSI Fellow Iain Barrass for kindly volunteering to review our draft.
We agreed to:
Want to help shape the future of DAHRSE Midlands?
Together, we’re building a connected, sustainable community for Digital Arts & Humanities RSEs in the Midlands—one small, purposeful step at a time.
Iulia Georgescu, science manager at the Institute of Physics, has published a new Physics World feature titled The forgotten pioneers of computational physics. The article traces the origins of research software engineering and highlights the many figures whose contributions were overlooked, whether because computational scientists were undervalued, much as RSEs often are today, or because sexism erased the work of the many women who drove early advances in the field.
RSEs can lead on sustainable research - but we can't just rely on their goodwill
RSECon is always a highlight for the Research Software Engineering community. There is a special energy when RSEs come together: shared purpose, practical problem-solving, and genuine warmth. At this year’s conference, we channelled some of that enthusiasm to address a pressing question: how can we reduce the environmental impact of digital research?
It is a complex challenge. RSEs are uniquely positioned to influence sustainability through efficient software, considered use of compute, and by supporting researchers to adopt lower-impact approaches. Yet sustainability is often absent from RSE job descriptions. The skills are there, but the structures, expectations, and opportunities are not always in place.
To bridge this gap, we conceived the Green RSE Special Interest Group (SIG) with the objective of embedding sustainability more deeply into research software practice. We believe that if we can bring together the knowledge and experience already held across the community, and provide clearer support and confidence to act, the transition to more sustainable digital research can be faster and easier for everyone.
The Green RSE SIG was launched at RSECon24, and this year we returned with progress to share and new challenges to explore.
RSEs clearly have the skills and the motivation to make research computing more sustainable. What is often missing are the systems, incentives, and resources that allow this work to become part of everyday practice. |
We enjoyed a great range of talks, including Martin Farley (UKRI), who introduced the new SPARK-Hub platform, designed to provide researchers with practical actions and guidance on sustainability, helping them track their progress and gain recognition for their efforts. Wahab Kawafi presented on quantifying emissions from the new Isambard AI system, and Andy Turner shared insights from his work on Green RSE training and advocacy.
Talks were followed with a Mentimeter survey on the Green RSE training more generally. Attendees showed a tendency towards needing support on how to improve the sustainability of their code, but also on how to convince their colleagues (both within and outside of RSE) to consider and adopt Green practices. We gathered many suggestions on what Green RSE training should focus on going forward, as well as things attendees’ groups are already doing that might be of use to others. These will be used to inform SIG blog posts and activities.
It was good to see how much has moved forward. More people are experimenting, sharing tools, and treating sustainability as a core part of good research practice rather than an optional extra.
We then ran community discussions on a subset of the sustainability principles for RSEs, first developed at RSECon24.
RSEs identified the following as priorities at RSECon24:
(These principles were selected at RSECon24 from a longer list, they were identified as being both important and achievable)
For each principle, we asked four questions: What gets in the way? What helps? Who holds responsibility? What should we do next?
There was a mixture of enthusiasm and realism. Many RSEs want to embed sustainability into everyday work. However, there was a clear understanding that this cannot rely solely on individual enthusiasm. Time, training, resources, and recognition all matter. RSEs already juggle many priorities, and while greener choices are desirable, people need support and structure to do this well.
At RSECon25, we found there to be strong enthusiasm across the community to build sustainability into everyday practice. Many already view it as part of good engineering: writing efficient code, using greener CI/CD, choosing appropriate compute resources via informed job scheduling, and helping researchers do the same.
However, we also heard clear challenges:
Participants shared practical ideas already in use: tools like CodeCarbon are helping track emissions, Pando Carpentries offers accessible training, and some institutions are using Slurm-based estimates to make energy consumption visible to users. |
Alongside these challenges, the mood in the room was practical and optimistic. Participants highlighted the need for:
A strong theme was that responsibility should not rest on individual RSEs alone. Funders, PIs, institutions, and infrastructure providers all have roles to play in shaping expectations and making change possible.
The message from the session was clear. RSEs are ready and willing to lead on sustainable research computing. However, to make real progress we need shared action, not just individual effort.
Over the coming year, the Green RSE SIG will:
A Green RSE Manifesto?
One idea we've been exploring is a "Green RSE Manifesto" - a lightweight set of commitments and principles that RSE groups could voluntarily adopt. This would be co-created with the community, not imposed top-down. The aim would be to offer a shared foundation and help signal collective intent, rather than to add pressure or create gate-keeping. We'd love to hear what RSEs and group leaders think: would this be useful? What would make it work for your context?
It is still early days, but there is real momentum. If you would like to get involved, whether you have tools to share, challenges to explore, or simply an interest in the topic, we would love to hear from you. Visit our webpage or join #green-sig on UKRSE slack.
UK Government AI for Science Strategy and SSI Responsible AI in RSE study group
Today, the UK government announced its AI for Science Strategy, setting out actions to ensure the UK’s scientific ecosystem not only adapts to, but benefits from the AI for science revolution. The strategy focuses on developing a data landscape that facilitates transformative research, ensuring researchers have access to large-scale compute, building interdisciplinary research communities, and capitalising on rapid advances in autonomous labs and both general-purpose and specialist AI tools.
This blog is part of the Research Software Camp: Careers and Skills in Research Software series.
Research Software Engineering (RSE) is a crucial component of modern research, but as a profession, it is often misunderstood, under-recognised, and discovered by accident. Researchers often find themselves writing software long before realising that their work constitutes a career pathway in its own right. While RSEs’ contributions are not always supported or acknowledged, the field is gaining visibility, and efforts to strengthen recognition and support are growing.
This article brings together RSEs' perspectives across different fields and institutions. Through their reflections, we explore how people come to recognise software as research, the challenges of navigating the boundaries between researchers and engineers, the complexities of career progression, and the changes needed for research institutions to better support their work. Their insights also offer a perspective on the future of RSE and how generative AI, shifting research cultures, and evolving training pathways will influence it.
The RSE profession is not always well known, and many stumble into it by chance or work as RSEs without knowing the role has a name. RF and PVM discovered RSE well into their careers. RF “didn’t know what RSE was until mid-Covid” when he was brought in to work with other RSEs on the Fair Data Pipeline. Although he was meant to be a data scientist, he found himself writing the software. PVM similarly notes that RSE was not really talked about during his PhD in Spain and that only after three years working in the UK did he realise he had “been an RSE for almost 8 years.”
PF suggests that there are two ways people learn about the RSE profession. The first, through using software and tools in their research, the second — as in his case — by “writing code from scratch to solve research problems.” Of course, he points out, there is a distinction between writing software for research and it being “recognised as research or considered on the same footing as other research outputs.”
AM adds that the “best scientists aren’t always the best software developers” and that the two are “quite distinct disciplines within the research community.” Similarly to the others, he also did not expect to write as much software as he did when he joined the Met Office as a Researcher, but that “it became a big part of the job.”
RSE would be more rewarding if software was treated as a first-class research output. AM believes that it is important to focus on what you enjoy and are good at. For him, that means working as an RSE and “creating reproducible software and enabling other scientists to do their great work.” PVM agrees, but points out that it is hard to make yourself heard and champion better research software practices when “there isn’t really time and capacity for that,” as teams tend to prioritise results and papers.
RF notes that it would be nice to be involved from the very start of a project, but that he usually “gets invited to look at the software after the research is done.“ He argues it should be a “collaborative effort and shouldn’t be an afterthought.” PF adds that “as a PhD student and postdoc, it was research first and software second,” but that as an RSE this balance has “reversed to some extent.” He recognises the tensions others describe, and observes that during his post-doc in the US, RSE roles were referred to as “computer facilitator” or “cyber infrastructor.”
Career progression in the RSE field seems to be uneven and often constrained or poorly defined. PVM would like to continue working within research, but struggles with the expectation that researchers must run experiments, a requirement that consistently appears when applying for funding. In biology, experimental work remains the “golden standard”, while some still consider computational work to be mere support and image analysis only a “pretty picture.” As a result, he has considered pursuing the RSE path or even moving into freelance work. RF adds that his institution offers scientist and technician tracks, and he chose the scientist one. However, he notes he might have “left for industry” had he not been on a permanent contract and able to apply for grants more easily than others.
PF is interested in finding out what RSE career progression looks like outside academia. At his institution, RSEs feel like an afterthought within the career framework. There are scientist and technician tracks, and RSEs are placed on the former but are only explicitly mentioned in two of the five available tiers. Progression criteria revolve around publications, teaching, and grant success, activities that “may not directly translate to RSE roles.” In practice, however, RSEs are well supported by team leaders who are themselves RSEs and understand what the role involves. AM notes that the Met Office also offers two tracks, scientist and RSE. Because the organisation sits within the Civil Service, career progression is limited, but he highlights “there are a lot of skills development and learning opportunities.”
Funding and proper resourcing sit at the heart of the issue when it comes to how research institutions support software work. RF argues that institutions need to offer stable, full-time contracts and recognise that sustainable software requires sustained investment. He notes, however, that the field is not yet in a position to match salaries in industry, “because there’ll always be a disparity between industry and academia.” AM expands on this by highlighting the need for “proper planning of resources for projects.” Many teams simply do not have “enough people to get the work done,” or the work progresses inefficiently because the initial project planning failed to account for the true effort involved. As he puts it, “planning is hard” and “it takes a lot of experience and knowledge to do it well.”
PF argues that these planning challenges stem from a deeper issue: a lack of understanding of what RSEs actually do and how they contribute to research. In his view, “once people better understand what the role entails, then other aspects will follow, including the planning AM mentioned.” Research teams often underestimate the time needed to develop software, leading to misplaced expectations or evaluations of RSE contributions. He emphasises that “supporting software work is fundamentally about supporting the people who make software work.”
Another issue is the long-term sustainability of research software. PF points out that project proposals rarely include funding for ongoing maintenance, and PVM agrees, noting that there is “no time allocated for maintaining software.” As for solutions, RF suggests that the community needs more programmes like the SSI’s Research Software Maintenance Fund, as well as broader recognition among funders that software “needs to be maintained.”
Recognition of RSE work varies widely across institutions and academia. At the Met Office and within the Civil Service more broadly, AM explains that RSE contributions are “recognised quite well, with clearly defined career families, and recognised as being essential” to all aspects of software-related work. He emphasises there is a growing appreciation for the skills RSEs bring.
RF describes a different experience at his university, where RSEs are less established compared to other institutions and many colleagues are simply unaware of “what RSEs do and how they can help.” As a result, much of their work is conducted through existing networks and personal connections, which shows that the contribution of RSEs is recognised once people experience it firsthand.
PF agrees that academics and project partners who have worked directly with RSEs typically come to understand and appreciate their contributions, often returning for further collaborations. Yet broader recognition remains a challenge. Within his own institute, senior team leaders provide a supportive environment, ensuring his work feels acknowledged. He highlights that academia remains overly focused on publication count as the primary metric for research success, and there is “a long way to go before software is understood as a tangible output in its own right.”
PVM echoes PF’s points, noting that when seeking postdoctoral positions, recognition depends heavily on the principal investigator. Some PIs “do not truly appreciate” RSE work, while others recognise its importance “for the future of [...] research”.
The future of RSE work is seen both with optimism and caution, as new technologies and evolving research practices reshape the landscape. PF acknowledges reasons for optimism but expresses uncertainty about the impact of generative AI, noting that it gives researchers who do not know how to code access to tools that may “complicate how RSEs contribute in the future.” PVM takes a more confident stance, arguing that “Gen AI is a reason as to why RSEs are more important than ever,” explaining that while AI can generate simple code, it cannot truly understand or maintain it. RF agrees that generative AI is unlikely to replace RSEs, but highlights emerging funding trends that emphasise AI in grants for RSE. AM echoes these points, observing that “Gen AI has the potential to greatly help researchers to write code, but doesn’t replace the role of the RSE.”
The future of RSE will also rely on education and training. PF suggests that universities should offer more RSE-related modules. This would offer students the opportunity of discovering RSE earlier in their lives, and maybe realise it is a career path they’d like to pursue.
A greater recognition and understanding of RSE work is fundamental for the future of the field. PVM emphasises that more appreciation of the contributions made by RSEs is essential. PF adds that stronger “communication and collaboration between communities,” such as HPC operators, dRTPs in industry, and open-source contributors, could foster valuable cross-pollination, benefiting all parties by sharing skills, approaches, and outcomes.
RF notes that while software validation can occur within research institutions, external partners often need to apply their own metrics. He also highlights differences with industry, where work moves faster but is constrained by costs and stricter intellectual property protections, including NDAs that can slow collaborative processes.
Across all discussions, it appears clear that, although research today depends deeply on software, not everyone within the field has fully adapted to this reality. RSEs often discover their profession after years of writing code, they can face unclear or constrained career pathways, they navigate environments that undervalue maintenance and long-term sustainability, and their recognition varies depending on different institutions and individual managers. And yet there is growing awareness of the importance of software in research and increasing appreciation for the specialised skills RSEs bring. There are opportunities for better planning, funding, and stronger collaboration. Generative AI could be a threat, but it could also reinforce the need for experts who know how to write code and, crucially, why it is done that way.
To ensure the future of RSE continues to be bright, institutions and academia need to acknowledge the role of RSEs in achieving research excellence, treat software as a research output in its own right, and provide career pathways and structures that reflect their value. The path forward requires change, and the first step is realising that supporting research software means supporting the people who build it.
Participants | |
Pablo Vicente Munuera | Postdoc, University College London |
Piper Fowler-Wright | Research Software Engineer, Rosalind Franklin Institute |
Ryan Field | Research Software Engineer, University of Glasgow |
Andrew McNaughton | Research Software Engineer, Unattached (previously Met Office) |
Facilitators | |
Events Manager, SSI, University of Edinburgh | |
Director of Strategy, SSI, University of Southampton | |
This blog is part of the Research Software Camp: Careers and Skills in Research Software series.
Effective outreach is key to growing and diversifying the scientific computing community, engaging everyone from students and researchers to policymakers and the public. Yet, many organisations struggle to build or sustain outreach programmes, especially without dedicated staff or resources.
At the 2025 SSI Research Software Camps, we ran a session designed to ease those challenges by showcasing practical ways to reuse, repurpose and reinvent existing outreach materials. The idea is simple: instead of reinventing the wheel time and time again, let’s use existing materials as the baseline for our own outreach activities.
We defined three scenarios when using existing materials:
Each of these approaches requires care and attention to important factors, such as accessibility, communication style, and audience background knowledge, to ensure effective and impactful outreach. This workshop equipped participants with a ready-to-use strategy, lowering the barrier to enable those new to outreach to take existing materials and adapt them to their own contexts.
We did this by featuring three invited speakers to present three successful outreach activities:
Fired up by these presentations, the workshop participants then split into breakout groups to discuss how the presented activities can be reused, repurposed and reinvented.
All three of the activities were very easy to reuse, low-cost, and easily adaptable to materials that most centres will already have access to. This extended into discussions around accessibility, where participants reflected on how activities could be reused in areas of the world where certain infrastructure or material is not available. Their fun and interactive nature means they appeal to a wide range of ages - especially the “Where’s Wally?”-style Beat the AI, which adds a nostalgic element.
When discussing repurposing, each activity was found to be very flexible in terms of how much technical depth can be introduced. Explanations can be extended to include more complex concepts where appropriate, making them suitable for repurposing across diverse audiences. For example, Parallel Sort can grow from a simple demonstration of speed-up to exploring ideas like bottlenecks, load balancing and race conditions. Importantly, none of the activities require participants to have a technical background to enjoy and understand them. This makes them accessible and inclusive entry points into scientific computing.
That said, some activities presented challenges when repurposing them for older audiences. For example, Plant-Me-A-Plant works beautifully with younger groups as they all shout over each other and excitedly make a mess! However, this can be less relatable for adults or specialists. Instead, participants suggested using more detailed tasks (like baking a cake or drawing a cat) or detailed instructions to demonstrate the same learning objective. Perhaps working in pairs, with one member blindfolded and the other giving instructions.
The reinvent discussions proved especially creative. For Plant-Me-A-Plant, ideas included integrating testing and debugging phases or introducing AI-generated content as a discussion point for reliability and bias in technology. Beat the AI could be used to access researchers in a broader set of areas by using pictures with medical imaging or astronomy, or even to teach how searching algorithms work. And the Parallel Sort could be used to demonstrate data handling or fault tolerance by removing a player halfway through.
Upon reflection, this format provided a useful framework to discuss the sustainability of outreach materials in different contexts. However, separating the discussions into reuse, repurpose and reinvent was challenging! These areas often overlapped in practice, making it more effective to explore each activity through specific scenarios rather than stick strictly to each topic.
This session was organised in collaboration with Computational Abilities Knowledge Exchange (CAKE) and members of the SocRSE EDIA Working Group. We encourage readers to explore and engage with these communities to further support knowledge exchange initiatives and sustainable outreach.
Research Technical Professional Career Paths in UCL’s Advanced Research Computing Centre
This blog is part of the Research Software Camp: Careers and Skills in Research Software series.
ARC is UCL’s research, innovation & service centre for the tools, practices, systems and people that enable computational science and digital scholarship. Formed in August 2021 as an evolution of the Research IT Services unit within UCL’s Information Services Division (ISD), we are now an explicitly hybrid independent department, with both professional services (PS) and academic missions. We provide advanced, reliable, and secure digital research infrastructure – including hardware, software, data, and skills – to researchers in UCL and beyond. We are also a laboratory for research, teaching, and innovation in compute, data, and software-intensive research methods.
A key aim with the hybrid nature of ARC has always been to provide a home for digital research technical professionals – who support and collaborate in the delivery of team-based research, but don’t fully fit into traditional PS or academic career pathways. We seek to provide outstanding career development opportunities for these staff, now all on permanent contracts, so that they can apply their skills to cutting-edge research problems for the greatest public benefit.
Alongside wider work within UCL on career frameworks, when forming ARC we therefore sought to harmonise the many custom job descriptions in use for staff in different teams and roles into a coherent framework that could form the basis of career pathways for personal development and progression. This was done through an extensive co-creation process with staff. While the leadership team had ideas for what the structure could look like, we wanted to ensure that everyone felt they fit within one of the job families and that their current role was at the correct grade (and salary). The text for each job description was developed within a wiki, and both comments and direct edits were encouraged from all staff.
To ensure we had a comprehensive set of professions that covered all the activities within ARC, we settled on five pathways: Data Scientists, Data Stewards, Research Infrastructure Developers (RIDs), Research Software Engineers (RSEs), and Professional Research Investment and Strategy Managers (PRISMs). The last group took the longest to finalise, as it provides an umbrella for the operational and administrative roles essential for the department to function, such as comms, finance, and HR, as well as project and community managers, and hence had to capture a wider breadth of activity while integrating with the still forming national PRISM network.
Our job descriptions (JDs) were also designed from the start to support career progression, and together with ISD, we were able to pilot a promotion scheme in 2022, which now runs annually. This meant that the JDs are structured in an additive fashion, with enhanced duties, responsibilities, and selection criteria at each grade. These show clearly what skills staff need to be able to demonstrate to progress. They are written in general terms that are common to all the job families, simplifying the process for both staff and the review panel. The duties and criteria specific to a single profession are in the base JD for that profession. This structure is easier to follow in our original wiki format, which has been published as part of the RSE Evidence Bank. It also makes it easier for staff to move diagonally between professions as they pick up skills, and to self-identify with a range of different job titles that can still match to a single JD (e.g. calling themselves a bioinformatician while being on either an RSE or Data Science JD).
A further benefit of the commonality between professions is that it helped us extend every profession to grades that did not previously exist within the department, at either end of the career ladder. Each profession has a director-level option, whereas before, only the head of department was a director, and we now have three staff members from two professions on that grade. At the entry level, we can recruit graduates and apprentices into each profession, allowing us to train up staff internally, especially for professions that are harder to recruit to, such as RID.
The JDs also allow for many different pathways to seniority. Not every leader needs to be a manager of people or projects! For example, someone can progress to Senior grade by “leading design, architecture and implementation for one or more technical aspects of research projects or service changes” and “design and delivery of teaching and training courses.” We have had staff follow a technically focused pathway to Principal level, and conceptually this could be extended to Director.
The benefits to our staff of having career progression opportunities to senior levels and commensurate salaries are perhaps clear. The case also needed to be made that this scheme provides benefits to the institution, and that any cost increases are affordable. The business rationale was to attract and retain top talent in a competitive market, supporting the university’s digital transformation efforts with staff that can lead innovation, and save on the high recruitment and contractor costs associated with turnover. The scheme supports internal growth by providing structured paths for staff to take on higher responsibilities, enhancing performance and productivity. A structured, annual promotion cycle with clearly defined criteria, transparent procedures, and detailed feedback on decisions is better than ad-hoc one-off arrangements for individuals and thus yields better pay equity.
The scheme utilises UCL's Information Technology Career Framework within ISD, the Research Technology Professionals (RTPs) Framework in ARC, and UCL Ways of Working across both, aiming to ensure the comparability of excellence across the departments. As of 2024, the Sainsbury Wellcome Centre has aligned with the ARC promotions process, allowing promotion of RTPs outside of ARC as well, and we hope that this approach will expand across the university.
The situation is therefore not static! We have been very pleased with the adoption of our career families so far, and staff turnover has reduced year-on-year. However, we’re not resting on our laurels: work continues to improve career pathways for staff in ARC and beyond through our internal People Plan, research culture strategy, and involvement in national initiatives such as DisCouRSE.
