Photo by form on PxHere (CC-0).

Authors

A blog post from the 2nd International RSE Leaders Workshop 2020.

The Challenge: New Roles in Old Institutions

Research Software Engineers (RSEs) are popping up everywhere across the research landscape. They may manage research data, administer High-Performance Computing (HPC) clusters, or develop scientific software, to name a few of their activities. RSEs have the background and skills to deal with the unique challenges that arise from the technical side of science. As demand for their services booms, a single RSE may quickly find themself managing a whole RSE group. However, their roles are rather novel, so it can be difficult to structure such a group or find a place in relatively rigid academic structures. How should a fledgling group leader organize their group? What are the pitfalls of different structures/models?

Our Approach: Learn What Works (And What Doesn’t)

A lot can be learned from existing groups and what has led them to adopt a particular group structure. We plan to examine how existing groups work, collate existing information, and offer a kind of ‘recipe book’ for founding new ones. However, it is clear that this is not a “one-size-fits all” problem, and that groups differ along a number of crucial dimensions. At the 2nd International RSE Leaders Workshop, held remotely on September 2020, we developed the following strategy:

  • Identify existing knowledge, and knowledge gaps about RSE groups
  • Define the dimensions along which groups differ to provide guidance on the organisation of new groups
  • Develop a method to address knowledge gaps by surveying existing RSE groups
  • Organise the compiled information into a “recipe book” with guidance for existing and newly created RSE groups

How RSE Groups Work

There is a wide variety of team structures and processes within RSE groups, which of course depend on the group’s size, amongst other things. For example, teams can be structured based on projects, based on cross-role teams (e.g., scrum teams), or based on skills (e.g., web interfaces, HPC).

How specific projects are assigned to teams often follows this structure and what’s possible is often constrained by the details of how funding and collaboration works within each organisation. Similarly, the more institutional support/core funding a group has, the easier it is for a group to operate as a unified team assigning members to projects and activities flexibly according to skills and experience. This in turn makes it easier to have technical specialisms, agile team approaches or multiple levels of seniority than if the group has to be more rigid about which people are hired to work on which grants, for instance. Another aspect of this mapping is the use of agile principles, which can be very appealing to RSE groups, but hard to apply in practice in many cases, as many specific methodologies developed within commercial teams (such as scrum) don't fit a typical RSE group context for various reasons. For example, it's rare to have multiple developers able to focus 100% on one project, and in fact, some groups don't allow developers to do this to avoid potential "project capture" and single points-of-failure.

In addition, an overall RSE group includes people with different roles (e.g. team line managers, technical project managers, lead developers, architects, programmers, scrum masters, QA testers) and these roles need to be considered in both developing a group structure and making effective assignments of projects to groups. Another aspect is how these roles fit into the organisation's formal titles and human resources structure, and specifically, for each of those more formal roles, what are the titles, salaries, requirements, etc. One of a group’s activities should be to mentor the staff to advance in these roles, and to get the training, education, and on-the-job experience needed for them to do so.

A group also needs to attract (or choose) projects to work on, hopefully based on some strategy and not just doing whatever work is available to keep the group members employed. This is tied to the financial model of the group, which could include full or partial institution (core) support for some or all of the team members, support based on the group or its members writing proposals to a funding body, either for group-developed projects or those done jointly with users, and support based on “customers” approaching the group with work to be done.

A last aspect to groups is where they fit into their organizational structure, such as reporting to the research part of the organization and being responsible for all disciplines, reporting to the IT part of the organization and being responsible for all disciplines, or reporting to a smaller unit (a department, a school, a faculty) and being focused on work within that unit’s discipline.

