Time-to-fill tells you when a seat was filled. Time to Contribution tells you when the hire started delivering. Here’s how to measure it and shorten it.
The Wrong Number on the Board Slide
Every quarter, engineering leaders report hiring progress to the board. The slide usually shows the same things. Roles opened. Roles filled. Average time-to-fill.
It looks like progress. It tells you almost nothing about whether your hiring is working.
Time-to-fill measures how fast a seat gets filled. It stops counting on the day an offer is accepted. But the business doesn’t care when the seat was filled. The business cares when the new engineer started shipping work the team relies on.
Those two dates sit months apart. And the gap between them is where most of the real cost of hiring hides.
A fast-filled seat with a four-month ramp is a worse outcome than a slightly slower search producing a three-week ramp. Yet most companies optimise for the first and never measure the second.
There’s a better metric. We call it Time to Contribution.
This article covers:
- What Time to Contribution means and how it differs from time-to-fill
- Why the gap between the two costs more than most CTOs realise
- Why healthtech ramps run longer, and what to do about it
- The five drivers of fast contribution
- How to measure it and report it to your board
What Is Time to Contribution?
Time to Contribution (TTC) is the time between a hire’s start date and their first piece of meaningful, independently shipped work.
Not “onboarded.” Not “up to speed.” Not “attended all the induction sessions.”
Contributing. Something the team now relies on, which the new hire built and shipped without someone holding their hand.
Examples of a real first contribution:
- A backend engineer ships a production feature end to end
- A platform engineer owns and resolves a production incident
- An integration engineer delivers a working connection to a client’s EHR
- A staff engineer drives an architecture decision the team adopts
SHRM uses a similar idea for time to productivity, defining it as the number of days until a new hire reaches the performance indicators set for the position. TTC applies this thinking to engineering, with a sharper finish line. The first independent, meaningful piece of shipped work.
TTC doesn’t replace full productivity as a measure. It’s an early signal. If the first contribution arrives fast, full productivity usually follows. If it doesn’t, something is wrong, and you want to know at week six, not month six.
Why Time-to-Fill Misleads You
Time-to-fill is easy to measure, so everyone measures it.
The benchmarks are well known. Gem’s data shows average time to hire rose from 33 days in 2021 to 41 days in 2024. Leaders fight hard to bring this number down. They should.
But look at what happens after the offer is signed.
A study from Pluralsight Flow found the average time to fully ramp a new engineer was six months. The Linux Foundation found something similar. Employers reported an average of 4.8 months for a technical hire to reach normal productivity, and 58% of 321 respondents said it took more than four months.
Put those numbers side by side:
- Around 6 weeks to get the engineer in the door
- Around 5 to 6 months for them to reach full productivity
The hiring process is the smaller problem. The ramp is the bigger one.
Here’s an illustration of the cost. As of June 2025, the average salary for new engineering hires on Carta was about $189,000. That’s roughly $15,750 per month. A six-month ramp at partial productivity burns tens of thousands of dollars in salary before the engineer performs at full strength. And this ignores the senior engineers’ time spent reviewing, explaining and unblocking.
Cut two months from your ramp and you save more than you’d save by cutting two weeks from your search.
The Two Camps of Engineering Teams
The most useful finding in the Pluralsight Flow research wasn’t the average. It was the split.
Although the average ramp was six months, companies fell into two camps: those where typical time-to-productivity was three to four months, and those where it took 11 to 12 months.
Same industry. Same talent pool. Similar engineers. One group gets new hires to full speed three times faster than the other.
The difference wasn’t talent. The companies with the fastest time to productivity used strategies like peer shadowing, pair programming and scaling task complexity over time. The researchers’ biggest takeaway was simple: “the better companies planned, the more successful their onboarding was.”
Other data points to the same problem. One Microsoft study found 24% of new hires in one engineering group completed no pull request in their first 90 days. Three months in, with nothing shipped.
This is the core argument for TTC. Contribution speed is mostly a product of how your company prepares, not who you hired. Which means it’s within your control.
Why Healthtech Ramps Run Longer
Healthtech adds a layer most generic onboarding plans ignore.
A new engineer at a healthtech startup has to learn the codebase, the team and the product, like anyone else. They also have to learn:
- HIPAA rules and how they shape data access in your system
- How your product connects to EHRs, and the quirks of each integration
- Clinical workflows and why clinicians behave the way they do
- Your security and audit requirements, often driven by enterprise customers
One healthtech recruiting firm estimates most strong engineers learn HIPAA requirements in two to three weeks. The bigger cost is the wider domain ramp. The same firm notes healthtech engineers show longer tenure than average once they clear the domain ramp, which typically takes four to six months.
Read that carefully. Healthtech engineers stay longer once they’re through the ramp. So the ramp is an investment worth protecting. But four to six months is a long time to wait for full value from a $189,000 hire.
The fix is not hiring only engineers with years of healthtech experience. That shrinks your pool and slows your search. The fix is planning the domain ramp as deliberately as you plan the technical one.
Compliance onboarding is the most common silent delay. Access approvals, security training and data handling sign-offs stack up in the first weeks. If nobody plans them before day one, a new engineer spends their first fortnight waiting for permissions instead of building.
The Five Drivers of Fast Contribution
Teams with short TTC tend to get five things right. Most of them happen before the new hire’s first day.
1. A clear 90-day problem, defined before the search starts
If the hiring team can’t say what the new hire should have solved by day 90, the new hire won’t know either. They’ll spend weeks working out what “done” looks like.
Define the problem first. Then write the spec, run the search and plan onboarding around it. The same sentence guides all three.
2. Seniority matched to the ambiguity of the role
A senior engineer dropped into an under-specified environment with no support will ramp slowly, regardless of skill. A mid-level engineer placed in a role full of ambiguity will struggle too.
Match the hire to the environment. Ask how much direction this person will receive in their first month. Then hire for the answer.
3. A named owner for onboarding
“The team will help them settle in” is not a plan. One person owns the new hire’s first 90 days. They schedule the introductions, review the first pull requests and remove blockers.
Asana built its approach around buddies, who run learning sessions on the codebase, architecture and testing framework during a new hire’s first few weeks.
4. A first task shipped in week one
Small, real and in production. The goal is momentum and confidence, not a big feature.
Some teams set this bar high. Asana has a rule for all new engineers to “ship something on their first day.” Gergely Orosz of The Pragmatic Engineer calls shipping production code in the first week “one of the best signs of a good onboarding process.” He adds it usually means a robust CI/CD system and guardrails to catch regressions are in place.
5. Compliance onboarding planned before day one
For healthtech teams, this is the one most often missed. Before the start date:
- Request system access and approvals
- Schedule HIPAA and security training for week one
- Prepare a written guide to how your product handles patient data
- Line up a session with someone who knows your clinical workflows
Every day saved here is a day the new engineer spends building.
The Warning Signs of Slow Contribution
Watch for these patterns. Each one points to a TTC problem you’re able to fix.
- No shipped work by week four. The first task was too big, too vague or blocked.
- The new hire keeps asking what to work on. The 90-day problem was never defined.
- Senior engineers complain about interruptions. Onboarding has no single owner, so everyone becomes the owner.
- Access issues dominate the first fortnight. Compliance onboarding wasn’t planned.
- The hire is technically strong but makes slow progress. The seniority or ambiguity match is off.
- Job specs keep getting vaguer as the team grows. Leadership is losing clarity on what each hire is for.
None of these signs mean you made a bad hire. Most mean the environment around the hire needs work.
How to Measure Time to Contribution
You don’t need new software to start. You need a definition and a habit.
Step 1: Define the contribution milestone for each role
Before the search starts, agree what a first meaningful contribution looks like for this specific role. Write it down. Keep it concrete.
- “Ships a production feature without pairing support”
- “Owns and closes an on-call incident”
- “Delivers a working FHIR integration to staging”
Step 2: Record two dates
The start date and the date the milestone is met. The gap is your TTC.
Step 3: Check in at 30, 60 and 90 days
Review progress against the milestone. If the hire is off track at day 30, find out why while there’s still time to fix it.
Step 4: Run a short retrospective on every hire
What sped this hire up? What slowed them down? Feed the answers into your next spec and onboarding plan.
Step 5: Track the trend
One hire tells you little. Ten hires tell you whether your hiring system is improving.
How to Report It to Your Board
Add TTC next to time-to-fill on your next board slide. Present them together:
- Time-to-fill: how fast you found the person
- Time to Contribution: how fast the person started delivering
Then tell the story the numbers reveal. If time-to-fill is fast and TTC is slow, your problem sits in role definition or onboarding. If both are slow, start with the spec. If both are fast, your hiring system is working, and you have the data to prove it.
Boards respond to this framing because it connects hiring to output. Headcount growth means little on its own. A team doubling engineering headcount is not necessarily doubling its capability. TTC shows whether new hires are adding capability, and how fast.
Measure What the Business Cares About
Time-to-fill matters. A slow search loses strong candidates and delays your roadmap.
But it’s half the picture. The real measure of a hire is how fast they start delivering work the team relies on. Companies tracking only time-to-fill are optimising the shorter half of the timeline and ignoring the longer one.
The teams winning the healthtech hiring race do three things:
- They define the 90-day problem before the search starts
- They plan onboarding, including compliance, before the start date
- They measure Time to Contribution and use it to improve every hire
Start with your next hire. Define the milestone. Record the dates. Review the result.
Want hires who contribute faster? Synaxia Group places senior software and product engineers into healthtech, medtech and biotech startups. We start every search by defining the 90-day problem with you, so the right engineer joins knowing what success looks like from day one. Get in touch with Synaxia Group to scope your next engineering hire.