More Hands, Less Speed: Why Adding People to a Late Device Program Backfires
When a medical device program falls behind, the reflex is to add engineers. In a regulated environment it usually makes things later, not sooner. Here is why the instinct fails — and what actually pulls a late program back in.
The instinct that feels like progress
A program is behind. The submission date has not moved. The room is tense, and someone says the obvious thing: we need more people on this. It feels decisive. It feels like progress. Headcount is visible, it is fundable, and it gives everyone something to point to. And in a medical device program, it is usually the move that makes the slip worse.
This is not a new observation. Fred Brooks captured it half a century ago in software: adding people to a late project makes it later. What is less appreciated is how much harder that law bites in a design-controlled, regulated development environment — where the cost of bringing someone new up to speed is not measured in a few days of orientation but in weeks of your most experienced engineers' time, and where every additional person adds traceable handoffs to work that has to withstand an audit.
The schedule math is only half the reason the reflex fails. The other half is hidden in the org chart, and it is worth making visible.
More hands is not more speed. In device development, speed comes from reducing what a small, expert team has to carry.
Why regulated development punishes the reflex
In an unregulated build, a competent new engineer can often start contributing quickly. Read the ticket, read the code, ship something small, learn as you go. Medical device development does not allow that on-ramp, and for good reason. Before a new person can safely touch anything that matters, they have to absorb the context that keeps the work compliant and traceable.
They need to understand the design history and the decisions already locked in. They need to know the risk file — what hazards have been identified, what controls are in place, and why. They need to understand the design controls, the applicable procedures, and the documentation discipline that every change has to follow. Skipping that context does not make the person faster; it makes them dangerous, because in this domain an uninformed change can invalidate evidence, break traceability, or introduce a risk nobody catches until validation.
Figure 1 — A new engineer can't just start. The ramp to safe productivity is paid by the people who were already the constraint.
Here is the trap: that ramp is not free, and it is not paid by the new hire. It is paid by your most experienced people — the exact individuals who were already the bottleneck. Every hour a senior engineer spends transferring context is an hour they are not spending on the critical work only they can do. So for the first several weeks, adding people does not add output. It subtracts it.
What the output curve actually does
If you plot it, the effect is not subtle. The moment you staff up, net team output does not rise — it dips, because your experienced people are now onboarding instead of delivering. Coordination overhead climbs at the same time, because every added person is another set of handoffs on work that has to stay traceable, and communication paths grow faster than headcount does.
Figure 2 — Net output dips during onboarding, then recovers — often to below the trend line you were already on.
Eventually the new people become productive and output recovers. But two things are true by then. First, you have already lost weeks of net output during the dip — weeks a late program did not have to give. Second, the recovered trajectory often lands below the line you were already on, because the coordination tax does not go away once onboarding ends. You paid a real cost for a smaller-than-expected gain, and you paid it at the worst possible moment.
Adding people to a late program does not buy you speed.
It buys you a dip you cannot afford, followed by a recovery you did not need to pay for.
The coordination tax nobody budgets for
The onboarding dip is the cost people can at least picture. The coordination tax is the one that gets left out of the plan entirely, and it is often the larger of the two. The reason is simple arithmetic: adding people does not add communication paths one at a time — it adds them geometrically. A team of five has ten possible pairwise channels to keep aligned. A team of ten has forty-five. You roughly doubled the headcount and more than quadrupled the number of relationships that have to stay coordinated.
In a regulated program that arithmetic is not abstract, because alignment is not optional. Every one of those channels carries decisions that have to stay consistent with the design history, the risk file, and the change-control record. More people means more reviews, more approvals, more handoffs, and more opportunities for two parts of the design to drift out of sync without anyone noticing until an audit or a verification run surfaces it. The overhead is real work, it lands disproportionately on your senior people, and it does not disappear when onboarding ends — which is exactly why the recovered output curve so often settles below the trend you were already on.
The practical implication is that headcount and throughput are not the same quantity, and in a late-stage device program they can move in opposite directions. Before you add a person, it is worth asking a blunt question: will this addition reduce the load on the constraint, or will it simply add another node to a network that is already expensive to keep aligned?
What actually pulls a late program in
If more people is the wrong lever, what is the right one? The answer is almost always to reduce the load on the small, expert team you already have — not to enlarge the team. Four moves do most of the work, and they can be started this week.
Figure 3 — Four moves that pull a late program in without adding the onboarding tax.
1. Cut scope before you add headcount
The fastest schedule lever in device development is almost never doing the same work faster — it is doing less work. Separate what this submission truly needs from what can wait for the next one. A feature deferred to a follow-on release, a claim narrowed, an option removed: each of these shrinks the evidence you have to generate now. Less to prove is less to build, verify, validate, and document. Before you spend a dollar on headcount, spend an afternoon on scope.
2. Protect your critical few
Your senior engineers are the constraint, so treat their time as the scarcest resource on the program. The instinct to pile context transfer onto them is exactly backwards. Instead, take low-value work off their plates — reviews that someone else can own, documentation support, meetings that do not need them — so that their hours flow to the work only they can do. Relieving the bottleneck is worth more than adding capacity somewhere the program is not actually constrained.
3. Add people at phase boundaries, not mid-stream
There is a right time to bring people in, and it is not the middle of a sprint toward a gate. Onboarding lands best at phase boundaries — when the plan is being rebuilt anyway and the team is re-orienting. Dropping a new person into work already in flight forces context transfer to compete with delivery, which is how you get the dip at its deepest. Timing the addition to a natural boundary lets the ramp overlap with planning instead of colliding with execution.
4. Re-baseline honestly
A schedule that everyone privately knows is fiction has already stopped driving decisions. People pad, hedge, and quietly work to a different plan in their heads. The single most clarifying act on a troubled program is often to re-baseline honestly — to build a plan the team actually believes, with scope and sequencing that reflect reality. A credible schedule is not an admission of failure. It is the thing that lets the team make real trade-offs again instead of managing appearances.
When adding people does make sense
None of this means never hire. It means be precise about when added capacity helps. Adding people works when the constraint is genuinely capacity rather than expertise — when there is well-scoped, separable work that a new person can own without deep program context, and when there is enough runway for the onboarding dip to pay back before the deadline. It works when you are building for the next program, not rescuing this one. And it works far better when the additions are planned at a boundary and paired with scope discipline, so the new capacity lands on a program that has already reduced what it is carrying.
The failure mode is not hiring. It is reaching for headcount as a reflex, mid-crisis, mid-stream, as a substitute for the harder conversation about scope and sequencing.
Signals you are staffing the wrong problem
A few patterns tend to show up when a team is about to add people for the wrong reasons:
The plan to recover the schedule is a headcount number, with no matching reduction in scope.
Your most senior engineers are increasingly in onboarding and review meetings and decreasingly in the work only they can do.
New hires are being dropped into work already in flight, not at a planned phase boundary.
Everyone nods at the schedule in the room and works to a different one in private.
Communication and coordination overhead is climbing faster than delivered output.
What good looks like
A well-run recovery does not look like a hiring spree. It looks like a program that got smaller and clearer. Scope has been cut to what the submission truly needs. The senior engineers who are the real constraint have been shielded, not loaded. Any people added were brought in at a boundary, onto separable work, with runway to ramp. And the schedule is one the team believes, so it is once again driving decisions instead of hiding them.
That is what “Medical Device Excellence” means when a program is in trouble: not heroics and not headcount, but the discipline to reduce what a small, expert team has to carry. Get that right, and you recover the schedule by subtracting load — which, in this domain, is almost always faster than adding hands.
Speed in device development is a subtraction problem far more often than it is an addition problem.
LET’S TALK If your program is behind and the plan on the table is “staff up,” it may be worth a second look before you commit. Helping teams find the real constraint — and pull a late medical device program back in without paying the onboarding tax — is exactly the work MEDEVEX Consulting does, across design and manufacturing engineering, quality and regulatory compliance, and risk-driven program execution.