(by Daniel S. Katz, Kenton McHenry, Jong S. Lee)
(in conjunction with a talk [slides, video] presented 28 September 2021 at SeptembRSE)
Over the past nine years there has been growing acceptance of the role of Research Software Engineers (RSEs) and the value they bring to projects. We’ve also talked about different models of where RSEs can fit in institutions, from lone RSEs working with research groups, to small groups of RSEs embedded in a department or division, to centralized groups of RSEs in an institution. And in some institutions (e.g., NCSA, Manchester, and Notre Dame), these groups have grown to a size where additional structure beyond just a group and a leader is sufficient.
Now it’s time to define how RSEs fit into their institutions, particularly at more senior levels. This post attempts to do that, and it has been influenced by a past blog post by Dan and Kenton, and a book by Camille Fournier.
RSE career paths
We can think of a typical technical RSE career progression as being divided into levels, perhaps for example, Associate RSE, Staff RSE, and Senior RSE. The number of levels here is somewhat arbitrary, though there are often a few concepts that work into the number: On one hand, it’s good to have multiple levels, so that there is the opportunity for promotion and recognition, perhaps every few years, and maybe even more at the start. On the other hand, with too many levels, it can be hard to define the distinctions between them. Additionally, some organizations believe that there is some level people need to achieve in order to be a good contributor to the organization, and if they can’t get to that level, it’s best to let them find another position. For the purpose of this blog, we’ll assume there are three basic technical RSE levels, and that the Staff RSE level is the minimum sustainable level for an RSE.
Some of these roles can include some mentoring and leadership, and at some point in technical progression, this becomes a key capability. For the purpose of this post, we’ll call this the Lead RSE level. This is where someone has to be the PI of a project or to lead an element of a large project. While this can happen at different levels, both lower and higher, we’ll argue that that is required at the Lead RSE level and above, and in fact, under the practice of some organization where a person has to demonstrate the ability to work at a higher level before they are promoted, this might be a requirement for becoming a Lead RSE.
Once a person is at this Lead level, the different aspects of leadership come to the fore, and they may choose to emphasize one of them and use that emphasis to build new skills and move into a new role. There are three options we’ll explore in the rest of this post: product-focused, technology-focused, and people-focused. We’ll called these roles
- Product Manager / RSE (product-focused)
- Principal RSE (technology-focused)
- Group Leader / RSE (people-focused)
Of course, people at this level are likely to have aspects of all these emphases and these sets of skills. And for these to be formal roles, the organization probably has to be of sufficient scale; otherwise, these roles will have to be combined, perhaps in a single group leader of the organization.
While these positions are shown here as the end points of RSE career paths, they may be the point at which someone leaves the RSE community and moves into a different community to further grow these other aspects of their abilities. For example, the Product Manager / RSE might move into larger product management outside of software, for example, becoming the PI of a large supercomputer procurement and operations project such as Delta at NCSA. The Group Leader / RSE might become a higher level organizational manager, such as a division director, such as for the NCSA Software Directorate, or the director of a research center such as NCSA. While a person moving along either of these paths may still have a responsibility for software, it is decreasingly likely that they will spend much of their time doing hands-on software work such as programming. On the other hand, the Principal RSE almost certainly will continue to work directly with software, as well as to mentor others, to lead software projects, etc. So this choice really is a choice, with both personal and professional aspects and consequences.
Supporting RSE career paths
Two interesting aspects of these paths are related to how they and the people in them are supported, both financially and intellectually.
At NCSA, a typical RSE in the career levels up to Lead is expected to be supported by projects about 95% of the time, and by the center for the remaining about 5%. This 5% allows them to work on activities that are not tied to any one project and are more institutional in nature, such as being involved in hiring or other such committees, and to contribute to proposals at a small level, noting that this time fraction is not sufficient for major proposal work, which at NCSA is funded on a per-proposal basis. At the earlier levels they will likely have little role in finding the projects on which they work, but at the Lead level, they are expected to be acquiring projects by writing at least sections of proposals and representing NCSA in discussions with collaborators and funders. This may require additional institution support, though at NCSA, it likely will be based on specific time-limited activities. And those at the group leader / RSE level will be supported at about 20% by the center for these management activities. We don’t currently have anyone at the Principle RSE or Product Manager / RSE levels at this time, but hypothetically, people at these levels might also be supported at around a 20% level as the center invests in both them and, in the case of the Product Manager / RSE, the product they support as a key element of the center’s future success. And at higher levels of either product or people management, the center will likely invest more in the person because of their increased work on behalf of the center, though a successful product manager is likely going to be acquiring funding for their product and themselves in a way that a people (line) manager cannot.
Intellectual support is harder to define, in part because it is less formal. We (NCSA) have a good deal of informal mentoring, but less formal training and no formal mentoring currently, though we do want to formalize these mechanisms in the future. Informal mentoring is mostly embedded within projects, where and when the senior person or lead of the project identifies opportunities/activities for staff to experience new skills. For example, the lead might delegate managing a part of the project to the junior staff member, such as task management, sprint planning, release planning, etc., and then coach that staff member in how to make this part successful. We offer, are developing, or have used external programs for training in leadership, proposal development, task management, and technical training (e.g., we have a weekly software working group meeting that both introduces new technologies and has focus groups that investigate and promote best practices in particular technologies). We also participate in the NSF-supported CyberAmbassadors program, which offers training in communication, teamwork, and leadership skills, including in how to effectively communicate and collaborate with external researchers (e.g., faculty).
As we previously mentioned, an organization must have sufficient scale to support these career paths, and these financial and intellectual elements are part of the reason. In a research organization that is primarily project-based, flexible funding that can be used to support these career paths typically comes from institutional support, which for a public institution like the University of Illinois includes both state funds and the overhead on awards. While these funds can be used to support these career paths, they also are needed to support other management, administrative, and institutional functions. Similarly, to create institutional educational programs and mentoring requires enough participants to make the programs worthwhile.
Examples
A number of these career progressions have been observed at NCSA. A typical example is “Ron,” who came straight out of college with a CS background. Ron started out as an associate level RSE. After working with a number of scientists, projects, and codebases over a couple of years, along with a staff level or senior level RSE who was assigned a small amount of time to oversee each supported project, Ron began to demonstrate more independence and the ability to drive a project on his own. He also participated in the more creative/design aspects of the scientific collaboration, while continuing to meet the project milestones and maintaining the collaboration so that the senior RSE assigned really wasn’t necessary on the project anymore and was able to work on other projects. At this point Ron was promoted to a staff level RSE as at this level he allowed the team as a whole to scale out its ability to support scientific efforts by being able to drive collaborations himself and to start to train others as well. Similar paths have occurred with staff coming from a non-CS field, in which case a solid software development proficiency needed to be demonstrated before they moved to the next level. Similarly, RSEs coming in with just industry experience needed to demonstrate an understanding of academia, its time scale and priorities, and being able to work successfully in this environment before being promoted.
Another example is “Sue.” Sue had a Ph.D., and also started out in what was effectively an associate level RSE position. She quickly demonstrated not only an aptitude for software development but also for building out programs and bringing in new projects. Because of this ability to drive projects, Sue was promoted to the staff RSE level where she continued not only to start new projects but also began to build up new reusable codebases and started to become a Co-PI on new projects. Sue was recognized for this added capability to help sustain the RSE group overall and was soon promoted to Senior RSE. She then started to help other staff RSEs grow in activities such as developing proposals, engaging collaborators, and managing projects. Continuing to work on larger efforts that often included previously developed software and becoming PI on some projects as well, Sue became part of the organization’s leadership, where today she not only continues to build out programs but oversees staff.
Conclusion
Given the growing acceptance of RSEs over the past nine years, and the fact that there are now perhaps hundreds of thousands worldwide, it’s time to think about what happens to RSEs later in their careers. We’ve proposed a branching path that starts with technical skills, adds leadership, and then moves in different directions, both technical (project-focused) and management (product-focused, people-focused), which in turn can lead to more senior roles with little hands-on RSE work for those who want to progress in this way, for example, leading large infrastructure projects or divisions or departments. As the idea of RSEs matures, this is our next needed step: to define these more senior roles for individual RSEs to aspire and aim to, as a step of attracting new RSEs to our organizations by giving them a set of possible futures.
This post has also been published as https://doi.org/10.59350/fd3hj-g1891 on the Rouge Scholar
Daniel S. Katz's blog 