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.

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.

Green RSE SIG - one year on

The Green RSE SIG was launched at RSECon24, and this year we returned with progress to share and new challenges to explore. 

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.

The principles

RSEs identified the following as priorities at RSECon24:

• Funding applications for software projects and RSE posts should include a sustainability component
• RSEs have a responsibility to consider environmental impacts in the projects they support
• Sustainability should be included in RSE job descriptions where appropriate
• RSEs should track the energy usage of the software they produce and use
• RSEs should develop consistent methodologies for estimating energy use
• RSEs should be trained in green computing best practices
• RSEs should train and support researchers to work more sustainably

(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.

What the community told us

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:

• Sustainability often sits beside, rather than within, core responsibilities
• There is limited time and training available
• Benchmarking and measurement tools are often not consistent
• It is not always obvious where to start or what “good” looks like

Alongside these challenges, the mood in the room was practical and optimistic. Participants highlighted the need for:

• real case studies and examples
• accessible training (with some pointing to the Pando Carpentries)
• guidance and expectations set by funders and institutions
• simple, standard approaches for measuring energy use
• shared tools and best practice from within the community

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.

What happens next?

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:

• collect and share examples of good practice
• highlight training and learning opportunities
• work with partners, including funders, to embed sustainability expectations
• explore simple and consistent approaches to measuring energy use

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.

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.

When did you first realise that writing software could be part of doing research - and not just a tool for 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.”

Have you ever felt caught between being a researcher and a software engineer? How do you navigate that?

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.”

What are your thoughts on career progression?

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.”

If you could redesign how research institutions support software work, what would you change first?

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.”

How is the work of RSEs recognised within your organisation and in academia in general?

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”.

How do you think RSE work will change in the future?

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.

Any other general thoughts?

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.

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:

1. Reuse: In the most straightforward case, we may be able to take an existing activity and use it again, largely as it was originally designed or with only minor adjustments. This works well when your new use has a similar audience or a similar setting. The “reuser” has a very low barrier to getting started! They just need to know enough about the activity, key concepts and gather the materials to get started with ease.
2. Repurpose: Often, different organisations will need to outreach to different audiences, in different settings or for a different purpose. In this case, an existing outreach activity can be adapted to accommodate these differences. This may require moderate levels of change, with the goal of ensuring that the material remains relevant and engaging in the new context. In this manner, we can extend the life of outreach activities and enable new centres to tailor their activities to meet their specific needs.
3. Reinvent: In other cases, organisations may find they need to communicate an entirely different learning objective or idea. But, this doesn’t mean they need to start from scratch! An existing outreach activity can be used as the basis for a new one, using the materials to inspire and create a new activity from a foundation that is proven to work. This approach offers space for creativity and new ideas, while circumventing the need to start from a blank page.

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:

• Karina Pesatova’s activity challenges participants to “Beat the AI” by seeing who can find the hidden key in a busy image fastest. This activity is part of a workshop for school groups, but has also been used at science fairs.
• Darren White introduced a Parallel Sorting activity, where participants are timed to sort objects into different categories. Over the course of a science fair, this produces a graph demonstrating parallel speed up!
• Will Furnell acted as a robot being instructed to “Plant-Me-A-Plant”, only taking instructions literally to demonstrate the basics of computer algorithms. This messy activity is fun, fast and engaging for young children.

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.

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.

This blog is part of the Research Software Camp: Careers and Skills in Research Software series.

Digital skills are becoming increasingly important for research, unlocking powerful tools that accelerate discovery and innovation - but these advances can come with an environmental cost. Every dataset stored, every AI model trained, and every simulation run consumes energy and contributes to emissions. And as the scale of digital research grows, so too does its environmental footprint.

The UK Government's commitment to Net Zero by 2050 will require a reduction in emissions from all sectors, including research. Digital research should be at the forefront of this transition, helping to unlock new ways of working that reduce environmental impact while maintaining quality, efficiency, and innovation. At the same time, it is increasingly important to ensure that the environmental footprint of digital research is minimised, without compromising the efficiency or quality of the work itself.

The good news is that many sustainable digital research practices are simply good digital research practices. Efficient code runs faster, well-managed data is easier to reuse, and optimised workflows save time and resources. So time spent transitioning to greener practices can also be mutually beneficial for research.

Why Training Matters

The challenge is that research is complex - there’s no one-size-fits-all route to more sustainable science. What’s essential for one field might be irrelevant to another, and that’s okay. The key is to identify what changes can make the biggest difference in your work.

The Greening Digital Research project (led by Weronika Filinger with Jeremy Cohen, Martin Jukes and Kirsty Pringle) is a collaboration between the CHARTED, NetDRIVE, DisCouRSE and SCALE-UP NetworkPlus projects. It has been working with training experts, including the team behind the DIRECT Framework, as well as researchers and digital research technical professionals (people who support research in a wide range of roles), to better understand where training efforts should be focused.

To explore this, we ran a workshop at a recent NetDRIVE meeting aimed at identifying how digital research training needs align with emerging green skills and sustainability goals. It’s early days, so the list is likely to change, but take a read through our initial points and think about what might apply to your work.

Ten Training Priorities for Net Zero Research

Here, we highlight ten areas where workshop participants identified training as important. Different priorities will matter for different research areas and styles - start wherever makes sense for your work.

Active Data Management & Reuse

Be deliberate about what data you keep, how long you keep it, and how you describe it.

Learn how to apply FAIR principles (Findable, Accessible, Interoperable, Reusable), create clear metadata, and avoid the trap of “store everything forever.”

Why it matters: Every unnecessary terabyte stored increases the need for additional storage hardware, which uses additional energy in both its operation and construction. Good metadata and reuse reduce duplication across the community.

Efficient & Responsible AI

AI and machine learning are powerful tools, but are also power-hungry. Training in efficient model design, experiment planning, and impact assessment helps you make sure AI is used wisely, not just because it’s trendy.​

Why it matters: Unnecessary use of AI models or poorly designed AI models can increase energy use and associated emissions.​

Code Profiling & Optimisation

Learn how to write lean, efficient code and use profiling tools (which can help you to see where your programs waste time and energy). Understanding compiler options, algorithms, and libraries can make your software (and your research!) run faster and greener.

Why it matters: Small improvements in code performance can be important when scaled to lots of runs or users.

Robust Software Practices

Test early, test often, and fix bugs before scaling up. Training in debugging, version control, and code review saves resources, time, and frustration.​

Why it matters: Every failed or repeated run is wasted energy. Plus it will save users time!

Sustainable High Performance Computing & Workflows

High-performance computing (HPC) is a key part of modern research, but it’s also a major energy consumer. Learn to optimise job submissions, right-size resources, and (if appropriate) use carbon-aware scheduling.  If you are unsure then speak to the HPC provider - they will have the expertise to help.  ​

Why it matters: A well-optimised job can do the same science with a fraction of the energy.

Smarter Cloud & Container Use

Cloud platforms are convenient, but easy to use incorrectly. Understanding when cloud solutions are appropriate and how they are deployed helps avoid hidden carbon costs

Why it matters: “Set and forget” cloud jobs often run long after they’re needed.​

Embedding Sustainability into Project Management

Make environmental impact part of your planning, not an afterthought. Learn to include carbon costing, risk assessment, and sustainability checkpoints in your project lifecycle.  Good project management can also reduce the risk of failures, which both speeds up research and wastes fewer resources.

Why it matters: What you measure, you can manage - and improve.

Leading for Change

You don’t have to manage a team to show leadership; you can advocate for sustainability wherever you work. For example, running training for your colleagues or peers, sharing best practices, and promoting opportunities can all have a positive impact.

Why it matters: Change happens when people lead by example.

Ethics, Adaptability & Collaboration

Being an ethical researcher means considering not only what you do, but how you do it. Developing skills in ethical reasoning, adaptability, and teamwork helps you make balanced decisions, work effectively with others, and avoid unnecessary waste or duplication. These skills apply across the whole research lifecycle, not just digital aspects.

Why it matters: Sustainable research is about people as much as technology.

Communication & Community

Good communication spreads good practice. Training in clear, evidence-based communication and community leadership helps to engage others and build collective change. It also raises awareness of the importance of sustainable research practices and encourages wider participation.

Why it matters: Sustainability is a shared journey, not a solo effort.

What do you think?

These topics came out as important from the workshop, but what do you think? We would love to hear any comments or suggestions: Greening Digital Research Training - Suggestion Form​

Where to Start

If you’re new to sustainability in research, here are a few great places to begin:

Green Software Foundation:  Free course on reducing the environmental impact of software, and lots of relevant blog articles.

Carbon Literacy Project:  Provides training to help individuals and organisations understand and act on carbon emissions, paid but often available through research institutions.

Digital Humanities Climate Coalition Toolkit: This toolkit is a guide to making your research practices more environmentally responsible. It is geared towards digital practices, but also touches on general areas such as travel and advocacy.

Final Thought

Achieving Net Zero in research won’t happen overnight, but every small change helps. Whether you’re optimising your code, rethinking your data storage, or mentoring others to do the same, you’re contributing to a more sustainable research ecosystem. You don’t need to do everything - just start somewhere.

This blog is part of the Research Software Camp: Careers and Skills in Research Software series.

Research Software Engineers (RSEs) sit at the intersection of cutting-edge research and high-quality software development. Despite their critical role in advancing research, the career path of an RSE is often unclear, varied, or undervalued. Here are 5 steps to help you explore what’s next in your career.

1 – Identify what you love about your job as a Research Software Engineer

“Well, that’s easy, right? I love coding”. Maybe, but trying to think a little deeper about your own self-awareness can be helpful as a starting point to career planning. Consider your strengths, skills, motivations, and values about work:

Start by making a list of all the activities, tasks, and skills involved in your job:

· What brings you joy?

· When do you “lose yourself” in your work? When does time fly?

· What gets crossed off your to do list first?

· What is important to you about the organisation you work for?

Action idea: 

Keep a journal of all the activities you complete for a week; reflecting on this can be very insightful. Yes, you probably love coding, but what about collaborating, training, and working with researchers?

2 – Think broadly about opportunities (and be curious about exploring)

“There is no way for me to progress in my current role”. This is something I hear Technical Professionals say all the time, and it’s easy to understand why if you only consider opportunities in your current team.

Try to look more broadly at what career development means to you. This will be different for everyone - but it is rarely just about salary and grade. Is there a way that you could do more of what you love in your current role? Could you take on a different responsibility at an institutional level, undertake a training course, or get involved with a committee, professional society, or community? What opportunities could there be for someone with your skillset in your current team or in other teams within the institution? Which aspects of your skillset would you like to develop? Could you change department, institution, or even industry? Or is there something completely different that you have always wondered whether you could try?

Action idea: 

Create a mind map (or list) of all the different things you could do. Then circle the ones you would like to find out more about and think about how you could do this. You could also consider referring to community developed competency frameworks or similar to develop your understanding of the field that you work in and the different areas involved – for example, Direct Frameowrk.

3 – Understand the marketplace for your skillset

When we feel at a career crossroads, it is human nature to log on to jobs boards and see what’s out there. Of course, you should absolutely do this. However, I also encourage Technical Professionals to be curious about settings where they could work and think more proactively about where they see themselves in the future.

You will need to consider your own mobility, of course, but think about opportunities within Higher Education, Research Institutes, other public sector and not for profit organisations as well as industry. Think about the organsiation and setting rather than just the job – then find out what opportunities they have and how you might find out more.

Different organisations can sometimes call very similar roles different titles, so it is important to read further than the job title and consider the activities a role involves.

Action Idea: 

Start with your skillset and what’s important to you. Create a list of departments, organisations, or sectors where you could potentially work. Again, highlight the areas where you are motivated to find out more. Even if you are not thinking about moving organisation, this exercise will help you develop your network.

4 – Network

Who in your current network might it be useful for you to connect (or reconnect) with? I often think that the word networking conjures scary images of trying to talk to strangers at a conference. We forget to develop better relationships with the people we already know. Reach out to a former colleague who might be able to help you with career thinking, find a mentor, or offer to mentor someone yourself. Speak to someone you don’t know very well at your next team meeting. If you are attending a conference, be brave and approach someone who works in a role that interests you, ask questions, and share your own insights and ideas. Having a conversation about career and development ideas with someone in a similar field can be very helpful.

You could also think about the communities you could join or develop a role in. Attending community events is a great way to expand your network. The Society of Research Software Engineering is a good place to start, and often holds regional events and networks.

Action idea: 

Start small – reconnect with one person this week that you haven’t spoken to for a while. Investigate local or regional technical professional communities and see if there’s something happening near you soon. Go along and say hello to a few people – this is a great way to build your network and find out what else is happening nearby.

5 - Reflect

If you had a magic wand and could create your perfect job, what activities would this involve?

Compare this list to the one you created in step 1 for your current role. How similar or different are the two lists, and what steps can you take to make the gap between your perfect and your current job smaller?

Career development is not always about moving role or organisation. It is important that we also appreciate what we love about our current position and use that as a starting point. There may be tweaks and changes you can make now which will help you in your future career development.

Action idea: 

What one change could you make to your current role which would have an impact on how fulfilled you are at work? Do you have the agency to make this change, or whom else might you need to help?

Good luck getting started!

This blog is part of the Research Software Camp: Careers and Skills in Research Software series.

Why would I go on a placement?

You can learn new skills from leading experts at world-class facilities in HE, industry, and research centres, and deepen your expertise in:

·       a novel research software engineering technique (like cybersecurity best practice)

·       a particular specialist tool (like a high-performance computer library)

·       a specialist technical skill (like continuous integration)

So, what is a knowledge exchange placement?

A placement is a visit to another work area outside of your organisation for a period of up to a week. ‘Knowledge exchange’ means that you are finding out how others work, learning new techniques, seeing new methods or experiencing new equipment, and bringing that knowledge back to your workplace.

Erik’s story: A new technique!

Erik Lacko, Research Technologist, University of Glasgow: “My placement was 3 days at the University of Birmingham, where I learned a specialist technique and in-depth data analysis from an expert. I also attended a facilities showcase where I networked with other technicians and facility managers. The experience has been highly beneficial for my knowledge and expertise, which I plan to further build upon at my home institution.”

How can I go on a placement?

Various grants and funds are available. The UK Institute for Technical Skills and Strategy has a specific fund available until March 2026 for technical professionals associated with UK Higher Education and Research Institutes: ITSS KE Fund. You should discuss this opportunity with your line manager.

Ruth’s story: How to handle requests for new work

Ruth Adewuyi-Dalton, Support Analyst, Nuffield Department of Population Health, University of Oxford: “Our team is tasked with supporting the Liquid Handling Robotic system within our Research Unit; we are all IT specialists, and were keen to understand how another institution works with their scientists. Our host at the University of Warwick took us meticulously through two liquid handling systems, explaining in great depth how requests for new experiments are received and documented, how the system is set up and tested, and how the different components communicate and fit together."

How do I plan for a successful placement?

Ask yourself: “What do I want to learn? A new technique or equipment? How a different work area functions? What skills gap can I fill? Do I want to build a network?”

Ask your line manager: “What is going on in our own institution? Which other institution do you want me to work with?”

Ask other individuals or networks: “What would you want from a similar placement?”

Cantug’s story: Making connections

Cantug Bar, Senior Scientific Associate, Cancer Research UK Cambridge Institute: “I believe the three days I spent on the placement saved me weeks of research time to understand the complex basics of a new technique. The opportunity of networking in person was invaluable and opened up a potential avenue of collaboration.”

What makes a good placement fund application?

•    Talk about vocational relevance (how the placement will help you to do your job!)

•    Explain the benefit to your home institute (you are unlikely to be popular if you say, “I want to get some experience so I can leave this job and get a better paid option elsewhere”!)

•     Stress the personal development opportunities (find out about best practice methods and sustainable ways of working).

•     Value for money to the fund providers (stick within the guidance costs that the providers have suggested – get in contact with them if that information is not available).

I’m hooked, please tell me more about my next steps!

Find out more about how you can experience a knowledge exchange development opportunity by going to the ITSS KE Fund website.

Part of the DIRECT team at RSECon25, University of Warwick, Coventry

This blog is part of the Research Software Camp: Careers and Skills in Research Software series.

Digital and computational skills have transformed the way we do science and research. From managing datasets to developing complex software and running analyses on high-performance computing platforms, the work is increasingly technical, collaborative, and fast-moving. With this complexity comes a question: how do researchers and digital technical professionals plan their careers and build the right skills for the future?

The DIRECT (Digital Research Competencies) framework tries to provide at least a partial answer to this question.

A Short History

The DIRECT project grew out of discussions within the UK and international Research Software Engineering (RSE) community, starting from the work that happened at the Software Sustainability Institute Collaborations Workshop 2023 Hackday, which was then kept active to date by a number of RSEs from the community.

Participants of the CW23’s HackDay working on “RSE skills and competencies” idea

The idea was to construct a resource on (initially only) technical skills that was curated by the RSE community, along with training materials that can help RSEs gain a particular skill. Their individual skill profiles would then be visualised as "competency/skills wheels" to show their skills across different areas.

Prototype application developed at CW23, courtesy of CW23’s HackDay participants

This type of chart makes it easy to see strengths at a glance (e.g. collaboration, programming) and identify areas for development (e.g. leadership, management).

The resource was meant to support (in particular junior) RSEs in tracking and managing their professional development.

As RSEs carved out their identity and position in modern research, it became clear that they needed a way to describe the diverse mix of technical as well as professional skills their work requires. Additionally, supporting just RSEs was not diverse and inclusive enough; we needed a way to support other digital research professionals. The original project was renamed DIRECT framework - which was designed to meet that need: a shared, evolving framework that could support individuals, roles, teams, and institutions in recognising and developing digital research competencies.

What is the DIRECT Framework?

DIRECT is a community-driven competency framework designed to capture the wide spectrum of skills needed across various digital research roles. It provides a structured vocabulary and skill map covering both:

• Technical competencies: such as programming, software design, data management, reproducibility, infrastructure, machine learning, and data science.
• Professional competencies: including teamwork, communication, project management, leadership, and community engagement.

Each competency is described across a progression of 4 skill levels — from novice to expert — with examples of behaviors that demonstrate proficiency, skills, and adequate training (both still under development). This makes it easy for individuals to see where they stand and what “the next step” might look like in practice.

Watch this short video of the project lead, Dave Horsfall (SSI Fellow from Newcastle University), describing the DIRECT framework and how it identifies skills and defines development pathways for anyone working in research software, serving as an important tool to help with career progression.