When a pharma team spots an opportunity for an AI project, it usually starts with a concrete hunch: maybe there's latent signal buried in years of regulatory data, or a way to optimize how evidence generation is planned across global markets. Maybe there's a promising class of small molecules, and the goal is to train a classifier to predict which candidates will fail on toxicity before burning wet-lab budget synthesizing them.
The pieces are on the table: a real hypothesis, a dataset (or at least a plausible pipeline to scrape and clean one), and a sponsor who might fund it.
Before anyone signs off on the money, before we even know how much money we need, someone has to answer the most important question: how would we build it? Who do we need to hire?
The default reflex is to go out and hire "an AI person."
Right here at step zero, a shocking number of projects quietly derail.
The phrase "an AI person" mashes six completely distinct engineering and scientific functions into a single magical job description. In reality, someone has to deeply understand the underlying biology or clinical mechanism. Someone has to define the exact evaluation metric for what counts as a useful prediction. Someone has to audit the dataset to see if the signal is even theoretically present in the features. Someone has to stand up the data plumbing and infrastructure. Someone has to build a rigorous validation split without accidentally leaking test-set labels into the training run. And someone has to run the unit economics to prove that even if the model works, it actually moves the needle for the business.
Those are fundamentally different jobs. A strong generalist might be able to wear two or three of those hats at once, but slapping "Lead AI Scientist" on a LinkedIn req doesn't collapse the complexity of the stack.
If I were spinning up a strike team to tackle this from scratch, I'd structure it around four core roles, plus a fifth specialist that some problems require from day one:
A skeptic with a high bar for rigor
A domain scientist who owns the impact
A systems technologist who designs the system and deeply respects the domain science
A pragmatic builder who writes the code and runs the experiments
And, for some problems, a dedicated ML modeler.
One job sits outside the team. Before you hire anyone, a business owner has to make the case that the idea is worth funding: if the team clears the bar the skeptic sets, the company should earn back many times what it spent. The staffing plan below belongs in that case. Treat the case as a gate. Once a project passes, staff the seats below.
1. The skeptic: define what success means
The first hire is the skeptic; someone with deep statistical intuition and a high bar for rigor, who owns the eval harness.
This isn't a professional naysayer who sits in meetings explaining why nothing will work. Their job is to make the project falsifiable. They ask the baseline questions up front: what decision does this system actually support? What is our human baseline right now? Which errors are catastrophic versus acceptable?
You need this person even if you never build a model in house. If you buy a vendor tool or call a frontier model, someone still has to test it against your problem; part of the skeptic's job is baselining what those off-the-shelf options already do. You need the seat the moment anyone applies AI to a problem, whoever built the model.
Scientists tend to default to "the AI has to be perfect," though no human scientist is perfect either. The skeptic turns that into a threshold everyone in the room agrees on: how many false positives the team can live with, how many false negatives, and what sensitivity and specificity would make a scientist change what they do next.
Take toxicity prediction. When someone says, "We need a high-accuracy model," the skeptic immediately unpacks the hidden variables. Accurate at what threshold? On which chemical scaffolds? Against which assay? And what's the asymmetric cost of a false negative (a toxic molecule slips into synthesis) versus a false positive (you throw out a good drug candidate)?
If 95% of your dataset is non-toxic, a one-line script that is hard wired to predict "non-toxic" every time hits 95% accuracy while doing zero useful work. The metric looks good only because it ignores class imbalance.
The skeptic translates the real-world workflow into a proper evaluation suite – tracking sensitivity, precision@K, calibration, or human review time. Because there's rarely a single magic number, they force the team to agree on the trade-offs before anyone trains a model and gets emotionally attached to a result.
Once a prototype exists, the skeptic tries to break it. They hunt for train/test leakage – checking if near-duplicate documents or close chemical analogs are sitting in both splits, letting the model cheat via memorization. They slice performance on the hardest edge cases and separate real signal from random noise.
Crucially, they also guard the test set from the team itself. If engineers inspect test failures, tweak the system, and re-run the eval 50 times, they've just overfit to the test set via human gradient descent.
A great eval doesn't guarantee success in production, but it gives you a clean, bounded read on reality: here is what we tested, here is what happened, and here is what the evidence actually supports. That is a much stronger basis for a decision than a cherry-picked demo.
2. The scientist who owns the impact
The second hire is the domain scientist who owns the impact: the person who makes sure the team is solving the right question.
Their primary job is to understand the real-world biology or clinical workflow deeply enough to catch the team the moment they start solving an adjacent, easier problem instead of the real one.
Adjacent problems are a massive trap in ML because they feel so rewarding to solve. Your LLM pipeline summarizes regulatory PDFs beautifully, when what the scientist actually needed was a way to flag subtle contradictions across sections. Your classifier gets a great F1 score predicting a clean in-vitro assay label, when the team actually cares about a messy downstream in-vivo toxicity outcome. Your optimizer cuts the number of recommended clinical studies in half, while completely ignoring a regulatory constraint that every practicing clinician takes for granted.
In all those cases, the code is doing exactly what it was optimized to do, while the project quietly drifts into irrelevance.
The domain scientist anchors the objective function and prevents drift. They map how decisions actually get made today, where domain experts trust, where baseline uncertainty already lives, and what exact bar an output must clear to make a chemist or clinician change their next action.
Even more importantly, they inspect the data labels. In computer science, we love to treat the y column in a dataset as objective "ground truth." In biology and medicine, "ground truth" hides a ton of messiness. Wet-lab assays have measurement noise. Two senior experts looking at the same readout will disagree. Historical regulatory decisions in your training set might reflect political or commercial context that was never logged in the database. Somebody on the team has to understand what the training labels physically represent.
When hiring for this seat, you want curiosity way more than AI hype. Plenty of scientists have been sold AI smoke and mirrors before; when they dismiss a new pitch, they're being reasonable. You need one who has seen those failures and still comes to the table curious enough to look at the new empirical results with an open mind.
What never works is treating this role as a part-time consulting gig where an engineer gets 30 minutes with a "subject-matter expert" every two weeks. The scientist needs real skin in the game and enough bandwidth to steer the experiment day to day. Otherwise, the engineers will spend six months optimizing a loss function, only to discover at the final demo that they answered a question nobody was actually asking.
3. The systems technologist: designing the system
The third seat is the technologist who translates the scientific problem into an actual software architecture.
You obviously need strong engineering depth here, but just as importantly, you need someone with the humility to obey Chesterton's Fence – someone who takes the time to learn why the existing scientific workflow looks as weird as it does. Many apparent "inefficiencies" in pharma exist because of hard regulatory or biological constraints that are easy to miss from the outside.
A manual human review step might be load bearing. Two database columns with nearly identical names might encode subtly different clinical concepts. A NaN in a dataset might mean "assay not run," "not applicable to this molecule," or "measured, failed QC, and dropped." To a naive script, those are all just missing values; to the problem, they are completely different signals. The technologist has to actually care about those nuances.
Their first real job is problem decomposition.
For a regulatory research tool, the bottleneck is probably PDF parsing, chunking, RAG retrieval, strict citation grounding, and careful prompting of an off-the-shelf frontier LLM.
For clinical evidence planning, maybe an LLM extracts candidate requirements into JSON, a human expert verifies them, and a deterministic optimization algorithm (operations-research software, not a human analyst) works out the best combination of studies.
For molecular toxicity, you probably need custom graph or sequence representations and specialized predictive models.
The architecture should fall naturally out of that decomposition, not from whatever hammer happens to be trendy on X that week.
In the beginning, the scientist and the technologist should be joined at the hip. They're building a shared mental model of the data types, what the output actually means, and how it plugs into a real human decision – and they'll have to keep updating it the moment their early assumptions collide with the actual data.
4. The builder: making the experiment run
The fourth role is the builder. The technologist designs the system; the builder makes the code and the experiments actually run.
They pull the raw data, wire up the APIs, write the ingestion pipelines, implement the baseline and the proposed architecture, log the runs, and make the whole thing deterministic and reproducible.
From 30,000 feet, people dismiss this as "just data plumbing." Up close, this is where reality and clean whiteboard theories collide. The same molecule has four different internal IDs across three departments. The SQL dump is missing the exact column the scientist thought you had. An upstream API changes its schema. Nobody knows which git commit generated last week's promising chart.
A great builder brings order to that chaos. For an exploratory sprint, you don't need over-engineered enterprise microservices. You need a clean, reliable experimental harness: versioned datasets, traceable model outputs, one-command repeatable evals, and good enough logging that you can actually look at your data and inspect the failure modes.
The builder also runs the experiments. Even if the team only uses off-the-shelf LLMs, someone has to test them rigorously against the skeptic's eval criteria: try a range of models, prompts, and settings, slice the results, compare runs, use what they learn to improve the next version, and write up the findings for the rest of the team. How much science and modeling this takes depends on the problem and the techniques. The skills often overlap with the skeptic's or the modeler's, usually in someone more junior who spends their days in the details.
Teams need less depth in this seat than they used to. In the early experimental phase, a junior engineer with good coding tools can get very far, especially with a sharp tech lead setting direction, as long as the company pays for those tools. A senior person should still check the calls that tools can't make: where the data came from, silent bugs, system state.
Staff this role based on how messy the underlying environment actually is and how much experimenting the problem needs. If step one requires joining twelve legacy databases with incompatible schemas, data engineering is the project.
5. The modeler: needed from day one, or not at all
The fifth role is the dedicated ML modeler. Whether you need one depends on the problem; you can usually tell before the project starts.
Some problems genuinely need someone who lives and breathes model architectures, custom loss functions, training dynamics, and out-of-distribution generalization. Toxicity prediction almost certainly needs this, even if you start from open-source weights. You still need someone who understands whether that representation space actually makes sense for your specific chemical scaffolds, assay noise, and downstream use case.
On the flip side, a regulatory document workflow will get 95% of its mileage from clean document parsing, smart retrieval, good UI/UX workflow design, and rigorous evals on top of frozen frontier models. Fine-tuning or pre-training your own weights there is usually a massive distraction.
That leaves two separate paths. When the problem needs a modeler, you can't skip the hire; a team that adds one halfway through has already spent months on the wrong foundation. When the problem doesn't need one, the hire wastes time and money. Don't hire a custom modeler just because the project pitch deck has the letters "AI" on it. Equally, don't ask a full-stack web engineer to wing it on a subtle domain-shift problem in computational biology.
Paradoxically, companies often make the modeler their first AI hire, and sometimes their only one. Hiring managers find it the easiest seat to fill: they look for a PhD in machine learning. A PhD student earns the degree by doing novel modeling work. A team gets impact from a project by caring about all the details a PhD program ignores.
On seats versus hats
To be clear, these are five distinct seats, not necessarily five full-time hires. A seat is a responsibility the team has to cover. A hat is what a person wears when they cover one; one person can wear several.
A domain scientist with strong biostats chops can easily wear the skeptic hat and own the evals. A strong technical lead can often act as the builder for v0. A modeler might drive the experimental design. Wearing multiple hats is great; it keeps the communication overhead low and the iteration loop fast. The only rule is that every seat needs an explicit owner.
Just be extra careful when combining the builder and the skeptic into one person. When the person building the model is also grading its homework, human bias creeps in quickly. If one person wears both hats, you need structural guardrails: pre-commit to the evaluation protocol up front, lock the holdout test set away in a vault, and get an independent set of eyes to review the final run. The goal is a small, high-trust unit that actively red-teams its own work.
How the loop runs in practice
A well-run project starts with a clear, 1-page spec: the specific scientific question, the downstream workflow it plugs into, the baseline to beat, the data on hand, the pass/fail eval metrics, and the exact business decision this experiment will unlock.
Phase 1 (Translation & Plumbing): The scientist and technologist lock in the problem formulation. The builder gets data access and stands up a reproducible pipeline. The skeptic stress-tests the eval harness to make sure it can actually separate real signal from noise.
Phase 2 (The Iteration Loop): The team runs experiments, looks at the error distribution, iterates on the system, and tests hypotheses. Progress here isn't measured in slide decks; it's measured in movement against the baseline, sharper mapping of the failure modes, or cleanly falsifying dead-end approaches.
Phase 3 (The Final Readout): You run the locked system against the held-out evaluation criteria. The scientist verifies that the system didn't drift away from the real biological question. The business owner plugs the real-world error rates and latency/compute costs back into the ROI model.
This is roughly the blueprint we run at Hop. It's designed to produce an empirical artifact leadership can actually bet on.
What happens at t + 1 (after the readout)
Finally, decide up front what happens the day after the experiment finishes.
If the experiment succeeds, somebody has to productionalize it, monitor for data drift, maintain the upstream data pipes, build the human review UI, and own the additional compliance validation. Sometimes your exploratory strike team is the right crew to transition into build mode; often, they aren't. Some companies hand the system to a differently skilled operating team; others have a maintenance crew check in once a quarter. Whichever you choose, count that total cost of ownership before you fund the experiment, not after.
If the experiment fails, you need to know why. Start with the team. Did they fail, or did they make principled progress that just didn't get far enough? Would more time get them there? Did something hold them back that you could unblock? Then look at the idea. Did we hit an information-theoretic wall because the signal just isn't in the features? Did we hit the ceiling of the current model class? Did we uncover a fixable upstream data-collection bug? Or is the signal real, just underpowered because our sample size N is too small?
Each of those post-mortems points to a completely different next move. The only good reason to fund phase two of a project is having a crisp, unresolved hypothesis and a concrete experiment designed to test it. "Well, we already spent nine months on this" is the sunk-cost fallacy talking.
That clarity is ultimately what proper staffing buys you. Make the business case before you staff the team. Hire the skeptic on day one. Give the domain scientist real skin in the game. Find a technologist who respects the biology. Resource the builder so your runs are reproducible. Decide on day one whether the problem needs a specialist modeler. We do these things because they make the readout actionable.
Pharma companies need to minimize time as aggressively as spend; the second or third company to market in a drug class often earns a very different return from the first. In pharma, the "minimum" in Minimum Viable Team is as much about time as budget. Staffing a project with the cheapest headcount you can fund is penny-wise and pound-foolish if that team doesn't reach the finish line quickly (or worse, doesn't reach it at all). The true Minimum Viable Team is the smallest possible cluster of people who can get you in the shortest time hard, empirical evidence on whether an idea deserves another dollar or another day.