In the weeks running up to the RSE Conference, myself and some colleagues will be providing our thoughts on the questions people have submitted for our panel discussion with senior university management about how RSEs are being supported within academia. (You can submit more questions and vote on the current questions on Sli.do.)

Question: If you have a central university RSE group do other staff working in RSE-like roles in academic departments have the same career opportunities as that group?

As research software groups grow, seemingly inevitably they start to acquire more structure and hierarchy, with more senior roles being created to help manage the group. This provides for career advancement opportunities within the group, although often this is with the caveat that an increase in grade requires more managerial responsibility and reduced time for technical work. The situation is more bleak for those employed directly in research groups, typically on a fixed-term postdoc style contract where typical academic advancement routes – dependent on a publication record – do not easily apply. How can universities ensure the same opportunities are available to all staff?

Several groups have tried to address this challenge by making their job descriptions and selection criteria available to the whole university, for instance at Sheffield and King’s Digital Lab. This promotes consistency of approach, and gives the potential to aim at senior roles with appropriate selection criteria. Sustaining posts beyond a single funding source still presents a bottleneck to supporting careers, however. Central RSE groups with a large project portfolio and successful track record can often offer permanent contracts to staff, whereas this is rarely an option for individual research groups. At UCL we are investigating the potential of establishing ‘satellite’ groups within academic departments. These would be able to offer equivalent terms and conditions to their staff, and collaborate closely with the central team. We are not there yet however!

It is also worth considering a broader perspective. For staff trapped in a succession of fixed term contracts, ‘career opportunities’ is often synonymous with getting a permanent post, ideally at senior postdoc or even up to professorial pay grade. There are however many directions of travel that could be considered. How do we allow university staff, wherever they may be based, to move flexibly between teaching, research and professional services roles (or a combination thereof!), into industry and back into academia, always learning new skills along the way? How can progression be linked to expertise in different technical areas, not just management responsibility?

This question is ultimately not limited to RSE roles, but affects the wider network of roles within academia. UCL’s career pathways initiative (aimed at professional services) and academic career framework provide hopeful first steps in supporting more flexible careers, but there is still plenty of work to be done!

Hear an expert perspective on this and a variety of other questions from a panel of senior institutional representatives covering roles in research, HR and research software at the Science and Engineering South panel on “Institutional Support for RSEs” at RSEConUK19 on the 18th September at 13:30. You can also read previous blog posts in this series by Simon Hettrick and Jeremy Cohen.

My colleague Jeremy Yates made the following comment to an earlier post. I thought it was interesting enough that it deserved a post and reply of its own:

An update from the coalface of the National E-I Project Directors Group. There is a major report being written for us and RCUK that looks at the practical issues of support and training including funding it. We hope this advice is made part of the RCUK E-I Strategy.

While we can at least make sure all the procedures and policies are right; the real task is to convince PIs (like me) of the utility of non-subject domain staff, not under my direct supervision, carrying out software tasks for my research.  The last week has provided me with several examples of a lack of trust/desire to retain control.  It’s taken a long time to wean people off having their own hardware; software is another matter in that it really does represent for many their IP and product – it’s personal.

At the heart of this though is the question “Just what is research software support?”

Some definitions I have heard sound a lot like “research” and seem to be combined with efforts to charge fEC on posts.   As I go deeper into this I’m learning the words that cause friction – Developer is benign in IT, but in research it is synonymous with Researcher; Engineering is, well, a research area.  We find ourselves forced back into terms that have become pejorative, such as “consultant”, or lower-grade such as “technician”. Perhaps we have to use older words such as Specialist or Expert.  Certainly the phrase “scientific programmer” is starting to reappear.

As ever this is going to be rather a long haul.   The need for a new and common lexicon between IT and researchers is the least of it.

— Dr Jeremy Yates, Director, STFC DiRAC HPC Facility,

We’ve been thinking a great deal about these questions in the UCL team: in our view we are professionals who are part of the research community, but are not pursuing our own research directions, instead acting as expert collaborators. This role, integrated within the modern multidisciplinary research effort, with the ability and experience to understand and contribute to research at the forefront of human knowledge, but as collaborators, not research leaders, is becoming more important as the set of skills needed to carry out effective research expands. This professional expert collaborator role, will, I think, apply in the 21st century not just to programming, but to other research contributions, including statistics, visualisation, and technical writing.

When we work with a research team, we take a collaborative, hands-on approach, trying to work with the processes, tools and ways of working that are comfortable for that team, while suggesting ideas from agile software development practices that may be helpful. By embedding ourselves within the culture of the group we are working with, we try to ensure that academic colleagues feel a strong sense of ownership for the code we produce together, while allowing our skills to diffuse into research groups. We do not follow a contractual, delivery-oriented approach. The feedback from the groups we have worked about this approach has been very positive.

We use the terminology Research Software Developer and Research Technologist, to indicate that we are specialist software developers, with the expertise, background, and intellect to engage deeply with advanced research. As I was quoted saying in a recent issue of the Times Higher Educational Supplement:

“It’s not our job to understand the science as much as the principal researchers, but you can’t do good software engineering without an understanding of what the programs are supposed to do. That is what we bring compared with the general software engineering marketplace.”

I’ve been asked to present a guest blog post for the Software Sustainability Institute about being a scientific software developer. After reading the post over at the SSI, if you love learning about cutting edge research, and find delight in crafting robust, readable and efficient code, then please apply to join our team. With the establishment of the Research Software Development Team, I hope we’re on the way towards establishing a successful home for scientific programmers in UCL.