CASRAI Dictionary

Tag: research careers

  • Researcher development frameworks: Vitae and recognising career-stage progression

    It is easy to count a researcher’s outputs and much harder to describe how they have grown. A doctoral student becomes an independent investigator; a postdoctoral researcher learns to lead, to supervise, to win funding, to manage a project; a mid-career academic develops the judgement and the breadth that the earlier stages could not yet supply. This progression is real and consequential, yet the conventional currency of recognition — publications and citations — captures almost none of it. Recognising career-stage progression requires a different instrument: a structured way to describe the capabilities a researcher develops and the stages they move through. Researcher development frameworks provide exactly this, and they are the subject of this article, which draws on the mentorship and career-stages domain of the CASRAI Dictionary.

    The problem with output-counting

    The dominance of output metrics has a hidden cost for careers. If recognition flows mainly to those with long publication lists and high citation counts, then the many capabilities that make a good researcher — the ability to design rigorous studies, to communicate, to collaborate, to manage, to supervise, to develop others — go largely unrewarded, and the people at earlier career stages, who have had less time to accumulate outputs, are systematically disadvantaged. Worse, output-counting tells you nothing about development: two researchers with identical publication lists may differ enormously in their independence, leadership and range. A system that cannot see growth cannot fairly support, develop or promote the people within it. Frameworks that describe capability and progression exist to correct this blindness.

    The Vitae Researcher Development Framework

    The best-known instrument of this kind is the Vitae Researcher Development Framework (RDF). The RDF sets out the knowledge, behaviours and attributes of effective researchers, organised into domains that span far more than research technique alone — covering knowledge and intellectual abilities, personal effectiveness, research governance and organisation, and engagement, influence and impact. Its value lies in making the full breadth of researcher capability explicit and nameable. Instead of leaving “development” as a vague aspiration, the RDF gives institutions, supervisors and researchers themselves a shared map: a way to identify which capabilities a researcher has, which they are developing, and where their growth might next be directed. It can structure training provision, inform appraisal and self-assessment, and give early-career researchers a language for articulating what they have learned beyond the papers they have published. The framework turns development from something assumed into something that can be described and supported.

    The Concordat and the institutional duty

    Frameworks describe capability; policy creates the obligation to develop it. In the United Kingdom, the Concordat to Support the Career Development of Researchers sets out the responsibilities of institutions, funders and researchers towards researcher development. It commits signatory organisations to providing environments and opportunities that support researchers’ growth — including dedicated time for professional development, support for career progression, and recognition of researchers as professionals with careers, not merely as a source of labour for projects. The Concordat matters because it places development on an institutional footing: it is not left to the goodwill of individual supervisors but becomes a commitment that organisations make and report against. Together, a capability framework like the RDF and a policy commitment like the Concordat form a system in which development is both describable and expected.

    Recognising supervision and mentoring

    A particular and often neglected dimension of career-stage progression is the work of developing others. Supervising doctoral students and mentoring early-career colleagues is demanding, skilled and central to the health of the research enterprise — yet it has traditionally been among the least recognised activities in academic careers. Efforts to address this include the work of bodies such as the UK Council for Graduate Education (UKCGE), whose recognition arrangements for research supervisors affirm supervision as a professional practice with its own standards and development path. Recognising supervision properly does two things at once: it values the labour of those who do it, and it acknowledges that the ability to supervise well is itself a marker of career-stage progression — a capability the researcher has developed. Frameworks that name supervision and mentoring as recognised contributions help bring this work out of the shadows.

    The narrative CV as the vehicle

    If development and capability are what we want to recognise, the traditional CV — a reverse-chronological list of outputs and posts — is a poor vehicle for showing them. The narrative CV has emerged as a better fit. Instead of merely listing publications, a narrative CV asks the researcher to describe their contributions and their development in prose: what they have contributed to knowledge, to the research community, to the development of others, to broader society. This format is well suited to career-stage recognition because it lets a researcher tell the story of their growth — the capabilities they have built, the people they have developed, the responsibilities they have taken on — rather than reducing their career to a count. The narrative CV and the development framework are natural partners: the framework supplies the vocabulary of capability, and the narrative CV supplies the form in which a researcher can demonstrate it.

    A consistent vocabulary for development and contribution

    For development and progression to be recognised consistently — across institutions, funders and the systems that record careers — the way contributions and capabilities are described must mean the same thing everywhere. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so that a contribution described in one place is understood the same way in another. The structured description of who did what, captured by the CRediT taxonomy, complements the developmental picture by recording specific contributions to specific works, which a narrative CV can then draw on and interpret. To explore how these instruments fit together in practice, see our broader material on learning and the wider research-administration record. Counting outputs tells you what a researcher has produced; development frameworks tell you who they have become — and a fair research culture needs to recognise both.

  • Recognising technicians and research-support staff: the Technician Commitment

    Walk into almost any laboratory, imaging suite, sequencing facility or data centre that produces research, and you will find people whose names rarely appear in the papers that result. Technicians keep instruments calibrated and running; facility managers maintain the shared equipment that whole departments depend on; data stewards organise and preserve the records that make analysis possible; and a wide range of research-support staff provide the specialist expertise without which the work would simply stop. Their contribution is foundational, and it is frequently invisible. The conventional reward systems of academia — authorship, citation, the publication record — were built around a narrower idea of who does research, and they often leave support staff out. This article looks at efforts to change that, drawing on the mentorship and career-stages domain of the CASRAI Dictionary.

    The recognition problem

    The problem is partly structural. Recognition in research has long been organised around the published article and its byline, and around metrics derived from it. Someone whose contribution is essential but does not fit the authorship mould — who built and maintained the instrument rather than designing the study, who curated the data rather than interpreting it, who ran a shared facility used by dozens of projects — can find that there is no obvious place for them in the formal record. The result is a career landscape in which support staff may be indispensable yet under-recognised: harder to promote on the basis of contribution, harder to retain when their work is invisible, and easy to overlook when funding and credit are distributed. This is not merely unfair to individuals; it weakens the research enterprise, because skilled technical staff who feel unrecognised are exactly the people research can least afford to lose.

    The Technician Commitment

    One of the most prominent responses is the Technician Commitment, an initiative through which research organisations pledge to address the visibility, recognition, career development and sustainability of their technical staff. The commitment is built around several themes. Visibility calls for ensuring technicians and their contributions are recognised within institutions and in research outputs. Recognition and career development addresses the need for clear progression routes, professional development and proper standing for technical roles. Sustainability concerns securing the future of the technical skills base on which research depends. By signing, organisations make public commitments and report on their progress, turning good intentions into accountable action. The Technician Commitment matters because it names the problem at an institutional level and asks employers, not just individuals, to do something about it.

    Making support contributions visible in outputs

    Institutional commitments matter, but recognition also has to reach into the outputs themselves, where so much credit is anchored. Several mechanisms help:

    • Contributorship statements. Moving from a bare author list to a structured statement of who did what creates room to name and describe contributions — technical and supporting work included — that a byline alone would hide.
    • Authorship where warranted. Where a technician’s contribution meets the criteria for authorship, including them as an author is the most direct form of recognition, and contribution-based thinking makes that case easier to see.
    • Crediting data and software work. When the data a facility produces, or the software a research engineer builds, is published as a citable output, the people responsible can be recognised as creators and contributors in its own right.
    • Specific acknowledgement. Where a contribution does not rise to authorship, a precise acknowledgement that states what someone did is far more meaningful than a generic line of thanks.

    How CRediT helps

    A contribution-based view of recognition depends on having a shared way to describe contributions, and this is where the CRediT taxonomy is particularly useful for support staff. Several of its roles map directly onto the work technicians and research-support staff do: Investigation for conducting experiments and operating instruments, Data curation for managing, annotating and maintaining data, Resources for providing materials, instruments and facilities, and Software for those who build the tools. The full set of roles is set out in our overview of the CRediT roles. By describing contributions in these terms, a contributorship statement can record exactly what a technician did, in the same structured vocabulary used for every other contributor — which means their work appears in the formal record as contribution, not as an afterthought. That parity of description is itself a form of recognition: it places technical work on the same footing as the work that has always been visible.

    Recognition across the career

    Recognition is not only about individual papers; it is about careers. Technical and support roles are genuine research careers with their own trajectories, and recognising them properly means attending to progression, development and standing over time — the concerns of the mentorship and career-stages domain. When contributions are visible in the record, they can inform promotion and reward; when career structures acknowledge technical expertise, skilled people are more likely to stay and develop. Visibility in outputs and visibility in careers reinforce one another.

    A consistent record of who contributes

    For the contributions of technicians and support staff to be recognised consistently — across institutions, publishers and reporting systems — the way those contributions are described must mean the same thing everywhere. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so that the work of a technician, a data steward or a facility manager is understood and credited the same way wherever it is recorded. The Technician Commitment asks institutions to value the people who keep research running; a shared vocabulary for contribution helps ensure that value is reflected, honestly and visibly, in the record itself.

  • Recognising Research Software Engineers (RSEs) as a career path

    An enormous share of modern research depends on software: simulations, analysis pipelines, instrument control and the bespoke code that turns raw measurement into result. Building that software well requires deep expertise — in both the science and the craft of programming — yet for a long time the people who provided it had nowhere obvious to stand. They were too specialised in software to follow the conventional academic track, and too embedded in research to be ordinary developers. The result was a recognised gap in the research workforce, and a name for the people who fill it: the Research Software Engineer, or RSE. This article looks at how RSE has come to be recognised as a career path in its own right, a development that belongs in the mentorship and career-stages domain of the CASRAI Dictionary.

    The gap that created a profession

    The problem was structural. Academic careers have traditionally been built on publications and the metrics derived from them, with progression assuming a path through postdoctoral research towards a faculty post. Someone whose contribution was the software — who wrote the code that made a hundred papers possible but appeared as author on few — did not fit that mould. Such people were frequently employed on short, precarious contracts attached to individual grants, with no clear progression and little recognition for work essential to everyone around them. The consequence was damaging: talented people left for industry, where their skills were valued, and research lost the expertise it increasingly depended upon. Naming the role was the first step towards fixing a problem that had previously been nobody’s to solve.

    The RSE movement

    What grew from that naming has become an international movement. It began with the recognition that a community existed, scattered across institutions and disciplines, doing fundamentally similar work without a shared identity. Bringing those people together — under the banner of research software engineering — gave them visibility, a professional network, and collective weight to argue for recognition. The Society of Research Software Engineering emerged from the UK community to represent and support RSEs, organising conferences, fostering local groups and advocating for the profession. In the United States, US-RSE plays a parallel role, and similar associations have formed in other countries, increasingly linked through international cooperation. The movement’s achievement has been to turn a diffuse population of overlooked specialists into a recognised profession with a name, a community and a voice — the precondition for everything else that recognition requires.

    Building a genuine career

    Recognising RSE as a profession means building the infrastructure of a real career, not just adopting a job title. Several developments matter here:

    • Dedicated RSE roles and teams. Many institutions now host central RSE groups, employing software engineers on stable terms to support research across the organisation rather than tying each one to a single grant.
    • Career frameworks. Progression routes specific to research software engineering — with defined levels from junior to senior and leadership roles — let RSEs advance on the basis of their actual work, rather than being judged against a publication-driven academic ladder that does not fit them.
    • Stable employment. Moving away from short grant-funded contracts towards more secure positions addresses the precarity that drove people away.
    • Professional recognition. Treating research software engineering as a profession with its own standards, training and identity gives RSEs standing comparable to other research roles.

    Together these turn a label into a livelihood: a path a skilled person can choose, enter and progress along without having to pretend to be something they are not.

    Recognising software contributions in the record

    Career structures address how RSEs are employed; the scholarly record must address how their contributions are recognised. Two mechanisms are central. The first is software citation: treating research software as a citable output in its own right, with a persistent identifier, version information and clear authorship, so that the people who built it can be credited and cited just as the authors of a paper are. When software is citable, the RSE’s work becomes visible in the formal record rather than disappearing into a methods section. The second is structured contribution description. When a piece of research is reported, the work of building its software can be named explicitly rather than left implicit, which makes the RSE’s role legible to readers, evaluators and employers alike.

    The CRediT Software role

    That structured description is exactly what the CRediT taxonomy provides, and one of its roles speaks directly to research software engineering. The Software role recognises programming and software development, the design and implementation of computer code and supporting algorithms, and the testing of existing code components — precisely the work an RSE does. The full set of roles is set out in our overview of the CRediT taxonomy and explored further in the resources at our learning hub. By assigning the Software role, a contributorship statement records an RSE’s contribution in the same shared vocabulary used for every other contributor, placing software work on an equal footing with the work that has always been visible. That parity of description is a quiet but powerful form of recognition: it says that building the software was research contribution, not mere service.

    A consistent vocabulary for software careers and contributions

    For the contributions and careers of Research Software Engineers to be recognised consistently — across institutions, funders, publishers and reporting systems — the way those contributions and roles are described must mean the same thing everywhere. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so that an RSE’s software role, career stage and citable outputs are understood identically wherever they are recorded. The broader work of recognising the full range of people who make research possible is the concern of research administration, where careers, contributions and recognition come together. The RSE movement has shown that a profession can be built where none existed; a shared way to describe software contribution is what helps that profession take its proper place in the research record.