Research collaborations

The RSE team collaborates on more than 30 projects a year. Collaborations span various lengths, from a few days or a few weeks to longer term partnerships of multiple years. However, it is clear that we are much more efficient and impactful when we collaborate on long projects where our contribution to the research itself can be the most visible.

To make sure that we can have a general overview on how all of them are going, it is important to have a project management process. The goal is not to micro-manage each of them. RSEs on projects are managing the overall RSE work. The objective is to keep track of project of the progress on the project and be able to tackle potential blockers that may arise during the collaboration to make sure that all parties have an enjoyable experience.

For this reason, we have created a fairly light process of project management, from scoping to impact inquiry shown in the figure below.

Project timeline showing the different stages of a project with RSEs.

In practice a project goes through five main phases:

WHEN to contact us?
We strongly prefer to engage with our colleagues as early as possible in the research project timeline, ideally during the grant writing process. This allows for us to:
  • Participate in the shaping of the proposal and advise you on the best software approach for the project. We might, for very software heavy proposals, suggest to join the project as co-investigator. In that case we will be happy to participate in the writing of the grant.
  • See if we have the right skills in the group,
  • Estimate the cost of the RSE involvment (see below),
  • Adjust the allocation for the team in advance.
We also can collaborate with you post award, but we cannot ensure the availabily of the RSEs at that stage it we have not been made aware of the project early on.

HOW to contact us?
To engage with us and discuss a potential collaboration please complete this form. It helps us to have an idea of the project and decide who from the team is best suited to talk to you. We will then get in touch with you and setup a scoping meeting. In general two RSEs will attend to scoping meeting. If you have any questions you can always email us at rse@sheffield.ac.uk.

How to COST us?
Note: We kindly ask you to let us know when you are costing RSEs on your grant so our admin team can check that everything is done correctly.
Costing a RSE depends on the source of the funding:
  • If the grant is generating overheads, the RSE is costed as G7.10, as directly incurred cost. RSEs are part of the University's costing tool and you can select us while you are building the costing for your grant;
  • If the source of funding is NOT generating overheads, the RSE may be costed using the internal day rate of £384. Please check this with us as this depends on the funder;
  • If the funding comes within the University, no overheads are to be taken into account. In that case we use our internal day rate of £384;
  • We are sometimes collaborating with external companies (e.g. spin-outs), in that case please get in touch to discuss the day rate.
When your grant is funded (congratulations!) and that the starting date of the collaboration with the RSE approaches, we will organise a kickoff meeting. This meeting will be attended by the RSE and their line manager and by people from the research team whose work will be closely linked to the RSE’s (at least the P.I. of the project). During the meeting we will discuss the following item:

  • Objectives and requirements of the project: What are the overall research objectives of the project?
  • Configuration of the collaboration: Primary contact, who is going to work on the project, Meeting cadence, Progress meetings,
  • Objectives of the RSE: Mapping research is difficult, so for this item we will discuss what are the objective of the first month?
  • Risks: What could go wrong about the project?
  • Technical aspects: On-boarding material, issue tracking and communication
  • Outputs: What outputs do you envisage to produce? (papers, software releases, etc.)
During the meeting, everything that is discussed will be recorded in the RSE end-to-end project report. The RSEs working on the project are the owner of the report and will be in charge of keeping it up to date.
For a long project in particular, it is often useful to take some time along the way to take a step back and discuss how the work and the collaboration is going. This is why we will organise progress meetings (also known as retrospective meetings). It will be an occasion to discuss the following points:

  • What is going well?
  • What is not going so well?
  • What can be improved?
  • What are the next steps?
It is worth mentioning that we do progress meetings for long projects (6+ months). For shorter project we are doing a final retrospective meetings at the end of the project only.
Ultimately, the goal of the collaborations is to participate to the research projects with robust scientific/technical input. It is therefore important to make sure that at the end of the project you are handed over the complete work. Another important aspect of this handover is that you understand the work that is handed over to you. For that reason we encourage the P.I. and/or research group members to take an active part in the development of the software.

Outputs are specific to projects and vary greatly by programming language, but have some core themes. The RSE team aspires to produce software that can be further developed with minimal or no input from the original engineer. To facilitate this we prioritise including the following in our repositories:
  • Developer and user documentation: How to build / run the software, how it is organised, what conventions have been used, what developer tools are needed e.g. to run tests.
  • Execution environment and dependencies: What operating systems will the software run on, is what other software / libraries / modules are needed, what versions, how the execution environment is described. E.g. through containerisation.
  • Appropriate automated tests: unit, regression, integration.
