Every downturn produces the same memo. Freeze external training, defer conferences, review all discretionary spend. I have written that memo. I have also sat on the receiving end of it, twice, and both times the argument I made to protect the budget was the wrong one.
The wrong argument sounds like this: people are our greatest asset, disengagement rises when we stop investing, competitors are pulling ahead. All true. None of it survives contact with a CFO who is trying to find eleven million rand by the end of the quarter.
The argument that works is narrower and colder. It names a specific operational exposure, attaches a number to it, and shows why the training line is the cheapest available control.
Supply-driven calendars are the root problem
Most corporate training still runs on a supply model. Someone assembles a catalogue in October, circulates it, collects nominations, and reports training days per employee at year end. It is easy to administer and almost entirely disconnected from what the business is trying to do.
I watched this play out at a large water utility. A post-incident review found that a shift supervisor had authorised work outside his competence. Corrective action: provide training. A course was booked, attendance recorded, action closed. Fourteen months later a near-identical event on a different shift. Nothing was wrong with the course. What was missing was any mechanism to turn attendance into authorisation, and any record of who was actually competent to make that call at 02:00 on a Sunday.
If your headline metric is training days delivered, you will hit it. You will hit it with whatever is easiest to schedule, which is rarely what is most needed.
Start with the failure, not the course
The organisations that hold their development spend through a squeeze have made one structural change. The conversation starts with an operational problem and works backwards.
A distribution licensee facing a retirement cliff among senior technicians did not commission a generic leadership programme. They mapped the specific judgement calls experienced technicians make under load — switching sequences, fault isolation, when to refuse an instruction — and identified which of those the next cohort could not yet make reliably. The programme that followed ran eighteen months: classroom modules, supervised switching, structured mentorship, formal authorisation at defined gates.
The success measure was not satisfaction scores. It was the number of technicians authorised to work unsupervised on defined equipment classes by a target date, against an attrition forecast. That number belonged to the operations director. When the budget review came, he defended it, not HR.
The evidence is already in your systems
You rarely need a new skills survey. You need to cross-reference what you already collect:
- Incident and near-miss reports coded by contributing factor, not only by outcome
- Repeat maintenance failures on the same asset class or by the same crew
- Audit findings — internal and external — that recur two years running
- Project post-mortems where the root cause was estimation, scope control or contract management rather than technical execution
- Exit interviews from mid-career technical staff, which are usually the most honest documents in the building
Skills surveys measure confidence. Failure data measures competence. They frequently point in opposite directions, and where they diverge is normally where your next incident is waiting.
Three mistakes that keep repeating
First, treating development as a reward. High performers get sent on programmes as recognition. The manager quietly generating grievances and turnover is left alone because that conversation is awkward. The spend flows to the people who need it least.
Second, designing for the classroom and ignoring the return. Adults retain what they apply within a fortnight. If a delegate comes back to a supervisor who does not know what they covered and has no interest in letting them practise it, the investment is gone in three weeks. A fifteen-minute pre-course briefing with the line manager and a mandatory application task afterwards costs nothing and changes the outcome materially.
Third, over-engineering measurement. I have seen teams spend nine months building an ROI model and evaluate nothing in the meantime. A rough estimate agreed with the business beforehand — we expect callout volumes on this asset class to drop by a fifth — is worth more than a precise calculation delivered after everyone has moved on.
What I would do differently
If I were rebuilding a learning function tomorrow, I would cut the catalogue by half and spend the freed time sitting in operational meetings. Not to present. To listen for the sentence that starts "we keep having the problem where…". That sentence is the brief. Everything else is administration.