Ask a learning and development leader what happens to the training budget when finances tighten, and you'll usually get a knowing look. Training is often the first thing cut — not because it doesn't work, but because it's rarely measured in terms the business cares about.
The typical post-course survey asks whether participants enjoyed it. That's worth knowing, but it's a poor basis for a budget argument. A finance director wants to know what changed in the business and whether it was worth the cost. Here's how to answer that credibly.
Start with the question you want to answer
Measurement works backward from a business problem, not forward from a course catalog. Before choosing training, be able to finish this sentence: "We expect this to improve ___, and we'll know because ___ changes."
Weak: "Improve cloud skills." Better: "Reduce the time new engineers need to ship their first production change from 12 weeks to 8." Better still, add the metric's source: "…measured from our deployment records."
The four levels, applied to technical training
The Kirkpatrick model, a long-standing framework in the learning field, gives a useful structure:
Level 1 — Reaction. Did participants find it relevant and well delivered? Cheap to collect, but a weak predictor of impact. Use it to improve delivery, not to prove value.
Level 2 — Learning. Did skills or knowledge actually improve? In technical training, practical assessments beat quizzes: a lab the participant completes, a short build exercise, a before-and-after skills check. Compare against a baseline taken before the course.
Level 3 — Behavior. Are people applying it on the job? This is where most programs go dark. Check it 30 to 90 days later through manager observations, code review patterns, pipeline usage, or whether the practices taught actually appear in the team's work.
Level 4 — Results. Did a business metric move? Examples for technical teams:
| Training area | Plausible business metrics |
|---|---|
| Cloud and DevOps | Deployment frequency, lead time for changes, change failure rate, time to restore service |
| Cybersecurity | Phishing report rate, simulated-phish click rate, time to detect and contain incidents |
| Data and analytics | Report turnaround time, hours spent on manual reporting |
| Cost / FinOps | Cloud spend per unit of value, waste identified and removed |
| Onboarding | Time to first meaningful contribution |
| Certification programs | Pass rates, and rework or escalation rates afterward |
Set the baseline before the first session
This is the step most people skip, and it makes everything else impossible. If you didn't measure the metric before training, you can't claim it changed because of training. Capture it at least once — ideally across several weeks to smooth natural variation.
Be honest about attribution
Other things change while training happens: new tooling, new hires, seasonal load, a reorganization. To make your case credible:
- Use a comparison group where practical — a similar team trained later, or a team not yet trained.
- Look at the trend, not just two points. Was the metric already improving?
- Collect participant and manager estimates of how much of the change they attribute to training, and discount them conservatively.
- Say what you can't prove. An honest "this is consistent with training being a major factor" is stronger than an overclaimed number that falls apart under one question.
Calculating ROI
The standard formula, popularized in the learning field by the Phillips ROI methodology as an extension to the Kirkpatrick levels:
ROI (%) = (Net benefits ÷ Training costs) × 100
Net benefits = Monetary benefits − Training costsAn illustrative example — the figures are made up to show the arithmetic, not typical results:
Training cost (fees, time away from work, materials): $40,000
Hours of manual reporting eliminated per month: 60
Loaded cost per hour: $50
Annual monetary benefit (60 × $50 × 12): $36,000
Second-year benefit, assuming the habit holds: $36,000
Two-year benefit: $72,000
Net benefit: $72,000 − $40,000 = $32,000
ROI: 32,000 ÷ 40,000 × 100 = 80%Include the full cost: participants' time is usually the biggest line, and leaving it out flatters the result and invites challenge.
Not everything converts to dollars
Some benefits are real but hard to monetize: lower attrition risk, fewer security incidents that never happened, better collaboration. Report them as intangible benefits alongside the calculated ones rather than forcing a shaky number onto them. Credibility matters more than a larger figure.
Make measurement part of the design
The cheapest time to plan measurement is before the training is designed:
- Agree the business goal and metric with the sponsoring leader.
- Capture the baseline.
- Build practical assessments into the course, not just a feedback form.
- Schedule a follow-up at 30–90 days to check behavior and metrics.
- Report plainly: what was measured, what changed, what else might explain it, and what you'd adjust.
Why it's worth the effort
Measurement does two things. It protects the training budget when it's questioned, and it makes the training itself better, because you learn which parts of a program change behavior and which are just pleasant.
At NovuSpark we design programs with this in mind: clear outcomes up front, hands-on assessments, and follow-up. Learn more about our approach for organizations on our For Business page, see how we think about why programs fail in why AI training fails when it ignores workflows, or talk to us about a pilot with measurable goals built in.