By Simon Hettrick, Deputy Director.
When I first started thinking about how we could create a career path for Research Software Engineers (RSEs) in academia, I assumed we would have to persuade university management to change their policies and make it possible, or at least much easier, for researchers to retain RSEs within their groups. The actual solution has been somewhat different, and much more effective.
Pioneers at a growing number of universities have seized the initiative and set up their own RSE group. These groups employ a number of RSEs and then hire them out to researchers at their home organisation. It’s a win-win for researchers: they gain access to the skills they need and—unlike hiring new personnel—they only pay when they need those skills. By servicing an entire university, RSE groups tap into enough demand to allow a number of RSEs to be consistently employed.
When RSE groups are first launched they tend to hire generalists, but as they grow they can hire more specialists, which makes skills available that researchers could only dream of accessing without such a group. As they grow, RSE groups need senior staff who can run larger projects and oversee the work of others, and this creates the RSE career path that has been so sorely needed.
In other words, we’re winning the fight for RSE careers not through lobbying, but by providing researchers with a way to pay for software experts. This doesn’t mean that we can relax, we still have to support RSEs who are embedded in research groups, but it’s an important success.
The first group to use this model was set up at UCL in 2012 (although similar groups, like EPCC, have been around since the 90s). It was two years before the next group was founded at the University of Manchester, then four more groups (including the group I run with John Robinson in Southampton) were created in 2015. Growth has accelerated since this time. There are now RSE Groups at 15 universities across the UK, and we are receiving requests for help setting up new groups with increasing regularity.
Setting up an RSE Group is not easy. To help, we asked leaders of some of the established groups to share their experiences. In this post, I thought I’d summarise what I believe are the main lessons.
How to argue for a new RSE Group
The quickest way of getting permission to launch a group is to win the backing of a senior academic, preferably one with some weight (a “Silverback”, to use the vernacular). The whole concept of software as the fundamental tool for research is new to many in university management, which means you are likely to encounter a lot of scepticism. Like it or not (“not” in my case), university management is more likely to listen if you have one of their own on your side.
The argument for creating an RSE Group is typically based on there being a huge amount of software used in research, and hardly anyone trained to conduct the software engineering. Software helps increase the pace and scope of research, and expertly engineered software does this doubly so, whilst also maximising reliability and reproducibility. You might find that people are more excited about increasing the pace of research than the increase in reproducibility. I don’t agree with this sentiment, but it’s a battle that can be re-visited after you’ve established the RSE group.
All of the RSE groups we interviewed—except one—receive institutional support. This is where the university pays for a number of RSEs, which allows the group to provide their time to researchers for free, or it simply reduces the pressure on finances. Most groups report that a significant proportion of costs can be recovered by charging researchers for their services. It’s helpful to survey your university to find who would be interested in hiring RSEs, because showing that people are willing to pay for your services is one way you can prove the value of the group.
Most of the groups we interviewed separate their work into “short” and “long projects” (in reference to their duration). Short projects are sometimes conducted for free, many see them as a loss leader, and long projects are paid for, at least in part, by the researcher. It’s interesting to note that a number of groups conduct a lot of 3-6 month projects. Researchers find these projects difficult to staff, because they’re too short to hire someone. They’re usually financed using funding that’s already available to the researcher: services-rendered accounts and the money left at the end of a grant, etc. There’s a lot of opportunity for cost recovery in these mid-sized projects. Longer projects tend to be funded by the RSE group being written into a bid. One group argued that including an RSE in a bid improves its chances of success. A review panel should look more kindly on a project that produces results using reliable software.
Another common feature is the provision of training. It’s good to conduct software engineering, but it’s even more appealing to the university if you offer to create a community of researchers who can conduct their own engineering (“Teach a man to fish…”). Universities get training, it’s their raison d’etre after all, so this is generally an easy sell. However, a training programme is also incredibly useful to the RSE Group. It’s another way of showing demand: if you can sell out training courses, this shows a market for software engineering expertise. It also identifies the people who are serious users of software—your future clients—and makes them well-disposed to your group.
Every group reported on the importance of a collaborative philosophy. Universities sometimes appear hell-bent on siloing their staff based on their purpose, their research interests, their seniority and any number of other categorisations. RSE groups have to work across faculties and service groups, and there’s a good argument that this collaborative philosophy will rub off on the researchers they work with. Having a global view of the university is an important strength, an RSE group can provide a valuable service just introducing researchers to people who are conducting similar work in their organisation.
The majority of RSE groups are based in IT (or a specialist research computing group). I’m still unsure whether it’s better to base an RSE group in IT or in an academic group, but I think we can be flexible on this front. Universities are surprisingly varied organisations, so I’d like to keep our options open and base RSEs group where they best fit for any particular establishment. I note that groups that are based in IT tend to be larger because they have easier access to staff. However, since recruitment of RSEs does not seem to be a problem, I hope that the academic-based RSE groups will catch up with the IT-based ones over time.
In summary, if you want to set up an RSE group, it’s advisable to find a friendly senior academic, prepare a business case that shows both the need for software and the route to recovering costs, include a training programme and promote a collaborative, community-building philosophy. It helps to conduct some market research, even just send a few emails, so that you can prove demand for software expertise. There’s a good argument that the group is likely to be more successful if you can attract institutional support, and possibly an even better argument that this support may not be necessary in the long run as the group grows and becomes self-supporting. And don’t overlook the importance of invoking jealousy: there are RSE groups at 15 leading universities, what will happen to the standing of your organisation if they miss the boat?
If you’re interested in setting up an RSE group you should join the RSE Leaders Network. It is an informal group of RSE leaders who meet every six months to share experiences and expertise. You’re far more likely to succeed if you talk to people who have been through the process, so that you can repeat their successes and avoid their failures.
I strongly suggest that you get in touch with some of the established leaders and discuss your plans in detail. Everyone in the RSE community is excited about the growth of RSE Groups because this is creating a sustainable home for RSEs—and that’s something that all RSE want to see.
For more information, please take a look at the case studies which are all available on the UK RSE Association’s website.