Building a Developer Team

Developing molecular software requires expert skill in both science and software engineering, and recruiting these double-experts is a fundamental challenge in our field, particularly because they can often command high wages in industry. Developers with these skills are usually graduates of PhD programs in computational chemistry or physics. The archetypal molecular sciences software developer is a recent PhD who found themselves more interested in writing production-quality code than in publishing in Nature. In our experience, it is much less common to find graduates of Computer Science programs who have learned molecular sciences outside the classroom.

In scientific software development, as in other knowledge work, virtually all management boils down to Human Resource Management. The success of your project depends entirely on the performance of your team. The skills required to do this work come mostly from PhD-level training, so they necessarily come along with independence, creativity, and persistence. Scientific developers need to be given aagency and respect to do their best work, and these depend on factors that have traditionally been relegated to HR. The conventional HR functions of defining and filling positions, setting fair compensation and benefits, promoting “work-life balance,” and resolving disputes (especially with managers) are essential to the performance of the team. Get these things right, and your team can’t help but succeed. In short, if you take care of your people, then your people will take care of the work.

Roles and responsibilities

OMSF projects are typically built by small teams of experts. Each person on the team may have to “wear multiple hats,” performing a mix of scientific and engineering tasks. We use two distinct job titles and descriptions (“Software Scientist” and “Research Software Engineer” to help define responsibilities and identify candidates, but in reality, each individual role can be thought of on a sliding scale between Science and Engineering. The exact position of that slider may be set by the particular skills and interests of the person in the role, but it may also shift over time, or even day-to-day, based on the work that needs to be done in the project.

The basic job descriptions for these two roles can be summarized:

• Research Software Engineer: Skilled software engineers who understand the needs of the scientific community, RSEs create new code to solve scientific problems. A burgeoning community of RSEs in Europe are defining the position as a distinct career path, and the US is beginning to catch up.
• Software Scientist: The Software Scientist expands the capabilities of existing software, through either experimentation or method development.

OMSF’s compensation policy defines a single category of developer (“RSE”) at three levels of seniority. Typical qualifications and responsibilities are as follows:

• RSE: PhD, Master’s +3, or Bachelor’s +5. Works under supervision, interacting primarily with immediate team members and supervisor.
• Senior RSE: PhD +3 or Master’s +6. Works independently, mentors team members, and interacts with the broader community.
• Technical Lead: PhD +5 or Master’s +8: Takes responsibility across multiple dimensions of the project, supervises team members, interacts directly with project governance, represents the project in public.

Following the division of RSEs into Software Engineers and Software Scientists, some OMSF projects have two Technical Leads:

• Science Lead: Supervises Software Scientists. Responsible for designing and conducting any relevant experiments, ensuring scientific accuracy and applicability of code, publishing any scientific papers that come out of the project
• Infrastructure Lead: Supervises Research Software Engineers. Responsible for designing software architecture, ensuring performance and stability of the code base, and leading testing and documentation efforts.

Hiring strategy

When defining the roles that will make up your project team, it is important to write realistic job descriptions that match real candidates. Accurate, realistic, detailed job description will allow candidates to self-select roles that will best match their own skills and interests. Job descriptions that are too ambitious may select for candidates with over-inflated views of their own abilities. There are no superhero software developers, or if there are, a non-profit budget can’t afford them. Selecting a candidate who is both an accomplished scientist and a skilled software engineer likely means choosing someone with poor teamwork or other important weaknesses.

The most important consideration when hiring is not the individual skills being added to the team, but the overall impact on team health. A team member’s ability to come to agreement on what problems need to be solved is far more important than their ability to solve the hardest problems. Just as importantly, a highly productive individual contributor who destroys the harmony of the team with a rude or belittling attitude is a net negative to the team’s productivity.