Career Development

growth that the institution hasn't named yet

Learning Objectives

• Describe what career growth means for someone on a non-standard research software track.
• Conduct a career conversation with a team member whose goals differ from yours.
• Identify one concrete way to advocate for a team member's recognition.

Before

Ren asked Jess what "senior RSE" meant at a national lab. Jess said she'd find out and emailed HR. HR sent her a job classification document that listed "Research Software Engineer I", "Research Software Engineer II", and "Research Scientist." The criteria for advancement were identical to the criteria for bench scientists: publications, grants, and citations. Ren had none of these. He had a simulator that was used by thirty research groups worldwide, a commit history spanning four years, and documented expertise in climate data pipelines that no one else in the lab had, none of which appeared in HR's guidelines.

A few months later, Tahia told Jess she wanted to become a PI and wanted her two years of simulator maintenance to count toward that goal. Jess didn't know how to help her: the university's tenure criteria counted software contributions only if they were accompanied by a software paper, and the software paper was still unwritten.

The Careers That Don't Have a Ladder

Research software engineers exist in institutional space that was designed for someone else. Academic promotion criteria were built for bench scientists, and engineering ladders in industry were built for product companies. Neither fits people who build and maintain research software as a primary contribution.

The lack of a defined ladder is not an excuse to ignore career development; it is a reason to be more deliberate about it. What "growth" actually means for RSEs varies by person and institution, but some dimensions are consistent:

• Technical depth: growing expertise in a specific domain that makes the person more valuable to the research community.
• Technical breadth: learning adjacent skills like DevOps, data engineering, and visualization that expand what the team can do.
• Community presence: publishing software papers, giving conference talks, contributing to standards bodies, and mentoring others all that make someone's expertise visible outside the lab.
• Institutional influence: serving on committees, advising students, and shaping policies build the kind of standing that leads to more autonomy and better conditions.

A useful career conversation covers two things: where the person wants to be in two to three years (concrete enough to plan toward) and what the project can offer toward that goal. The second part requires honesty. If the project can't offer authorship, say so. If it can offer a conference talk or a software paper, offer it explicitly.

After

Jess started having 30-minute career conversations with Ren and Tahia every quarter. For Ren, the immediate goal was a software paper that would give him a citable contribution. Jess committed to prioritizing it in the next quarter. For Tahia, the goal was visibility in the ecology community as someone who did more than maintain existing code. Jess proposed submitting a methods paper together that described the climate data pipeline Tahia had built. Neither conversation required Jess to change the project's direction—only to make its existing work count explicitly toward goals that hadn't previously been stated.

Advocating for a team member's recognition is often more useful than providing career advice. Jess could nominate Ren for a best software contribution award at a conference. She could write a reference letter that specifically described what he'd built. She could invite Tahia to co-present at a workshop. These acts cost Jess relatively little and matter disproportionately to people who are trying to establish themselves in a field that doesn't have standard career signals for what they do.

Exercises

Career Conversation Practice (12 min)

Prompt the LLM like this:

Play the role of a junior RSE who has been maintaining a research software project for two years. You want to advance in your career but you're not sure what that means in your institutional context. Answer my questions about your goals in character. Your specific situation: [describe one detail about their background or ambition].

1. Ask the LLM what does success look like? What's in your way? What would help?

2. Based on the conversation, write three concrete things the project could offer toward this person's goals. Be specific: not "support their development" but "submit a software paper with them as first author in Q2".

3. What did the LLM get right? What did it get wrong? (The most common failure is it not knowing what constraints actually exist at your institution, e.g., what counts for promotion or what authorship norms are in your field.)

Advocacy Audit (8 min)

Individually:

1. List the team members you manage or work closely with.

2. For each person, write one concrete thing you have done in the last six months to make their contributions visible to people outside the project, such as a reference letter, a conference submission, a mention in a talk, or a nomination for an award.

3. For anyone where your list is blank: write one specific thing you could do in the next 30 days.