One example is the Netherlands eScience Center, which currently uses a mixed model where some RSEs are working as part of a team while others are working in one or several more loosely formed project-related teams. The formal teams follow the agile methodology of their choice, whether it’s Scrum or Kanban. The teams work on a set of related projects, either from the same domain or using similar technology. The teams often focus on a specific project in each sprint or iteration, while the other projects are on hold. Within teams, each project that is worked on by the team has a product/project owner, who directly communicates with the stakeholders of the project and defines the stories/issues for the team to work on. The RSEs who are not in a formal team work on a more individual basis usually on multiple projects simultaneously, having more control themselves on how they divide their time over projects and other activities. Projects typically span multiple years, so the engineer-project assignments do not change that often.

Dimensions of RSE Groups

The description above illustrates that there are many different operational models for RSE groups and that groups differ across a number of dimensions. If we are to better inform new groups, a system of categorisation would help organise the content of our recipe book so that it is relevant. The categories could provide a way to arrange information that new groups could easily find documents that relate to their situation, or to find other groups in a similar environment to compare their solutions for common problems. For example, information about possible management approaches may depend on the size of the group: management approaches for a group of 50 RSEs may not be appropriate for a new group of 5 RSEs. As a first proposal, we list some key categories of RSE groups:

  • Business/financial model - Through full or partial core institutional funding? A “customer” approach? Active participation in grant proposals?
  • Management structure - What roles do the RSEs take on within the group? How is the group organized on a day-to-day basis? How do members' careers progress? Who has leadership and makes the strategy?
  • Demographics of the individual RSEs - What is their professional background? Do they come from academia? Do they have a PhD?
  • Working culture - Do they promote open-source? Do they seek to exploit commercial opportunities? How flexible are the working hours and work environment?
  • Institutional context - How does the group fit within its housing institution? What is their origin/history? Who are they accountable to? How large are they?
  • Technical focus - What kind of services do they provide? (HPC, Web-Platforms, Databases, etc.)
  • Subject focus - What fields of science are they active in? How specialized are they?

Knowledge Base

We already have a reasonable amount of knowledge about the methods and dimensions of existing groups from previous activities, including surveys, publications, and materials banks.

The surveys include:

In addition, we know of two relevant papers and one dataset. "Research Software Development & Management in Universities: Case Studies from Manchester's RSDS Group, Illinois' NCSA, and Notre Dame's CRC" (preprint) by Katz et al. reviews three exemplar RSE groups (two in the US and one in the UK.) It covers group/governance structure, financing, career path within groups, as well as advantages of having RSE groups. "The Industrial Ecology Digital Lab" by Stadler et al. describes the setup of the Industrial Ecology Digital Laboratory, focusing on the tasks and infrastructure.

Finally, there are several resources containing information on how different RSE groups work. The material banks below are a good starting point for finding further information:

Repositories of RSE Groups

There are a set of existing lists that include groups identifying themselves as RSE groups, Existing groups can add themselves to the appropriate list.

However, large parts of the academic infrastructure is managed by organizational structures which are basically RSE groups but currently do not self identify as such (HPC groups, IT support groups, and so on). If you do establish an RSE group, please make sure to be added to one of these repositories.

Surveying Existing RSE Groups

While RSEs are a relatively new concept, there is already a considerable knowledge base available. To gather more data, we could collect unstructured data through interviews, with topics based on the existing knowledge base. To collect structured data, we could create a short on-line survey. In either case, to begin this work, we would need to:

  • Formulate questions for leaders of existing groups
  • Decide whether to use interviews or a survey, and if there we will use a survey, will it be new or included in an existing survey
  • Obtain human subjects (IRB, ethics) permission for our study

We could also aim at collaboratively writing a report or paper with multiple RSE group leaders, either after a survey/interviews or independently.

Next Steps

A lot can be learned from existing RSE groups. However, this knowledge is dispersed across groups, diverse and context specific and often not well documented. Sharing and collecting this knowledge will require a large community effort. Members of existing groups will need to share their knowledge by contributing to surveys. And volunteers in the community, such as the authors of this blog post, will need to work together to collate and synthesise this information. The proposed ‘recipe book’ will help collect and organise this knowledge to assist in the foundation of new RSE groups.