 Hello and thank you for tuning in to our talk, Rewarding and Recognising Team Infrastructure Rules. My name is Esther Blompe and I'm a data steward at the Delft University of Technology in the Netherlands and I'm Ariel Bennett, programme manager for the tools, practices and systems programme at the Alan Turing Institute. And today we'll talk about rewarding and recognising team infrastructurals. But this is heavily based on work that we've been collaborating on with several of our co-authors, which are listed in the slide, in a work that's called a Manifesto for Rewarding and Recognising Team Infrastructure Rules. And we have a pre-printout, so anything that we're touching upon now you can read upon in more detail in the pre-print. But before we start talking about how do you recognise and reward these team infrastructurals, we figured it would be more helpful to discuss first who or what these team infrastructurals are. And these can be a great variety of roles that are contributing to research. So there's a couple of roles listed in the slide, such as laboratory technicians, librarians, data stewards, data managers, research software engineers, community managers and the list goes on and on and will likely develop in the upcoming years as more of these roles develop. What they have in common is that they make great contributions to research and they are involved in a research process, but they are not necessarily incentivised to participate in the credit economy, which in research is still producing academic papers. And we have called them Team Infrastructure Rules, infrastructure to stress that they actually play a structural role in this research process. And we argue that there are many benefits of having these types of roles in research. It increases the amount of specialised expertise you can have in research teams, which would allow them to tackle more complex challenges that individual researchers would not be able to handle. It also contributes a lot more diverse perspective to research, not just skills, but also different perspectives. And by having this specialised infrastructure in place, you can also improve the productivity and processes involved in research, because you're no longer relying on a single individual being able to do all the things. And that is building on the quotes that Kersi Whitaker made at AIUK this year. We basically cannot expect individuals to be able to perform all the tasks of academia to the highest standard. It's just not possible that we can be a specialised unicorn in everything and do all the things. On the other hand, another quote from McFerrin here is saying that if you pass these tasks to professionals, you are basically hollowing out what it means to be an academic. So these are two different perspectives on this. And what we're here for today is to generate some of our own quotes by giving you some of our more personal perspectives regarding the team infrastructurals, because the two of us are both involved in such a role. So myself as a data steward and Ariel as a program manager. And as a data steward at the Delft University of Technology, I am mostly providing other researchers with any support regarding data management, software support and any open science questions. And in this role, for me it is quite challenging to see a career path beyond my career as a data steward. One of the career paths is to become a data stewardship coordinator. But what if I don't want to manage other data stewards and I would rather be more directly involved in the research process. So there's not really a clear option available for that. There are a lot of opportunities to be more directly involved in research. It's more of an advisory role. And so what I've thankfully been able to do, and that is also because I have a very supportive manager, is to become more involved in other communities that are focusing more on open science, which has allowed me to develop skills. So basically become more involved in the community and also with other researchers outside of my faculty. So I'm a project member at the Turing Way, a mentor expert at Open Life Science, and also an open research ambassador and board member at ISOARC. And while it's great that I can gain experience in mentoring, being a part of committees, being a part of boards, etc. Sometimes it feels a little bit like this is not fully part of my role as a data steward. And it becomes a bit of a hobby sometimes. And that is also dangerous in terms of life health balances, life work balances, sorry. These are some of the challenges that I'm dealing with. And now to Ariel. Yeah, so as a program manager at the Alan Turing Institute, I have a fantastic and incredibly varied role. And I have to say I'm also very lucky to be part of an incredibly diverse team who supports and recognises everybody's contributions to the research process. But what I find is because my role is on a day to day basis is predominantly an operational role. It can be incredibly difficult to find the time to contribute to open science to contribute to the research processes and the way that I would like to, and to also sort of do some of the writing in the thinking that I would also also like to do as well. And so as a project member of the Turing way I have tried to build this into my day to day. So sharing advice and expertise via its project design, yeah project design guide. And the other areas bringing in my knowledge of labour organising and union unions into the research ethics guide as well on the basis that ethical research includes ethical working conditions for everybody involved in that work. But yeah, finding time to participate when there are a lot of demands on my time that aren't necessarily visible to the researchers is a massive challenge. The only challenge that I do faces that sometimes I find that there are. There's more weight placed on academic voices. When it comes to sort of making decisions, even when people in the room who work in team infrastructure roles might have more specialist expertise that would be better served. Working on that, or providing the path forward, I think so. These are not just our unique perspectives and challenges. We have, as Esther mentioned, we've been working on a manifesto for rewarding recognising and rewarding team infrastructure roles. And we go into some of these emerging challenges in more depth in the paper. We do see folks finding that they have a notable lack of autonomy in these roles so they're perhaps limited by either task requirements or by narrowly scoped and defined contributions rather than being allowed to engage their creativity and their expertise. For some roles, these they're very emerging and incredibly new roles such as research application managers or data students have really not been around for very long at all. And this leads to a limited formalization of career pathways. So for example, for me, if I want to move on from being a program manager, there are sort of not that many options in terms of, you know, growing and challenging myself that exists yet. So when we think about the traditional prejudice that we've seen from McFarlane in 2011 about the team infrastructure role activities and career choices. And I have, you know, in previous roles, heard people describe folks who've chosen team infrastructure roles as, you know, not being successful when in actual fact they're providing an incredibly specialized sets of expertise that would be impossible to develop without making a career choice to develop those skills and expertise and to devote time and effort into it. And then finally, the limited range of academic recognition at the moment really erases a lot of team infrastructure role contributions towards research process. For example, as a program manager, I'm not typically acknowledged on papers and that is a standard thing that we see throughout academia, bioinformaticians for example, or research software engineers have long known the challenges of being included as middle authors rather than first or last. And indeed the focus on who is first and who is last on a paper is an overarching challenge, I would say, academia in general as well. So we see all of these challenges with this emerging class of roles that is linked to sort of the challenging the structures of academia. So it's not all doom and gloom we didn't want to come here and just tell people how difficult it is to manage these roles. There are processes and pathways forward that we also propose in the preprint as well. But first up, our recommendation is to focus on the process and not the outcomes of research so moving away from that traditional view of the academic paper as the be all and end all of academic success or research success. The ability to focus on how the research is done is it done in a collaborative way. Is the code well documented is it written well, what other outputs are being produced and how is the work actually being done in a way that's mutually respectful and collaborative. All of these things should be valued just as much as academic papers and sort of research artifacts. So by this we also strongly advocate for it's massively expanding the system that currently is widely acknowledged as the way to recognize contributions. So taking into account the unique contributions that team infrastructure role can make to each part of the research process would go a long way to, you know, supporting these roles and kind of highlighting the mutual respect for them from the academic system. And then these all complement each other very nicely but there's also the idea of a system to validate the research outputs as well to ensure that what's being produced is reproducible it's reusable and it's of high quality. And finally, we strongly advocate for standardized roles and pathways for career development that exists outside of the traditional tenure track towards professor at the end. In the paper itself we go into a bit more detail and we actually look at three roles that are in various stages of maturity from research software engineer with a relatively well established pathway a series of professional networks across the globe. And I would also say quite a lot of high esteem and prestige for those working in in those teams through to newer roles that are still in the process of being developed and emerging to address the variety of research needs that we're finding. And we make the case that research software engineers could potentially form something of a blueprint for these other roles to follow in terms of networks development opportunities and career pathways forward as well. And also, if you've listened to this talk and you think, oh, this sounds great. I realize but actually I'm a I'm working in team infrastructure role as well. Esther and I would love to hear from you. We have co authored and helped other people to contribute to the chapter in the turnway called research infrastructure roles, highly analogous to the team infrastructure roles that we're talking about now. So if you'd like to share a description of your role, or you'd like to share your career pathway as a case study for this chapter please do open an issue on GitHub. We would love to have a chat with you and, you know, take your feedback as well on on the existing roles that we're currently covering there. And this is open as well you also don't need our permission to come along and suggest changes we'd love to have you on board. In summary, very quickly, team infrastructure roles provide diverse benefits to research processes and outputs and I would argue are a cornerstone of how modern research can and should be done. But there are challenges with integrating team infrastructure roles into the way that we view the research process now in the modern day, including levels of autonomy, career development and also mutual respect as well. And finally that focusing beyond papers towards processes and broader outputs from the research process is only going to benefit, not only those working in team infrastructure roles but actually the broader academic sphere as well. The recognizing more diverse contributions, recognizing a variety of contributions is really the way forward the future of academia and so if you disagree with that that's also fine. But in closing I'd like to finish with a particular question that you know whether you agree or disagree with what we've discussed here and sort of the challenges is what we're really wanting to try and tackle is how we need to, how we should remake the system so that these kinds of diverse roles truly seem as integral participants in research. So with that. Thank you very much to our co-authors on on the preprint. A huge thank you to the Turingway, OLS and the wider open science communities. Thank you to the Turingway illustrations by Scriberia that you've seen some of them throughout the talk. And I'd also like to extend a particular thanks to the tools practices and systems program at the Alan Turing Institute, where I get to work with an incredible diverse range of team infrastructure or research infrastructure role people, and it's an amazing space so huge thanks to them as well.