A Research Software Engineer (RSE) is someone who applies professional software engineering skills and practice to a research problem, working as part of a research team rather than a general IT service function. The operational distinction that matters for research-computing administration is this: an RSE’s core deliverable is software that is itself a research output or a critical piece of research infrastructure — not a helpdesk ticket, a procured system, or a one-off analysis script written by a domain researcher with no formal software-engineering training. Administrators who treat “RSE” as a loose synonym for “IT support,” “data scientist,” or “postdoc who codes” will mis-scope, mis-budget, and mis-classify the role, which is the practical problem this page exists to prevent.
What Is a Research Software Engineer? An Operational Definition
The term was coined in March 2012 at a Collaborations Workshop run by the UK’s Software Sustainability Institute (SSI) at Queen’s College, Oxford, where a small group of academic software developers discussed the absence of a recognized career track for people doing serious software engineering inside research groups. The SSI’s own definition, still the most widely cited, holds that an RSE “combines professional software engineering expertise with an intimate understanding of research” — two things that, individually, are common in academia (research domain expertise without engineering rigor, or engineering skill without research context) but that are rarely combined in a single role with its own job family, promotion path, and budget line.
Three characteristics distinguish the RSE role in practice:
- Software engineering discipline applied to research code. Version control, automated testing, code review, dependency management, and reproducible build/deployment practices — applied to codebases that exist to answer a research question, not to ship a commercial product.
- Embeddedness in the research process. An RSE typically works close enough to the science to understand what the code needs to do and why, which is what separates the role from a general-purpose enterprise software developer or a vendor contractor.
- A distinct career identity. RSEs are neither faculty researchers (whose primary output is publications and grants) nor conventional IT staff (whose primary output is operational uptime); the movement’s founding motivation was precisely that neither career track fit.
How the RSE Role Differs from Adjacent Roles
Research-computing organizations frequently conflate the RSE role with several neighboring functions. The distinctions matter for hiring, job classification, and grant budgeting:
- RSE vs. research IT / HPC systems administration. HPC and research-IT staff keep shared infrastructure (clusters, storage, networking) running for many users; an RSE writes and maintains the software that runs on that infrastructure for a specific research problem. The two functions collaborate constantly but are not the same job.
- RSE vs. data scientist. A data scientist’s primary output is typically analysis, models, and findings; an RSE’s primary output is software — durable, tested, documented code and tooling that other people and future projects can reuse. In practice the skill sets overlap and some institutions blend the titles, but the distinction is useful when writing a job description or a grant budget line.
- RSE vs. a researcher who codes. Most researchers write some code as part of their work; that alone doesn’t make them RSEs. The RSE identity implies software-engineering training and practice applied as a primary professional skill, not an incidental one.
- RSE vs. data steward / data curator. A data steward is responsible for the ongoing quality, documentation, and accessibility of a dataset across its lifecycle; an RSE is responsible for the software that produces, processes, or analyzes that data. See CASRAI’s guide on data stewardship and the data curator role for the adjacent, and often collaborating, function.
Where RSEs Sit Institutionally
There is no single organizational model; institutions place RSEs using roughly three patterns, often in combination:
- Central RSE group or core facility. A dedicated unit (sometimes under research computing, sometimes under the library or a research office) employs RSEs as shared staff who work on projects across multiple labs, typically on a cost-recovery, grant-funded, or partially centrally-subsidized basis. This is the model the UK’s RSE movement has pushed hardest, and it is increasingly common at large US research universities and national labs.
- Embedded in a lab or center. An RSE is hired directly onto a single PI’s grant or a large multi-institution project (a genomics consortium, a climate model, a particle-physics collaboration) as long-term technical staff, similar in structure to a lab manager but with software as the deliverable.
- Distributed network with light central coordination. Some institutions maintain a directory or community of practice connecting RSEs who are formally employed in different departments, without a single reporting line, to share training, tooling, and job-classification standards.
For research-computing administrators, the practical question this raises is not “which model is correct” but “does our institution have any defined job family, pay band, and promotion criteria for this work” — because without one, RSE-shaped work defaults to being absorbed into postdoc contracts (with no software-focused promotion path), general IT job codes (with no research-context requirement), or informal, unbudgeted favors between labs, all of which produce high turnover and unmaintained research software.
Career Track and Professional Recognition
The RSE community has built formal professional infrastructure specifically because the role didn’t fit existing career ladders:
- The UK’s RSE community held its first national workshop in 2013 (56 self-identified attendees) and voted to found the UK Research Software Engineers Association, which converted in 2019 into the Society of Research Software Engineering — an independent organization able to hold funds and employ staff, running an annual RSE conference and advocating for formal job families and promotion criteria at UK institutions.
- In the United States, US-RSE (the US Research Software Engineer Association), founded in 2018, is a grassroots community organization performing a similar function: connecting RSEs across universities and national labs, and pushing institutions toward recognized job titles and career progression rather than one-off postdoc or soft-money staff lines.
- Related national infrastructure includes the US Research Software Sustainability Institute (URSSI), which works on sustainability practices and policy for research software specifically, complementing the community-organizing work of US-RSE.
For an administrator, the existence of these bodies is a practical resource, not just a professional-identity footnote: they publish job-description templates, salary-survey data, and career-ladder frameworks that an institution designing its first RSE job family can draw on rather than inventing one from scratch.
Why Research-Computing Administration Needs a Defined RSE Track
Three administrative problems recur when an institution has RSE-shaped work but no RSE-shaped job structure:
- Retention and turnover. Skilled software engineers hired into postdoc-equivalent contracts with no software-specific promotion path, and salaries benchmarked against academic rather than technical labor markets, tend to leave for industry once market conditions allow — taking undocumented, unmaintained research software knowledge with them.
- Attribution and academic credit. Software is a recognized research contribution under NISO’s CRediT taxonomy (the Software role, covering programming, algorithm design, code implementation, and testing), but that credit is frequently omitted or under-recognized in practice when the person who wrote the code isn’t a paper author in the traditional sense. See CASRAI’s guide on CRediT for non-traditional contributors for how this attribution gap is typically addressed.
- Grant budgeting. Major US funders explicitly permit budgeting RSE effort as a distinct personnel category on proposals (technical/professional staff time, not just postdoc or grad-student lines), but only if the institution’s own HR and grants-office job codes recognize the role as something other than generic IT support or a temporary research assistantship — otherwise the budget line has nowhere accurate to go.
Structuring and Budgeting an RSE Position: A Practical Checklist
For a research-computing office or grants administrator setting up an RSE position for the first time:
- Write the job description around software-engineering deliverables and research collaboration, not generic “IT support” or “programmer” language — this affects both the applicant pool and the eventual pay band.
- Decide up front which institutional model applies (central group, embedded in a specific grant, or distributed) since it determines whether the position is centrally funded, grant-funded, or cost-recovery, and who supervises day-to-day work.
- Confirm the HR job family has a technical-track promotion path (senior RSE, RSE lead) rather than defaulting the position into a postdoc or temporary-staff classification with no software-specific advancement criteria.
- When the position is grant-funded, budget it as a distinct personnel line consistent with the sponsor’s own categories, and confirm the funder’s policy on multi-year or multi-grant continuity, since research software maintenance rarely maps cleanly onto a single grant’s period of performance.
- Build in explicit CRediT/authorship credit expectations for software contributions from the start, rather than resolving attribution disputes after a paper is already in submission.
Frequently Asked Questions
Is a Research Software Engineer the same as a software developer?
Not quite. An RSE applies the same core software-engineering skills a professional developer would, but does so embedded in a research context, with an understanding of the science the software supports and typically with research outputs (software as a research product, sometimes a software paper) as part of the role’s purpose — not just delivering a working system to a business specification.
Does an RSE need a PhD?
No formal credential is required by the role’s definition. Some RSEs hold PhDs and moved from a research career into software-focused work; others come directly from professional software engineering backgrounds without an advanced research degree. Institutions vary in what they require, and one of the RSE movement’s explicit goals has been to stop treating the PhD as a de facto gatekeeper for a role that is fundamentally about engineering skill.
How is RSE work different from research computing / HPC support?
HPC and research-IT staff operate and maintain shared infrastructure for many research groups; an RSE builds and maintains the specific software a research project runs on that infrastructure. The two roles work closely together but sit in different job families with different deliverables.
Where do RSE positions get funded from?
Funding sources vary by institutional model: central RSE groups are often funded through a mix of institutional subsidy and project cost-recovery; embedded RSEs are typically funded directly on a specific grant; distributed-network RSEs may sit on departmental or individual PI budgets. Major US funders permit budgeting RSE effort as personnel time on a proposal, provided the institution’s job classification supports it.
How does CRediT recognize software contributions?
NISO’s CRediT taxonomy includes a dedicated Software role covering programming, algorithm and code implementation, and testing of code components, which can be assigned to an RSE the same way any other contributor role is assigned — giving software work a formal place in author-contribution statements rather than leaving it as an unrecognized acknowledgment.