A final retrospective meeting will be held at the end of the project. This will help us to know what went well, what did not, and how to improve our way of working in the future.
We know that producing outputs takes times and we certainly want to be involved in the production of research outputs. As a general rule, If the software developed or maintained by the RSE has enabled the content of a publication co-authorship is expected. This is valid even if the collaboration has ended. For that reason, you can expect RSEs to help wrap up outputs (e.g. papers, software releases) even after you stopped working with the RSEs.

Finally, we will check with you from time to time if the work made by the RSEs has been used for publication or if there is opportunities for further collaborations.


Expectations

As described in About the RSE team, the RSE team at the University of Sheffield is a group of research software specialists with multi-disciplinary knowledge, a wide range of research software skills and a deep interest in carrying research with software

Embedding a RSE in your project is equivalent to initiating a collaboration with a researcher specialising in software engineering. RSEs are research partners, not simply software developers. We have a strong track record of securing funding as Principal Investigators (PIs) and Co-Investigators (Co-Is), as well as co-authoring academic publications. Unlike short-term contract staff, we provide continuity: there is no recruitment process required, and no risk of losing expertise at the end of a project due to project/contract expiry and people leaving the University. In addition, it gives more opportunity to collaborate again together in the future.

RSEs are not technical support, they are active research collaborators. You should expect your RSE to pro-actively contribute to the research direction and steer software development using open, efficient, and reproducible methodologies. RSEs will always advocate for the formal release of software and the publication of research findings.
To maintain their high level of expertise and expand their knowledge, RSEs participate in university-wide and external academic activities. Our team culture supports this by prioritizing research impact over rigid time-tracking, providing RSEs with the professional autonomy to balance their development opportunities with project delivery. However, to maintain team cohesion and technical standards, RSEs have the following standing commitments:
  • Weekly (or fortnightly) one-to-one meetings with their direct Line manager (~30min-1h),
  • Fortnightly meeting with the Head of RSE (<30minutes).
  • RSE team meetings: 60-minutes RSE group meeting every other Wednesday.
  • RSE away day: Once a year, full day.
  • [Senior RSEs only:] Monthly senior RSE meeting and weekly (or fortnightly) meeting with their direct report (~30min-1h).
Depending on their interest and availability, RSEs can also engage in other activitites such as scoping new collaborations, organizing workshops, delivering RSE training, and attending key conferences (such as the Society of RSE annual conference). As you would expect any of your collaborators to also have other activities, you can expect the same from RSEs. However, we will make sure it does not take up more than 10% of their time along the year.

Transition period:
Research rarely concludes abruptly at a contract’s end date. Often, essential tasks like finalizing a publication, releasing a software version, or polishing documentation extend slightly beyond the official project timeline. We allow RSEs a reasonable amount of time to finalize these high-impact tasks for previous projects. Equally, when an RSE begins a project with you, they may occasionally need brief windows of time to wrap up their previous collaboration whilst familiarising themselves with your project. We appreciate your flexibility in recognizing this as a standard part of the research lifecycle.
Collaborating with a Research Software Engineer (RSE) is fundamentally similar to working with any academic researcher. To ensure the success of our joint efforts, please keep the following operational principles in mind:

  • On-boarding: RSEs are versatile individuals who frequently transition between diverse fields, such as moving from particle physics to archaeology. While this cross-disciplinary expertise allows for the valuable transfer of techniques, it requires a good understanding of the project from the beginning. To ensure an efficient start, we require that the PI arrives at the kick-off meeting with all necessary on-boarding materials (see below). This can include relevant publications, existing codebases, technical documentation, and domain-specific context.
  • Teamwork and communication: An RSE should be treated as a core member of your research team rather than an external service provider. We expect RSEs to be included in team meetings, relevant mails, and communication channels. Active engagement from the Principal Investigator is critical. Regular meetings regarding the software’s evolution are essential to keep the project on track and scientifically relevant.
  • Outputs: Like all research staffs, RSEs are evaluated based on their scholarly contributions. As a general rule, If the software developed or maintained by the RSE has enabled the content of a publication co-authorship is expected. We obviously do not request authorship on unrelated works; however, if the RSE’s contributions enabled the research, they should be credited as a collaborator.