When I took on the role of Associate Vice President for Research Informatics, the honest version of the job description was this: make institutional research data usable by the people who need it, at a scale and reliability that no single investigator's lab could ever produce on its own. That is not a hiring problem you solve by posting a requisition for "a research informaticist" and waiting. The people who can do this work at the level a large academic medical center needs mostly do not exist on the open market in the quantity you require. You have to build the team deliberately, and, harder, you have to build the pipeline that keeps producing the people the team is made of.
I want to be concrete about how, because most of the writing on this subject stops at "research informatics is important" and never gets to org-chart, roles, and the training mechanics that decide whether the function survives the departure of any one talented person.
Start with the function, not the headcount
The first mistake I see leaders make is to think of research informatics as a pile of technical FTEs to be assigned to grants. It isn't. It's a function with a stable shape, and the headcount only makes sense once you've named the shape. In my experience the function has four load-bearing capabilities, and a real team needs all four, not three.
- Domain translation. Someone who can sit between an investigator's clinical or scientific question and the data model that answers it. This is the role I personally occupy most often, and it is the one institutions most consistently under-resource because it doesn't map cleanly to either "IT" or "faculty."
- Software engineering. Senior application developers who build, maintain, and operate real systems through the full software development lifecycle, not scripts that work once on a laptop, but services other people depend on.
- Data engineering and curation. People who pull data out of the EHR and the enterprise data warehouse reliably, and who can abstract, structure, and quality-check it. Curation is skilled work; treating it as data entry is how you end up with a model trained on garbage.
- Early-career capacity. Post-docs, graduate students, and undergraduates doing real project work under supervision. This is not charity or filler. It is the part of the team that scales, and, done right, it is your hiring pipeline.
When I staff a project, I think in those four terms before I think in dollars. A grant that funds three excellent developers and no curator will fail in a predictable way: the software will be elegant and the data underneath it will be untrustworthy. The composition has to match the function, every time.
Mix seniority on purpose
The strongest teams I have built deliberately mix deep institutional veterans with early-career people, and the mix is not incidental, it's the design.
On one project, the senior application developer had more than fifteen years in clinical informatics: cancer research, specimen management, clinical trials management, personalized medicine, open-source contribution, commercial software. She had carried real systems through their full lifecycle. Around her I placed a data manager fluent in the specific topology of our data warehouse, a pair of staff scientists who could curate and, critically, train and write the standard operating procedures other curators would follow, and a post-doctoral position to run day-to-day execution. The veterans hold the institutional memory and the standards; the early-career people supply throughput and inherit the craft.
That last clause is the whole point. A staff scientist who is "efficient at information retrieval and abstraction" is valuable. A staff scientist who is efficient and writes the curation SOPs and trains the next curators is worth several of the first kind, because she is manufacturing the team's future capacity while she works. When I evaluate senior hires for research informatics, I weight that teaching multiplier as heavily as I weight raw individual output. The veteran who only produces is a single point of failure. The veteran who produces and reproduces is infrastructure.
The pipeline is the strategy
Here is the part most institutions get wrong: they treat the team and the training program as two different budgets owned by two different people. They are the same thing. A research-informatics function that can't grow its own people is one resignation away from a crisis, and the academic labor market will not bail you out on the timeline a grant requires.
I learned this most clearly running a small mCODE genomics project with a team of four undergraduate computer-science students. The brief was to demonstrate that we could lift structured genomic data out of the EHR and serve it as standards-conformant FHIR resources on Azure. The students were not cheap labor filling in for staff we couldn't afford. They were the point: the project introduced biomedical informatics as a viable career to people who had never considered it, taught them cloud DevOps and FHIR, genuinely valuable skills they would carry forward, and produced a reusable artifact other implementers could build on. One of those undergraduates became the senior developer and first author on the resulting paper and is now in a bioinformatics PhD program. That is what a pipeline looks like when it works: the training and the deliverable are the same activity.
This is why I built clinical informatics into the medical-student curriculum and created a graduate medical education elective, and why my colleague Dara Mize and I argued for a unified approach to clinical informatics education across undergraduate and graduate medical education at the 2022 AMIA Annual Symposium. "Unified" is the operative word: the medical student, the resident, and the fellow are one continuum, not three disconnected audiences, and informatics should be present at every stage rather than appearing abruptly as a niche elective for the already-committed. The team you can staff in five years is determined by the curriculum you build today.
Fund the platform, not just the people
A research-informatics team needs an environment to work in, and that environment is itself a deliberate build. Hands-on informatics training is usually impractical because of the licensing, security, and infrastructure overhead of giving learners realistic clinical data and systems to work against. My 2020 Microsoft Investigator Fellowship, a two-year award explicitly for scaling clinical informatics education through Azure-based virtualization, was aimed squarely at that obstacle: build the cloud infrastructure that lets a learner stand up a real environment without first solving the institutional provisioning problem from scratch.
The leadership lesson generalizes beyond that one grant. When you stand up a research-informatics function, budget for the platform as a first-class line item, not an afterthought, storage that scales from terabytes to the hundred-plus terabytes genomic data demands, elastic compute the team can pool for heavier analyses, and a governed place to store and query structured patient data. If you fund the people and starve the platform, you've hired skilled engineers to fight your own infrastructure instead of doing the work you hired them for.
What the infrastructure actually buys
This is not abstract. The platform and the team are what turn ideas into shipped work that no single investigator's lab could produce, and the clearest way to justify the investment is to point at what depended on it. The mCODE genomics pilot above ran on exactly this kind of cloud platform. The multi-year GE HealthCare collaboration that produced our models for immune checkpoint inhibitor effectiveness and toxicity depended on the data engineering and curation capacity to turn routine EHR data into something a model could learn from at scale. And the structured-genomics integration I describe in bringing genomics out of the PDF and into the chart sits squarely in this body of work. Each of those is a beneficiary of the function, not a side project that happened to occur next to it. Starve the function and none of them happen.
Make it an institutional strategy, not a personal hobby
The failure mode I most want leaders to avoid is the one where the whole function depends on the enthusiasm of one person. Individual enthusiasm leaves when the individual does. A team built around a single irreplaceable translator, or a training program that exists only because one faculty member volunteers to teach it, is not a capability, it's a liability with a shelf life.
The antidote is to make the strategy explicit and shared, so it does not live or die with whoever happens to care this year. The same discipline applies to the operational team. Write down the four capabilities. Write down who owns each. Write down the SOPs so curation survives a departure. Write down the training continuum so the pipeline doesn't depend on a single champion. A function you can describe on paper is a function the institution can sustain; a function that lives only in one person's head is one you're going to rebuild from zero, on a worse timeline, at the worst possible moment.
What I'd ask of leaders and boards
If you're a dean, a center director, or sitting on a board weighing investment in research-informatics capability, three asks.
First, fund the function as a whole, not as a stack of project FTEs. A team that has engineering but no curation, or capacity but no senior translators, will produce expensive disappointment. Second, fund the pipeline and the platform on the same timeline as the team, the people you'll need in five years are being trained (or not) right now, and the infrastructure they need is a capital decision, not a line you cut when budgets tighten. Third, demand that the whole thing be written down: the roles, the SOPs, the training continuum, the governance. The test of a real capability is whether it survives the departure of its most talented member. If the honest answer is no, you don't yet have a function, you have a person, and people leave.
Research informatics is buildable. I've watched it compound: undergraduates become first authors, fellows become faculty, one-off projects become reusable infrastructure, and a curriculum becomes a hiring pipeline. None of it happened by accident, and none of it happened fast. It happened because we treated team design and training as the same deliberate act, which is exactly how I'd advise you to treat it. See the broader leadership and clinical informatics education work for where these threads connect, and the research record for what the team has actually produced.