Notes on scaling a data-science function
From a single scientist to a cross-functional team without losing rigor.
The transition from a single data scientist to a cross-functional team is not a staffing exercise. It is a redesign of the function itself: what gets centralized, what gets embedded, what gets written down, what stays tribal — and which calls only you can still afford to make.
I built and now lead a data-science function that spans ML research, embedded integration, and product software. The interesting part was not the hiring. It was watching which things that worked at a team of one quietly stopped working, and rebuilding them before they failed loudly.
What actually breaks when you grow
At a team of one, the function is coherent for free. One person holds the whole pipeline — sensor, calibration, model, deployment — in their head, and every decision is consistent because it was made by the same brain on the same afternoon. That coherence is the thing you are about to lose, and most of the pain of scaling is the pain of manufacturing it deliberately once it stops being automatic.
The failures are predictable. Context that lived in one head becomes a bottleneck the moment two people need it at once. Standards that were obvious-to-you become invisible to everyone else, so quality drifts silently until something ships wrong. And the thing you were best at — the hands-on technical work — becomes the thing you have the least time for, right when the team most needs to see it done well.
None of these are solved by process for its own sake. They are solved by deciding, explicitly, what the function centralizes and what it distributes.
Hire for range, then depth — in that order
Early hires into a small cross-functional team are not specialists you slot into a fixed org chart. They are the people who will define the seams between disciplines that don't usually talk: ML research and embedded, algorithms and regulatory, model and product.
So I hire first for range — people who can hold a problem that crosses layers without dropping it at the boundary. The ML researcher who can read a datasheet and reason about what the sensor is actually doing. The embedded engineer who is not afraid of the math. The scientist who understands that a model is not done until it runs on the target hardware within the target budget. Range is what lets a small team cover a wide surface without shattering into silos that hand each other tickets.
Depth comes second, and it comes as the team grows. Once the seams are held, you can afford — and now genuinely need — the specialist who goes deeper on quantization, or optics, or the regulatory path than any generalist ever will. Reverse the order and you get a group of deep experts who each optimize their own layer and no one who owns the handoffs. The handoffs are where medical-device ML actually lives or dies.
A team of generalists ships a coherent system slowly. A team of specialists ships an incoherent system fast. The job is to sequence them so you get coherent and fast.
Rigor is a culture, and code review is where it lives
The hardest thing to preserve across growth is rigor — and rigor does not survive as a rule. It survives as a culture, and the highest-leverage place to cultivate it is code review that deliberately crosses the research-production line.
I learned this translating Python and MATLAB research prototypes into production C# under test-driven development. That work established a pattern the team later standardized on: research and production are not two worlds with a wall between them, they are one pipeline with a translation step, and the translation step is where correctness is either verified or lost. Making that step a reviewed, tested, first-class activity — rather than a thing a scientist does alone the night before a demo — is most of what "rigor at scale" means in practice.
Concretely, that means researchers read production code and production engineers read research code. The scientist has to see how their prototype becomes a validated component; the engineer has to understand the assumptions baked into the algorithm they are hardening. Review is not gatekeeping. It is the mechanism by which standards that used to live in one head become standards the team shares — and the mechanism by which a new hire absorbs "how we do things here" faster than any document could teach them.
Keep the scientists close to the bench
There is a strong gravitational pull, as a function scales, toward abstraction. Scientists drift from the sensor to the notebook to the dashboard, each step further from the physical thing the system measures. Every step is reasonable and the sum is a team that has forgotten what it is modeling.
I fight this. The people building models for a physical device need to stay close to the bench — the hardware, the calibration, the actual signal coming off the actual sensor under realistic conditions. Multimodal sensing systems fail at the seams between the physical and the computational, and you only see those seams if you are standing where they are. A model developed entirely on cleaned, cached data is a model that has never met its own failure modes.
Keeping scientists close to the bench is partly a staffing choice and partly a ritual one: hardware in the room, data collected by the people who model it, failure analysis done by looking at the raw capture rather than the aggregate metric. It is slower per-experiment and dramatically faster per-shipped-feature, because the failures that would have surfaced in the clinic surface on the bench instead.
What a Director actually owns
The last shift is the hardest to internalize, because it asks you to stop doing the thing you are best at.
At a team of one, you own the output. As a Director, you own the conditions that produce the output: hiring, technical direction, and the career development of the people doing the work. Your leverage is no longer the model you build — it is the standard you set, the seams you design, and the judgment you install in other people so they make the calls you used to make.
That does not mean leaving the technical work. I still hold technical direction, and I still believe a leader who has lost the ability to read the code and reason about the physics has lost the ability to lead this kind of team. But the unit of work changes. You are no longer optimizing a pipeline. You are optimizing the team that optimizes the pipeline, and the calls you reserve for yourself get fewer and heavier: the architecture decisions with long half-lives, the hires, the moments where rigor and a deadline are in genuine conflict and someone has to own the trade.
The redesign, in one line: centralize the standards, distribute the work, write down what used to be tribal, and reserve for yourself only the decisions whose cost of being wrong is too high to delegate. Do that well and the function scales without losing the thing that made it good when it was just you — the coherence. Do it badly and you get a bigger team that ships worse. The difference is almost never talent. It is whether someone redesigned the function on purpose, or just kept hiring.