Time to productivity is a reasonable thing to measure and a bad thing to make one team accountable for. IT typically owns the number and controls perhaps the first few days of it, while the rest depends on a manager, a codebase and a set of relationships nobody can provision.
TL;DR
- Split the measure in two: time to working, which IT controls, and time to contributing, which it does not.
- Time to working is hours between a start time and first successful use of each core tool.
- Ticket resolution time is a misleading proxy, because the clock starts when somebody notices and reports.
- The gap between the two numbers is often three times larger than teams expect.
- A blocked starter rarely reports it, so the measure must come from asking rather than from tickets.
- Improving time to working past about a day has very little effect on anything downstream.
Two measures wearing one name
Time to working is the period between somebody starting and being able to operate: signed in, on a managed device, with access to the tools their role needs. It is measured in hours, it is almost entirely within IT’s control, and it is unambiguous.
Time to contributing is the period until the person produces something of value. It is measured in weeks, it depends on the complexity of the work, the quality of the manager, the state of the documentation and how willing the team is to be interrupted. IT influences the first few days of it and nothing after.
Reporting one number conflates the two and produces the familiar argument where IT is asked why onboarding is slow and can only answer about the first morning.
Measuring time to working honestly
The common proxy is ticket resolution time, and it is misleading for a specific reason: the clock starts when a ticket is raised, and a new starter raises a ticket well after the gap began to matter.
Someone who cannot access a tool on their first morning typically spends a few hours assuming they were not shown where it is, asks a colleague at lunch, and raises something the following day. A four hour resolution time is accurate and describes an interval that started eleven working hours after the problem did.
What to do:
- Define the core tool list per role, limited to what genuinely blocks work.
- Record first successful use of each, from system logs rather than from tickets.
- Start the clock at the contracted start time, not at first login.
- Report the slowest tool, not the average, since one blocker is enough.
- Ask every starter at day five what they could not do, and add what you find.
Reporting the slowest rather than the average matters more than it sounds. An average hides the one tool that took four days, and that one tool was the whole of the person’s experience.
A number that moved the wrong way for good reasons
A company of around ninety people measured onboarding by ticket resolution and reported a median under four hours. New starters were still routinely unproductive for two days.
Switching to hours between start time and first successful use of each core tool produced a figure of eleven working hours, driven almost entirely by one application that required a manual approval nobody had scheduled. The four hour number had been real and had been measuring the wrong interval the whole time.
Adding that application to the role template removed the approval step and brought the figure to under three hours. The reported number got worse before it got better, which needed explaining to people who had been reading the old one as a success.
The point of diminishing returns
Once time to working is reliably inside a day, further improvement has almost no effect on anything downstream. A starter who is operational by lunchtime on day one is not meaningfully held back relative to one who was ready at nine.
This matters because the pressure to keep improving a visible number does not stop when the number stops mattering. Effort that would move time to working from four hours to two is better spent on the parts of time to contributing that are genuinely slow, most of which are not IT’s to fix but are IT’s to surface.
Documentation quality is the usual candidate, and it is the one place the two measures touch.
Where the two measures meet
After the access problem is solved, the next constraint is usually that a new starter spends their second and third weeks asking questions that are already documented somewhere nobody can find.
Matram is our own product and it addresses that slice: it reads your documentation and answers in the channel people already use, which shortens the question cycle without anybody being interrupted. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only, so it will not provision access or shorten time to working at all. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. It affects the second measure and not the first, which is the distinction this whole article is about.
Splitting the number
| Measure | Unit | Owner | Good target |
|---|---|---|---|
| Time to working | Working hours | IT | Under one day |
| Slowest single tool | Working hours | IT | Under one day |
| Unreported blockers found at day five | Count | IT | Trending to zero |
| Time to first meaningful contribution | Weeks | Manager | Role dependent |
| Questions answered without a person | Share | Shared | Rising |
The checklist worth keeping
Checklist:
- Two separate measures, with separate owners, reported separately.
- Time to working measured from the start time, not from a ticket.
- The slowest tool reported rather than the average.
- A core tool list per role that excludes anything non blocking.
- A direct question at day five to catch unreported blockers.
- Effort redirected once time to working is reliably under a day.
Final Thoughts
Time to productivity is two numbers with different owners, different units and different levers, and reporting them as one produces an argument nobody can win. IT can be accountable for hours between a start time and a working setup, and should be. It cannot be accountable for how long it takes somebody to understand a codebase.
Split the measure, take the honest half, and stop optimising it once it is inside a day.
Frequently asked questions
What is time to productivity?
It is the period between somebody starting and becoming effective, which in practice covers two very different things. One is how long until they can operate their tools, measured in hours and controlled by IT. The other is how long until they produce something valuable, measured in weeks and controlled mostly by their manager and the work itself.
Why is ticket resolution time a bad proxy?
Because the clock starts when a ticket is raised, and a new starter usually raises one long after the problem began. They tend to assume a missing tool is their own misunderstanding, ask a colleague first, and report it the next day. The resolution figure is accurate about an interval that started many hours after the one you care about.
Should we report an average or the slowest tool?
The slowest, because one blocker is enough to stop somebody working and an average hides it. A starter with nine tools ready in an hour and one taking four days experienced a four day onboarding, and an averaged figure will describe that as a good result.
How do we catch problems nobody reported?
Ask a direct question at the end of the first week about what they could not do and did not mention. Open invitations to get in touch do not work at that stage, because the person cannot yet judge whether something is broken or normal. Expect reported blockers to rise once you start asking, since that is the measurement improving rather than the service declining.
How fast is fast enough?
Reliably inside one working day for every core tool. Past that point, further improvement has very little effect on when somebody actually becomes useful, and the effort is better spent on documentation quality or on the manager side of the second measure. Optimising a visible number past the point it matters is a common and expensive habit.
Can tooling shorten the second measure?
Partly. The share of the second measure spent hunting for already documented answers is real and addressable with better retrieval. The share spent understanding the work, the systems and the people is not, and no tool shortens it. Be clear which part a purchase is aimed at before claiming an effect on the headline figure.
