Every spring, an engineering manager receives a stack of training requests. One engineer wants a cloud certification, another wants a conference ticket, a third asks for a hands-on Kubernetes course, and the security team needs a mandatory refresher. The budget covers maybe half of it. The usual response is a negotiation conducted by email, in which the loudest or most senior request wins and everyone else feels vaguely shortchanged. A more defensible approach is to audit the requests against a short, written list of obligatory needs, label the remainder as optional, and keep the evidence for each decision. This checklist shows how to do that in a single working session.
The aim is analytical rather than diplomatic: every approval and every deferral should be explainable with a sentence and a source. If you can do that, regret falls, because people can see the logic even when they disagree with the outcome.
Before you start: gather the inputs
Allow about two hours and invite one person from finance or operations to sit in, because an outside reader is the quickest way to spot a vague justification.
Collect four documents, and do not begin scoring until you have all of them.
- The full list of requests, each with requester, cost and proposed date.
- The team’s delivery commitments for the coming two quarters.
- Any compliance or customer obligations that reference skills or certifications.
- The remaining training budget, stated as a ceiling, not an aspiration.
Part A: identify the obligatory needs
An obligatory need is a training request whose absence would create a concrete problem within the planning window. Work through the following checks for each row. Record a yes or no, and note the evidence next to it.
- Is the training required by a contract, regulation or customer audit? Evidence: the clause or the audit finding.
- Is a named delivery commitment blocked without it? Evidence: the project plan line and the skill gap, stated in one sentence.
- Is there a single-person dependency that this training removes? Evidence: the incident or handover record that exposed it.
- Does a platform change scheduled within two quarters make the skill necessary? Evidence: the roadmap item and its date.
Any row that scores yes on at least one check goes to the obligatory column. Everything else goes to the optional column. Resist the urge to add a fifth check about “strategic value”; that phrase is a wish in formal clothing.
Calibration test
If more than about a third of the requests land in the obligatory column, your checks are probably too loose. Re-read each yes and ask whether the evidence would convince a sceptical colleague. Weak evidence moves the row to optional. It is common for first-time audits to over-classify, and the fix is cheap.
Part B: rank the optional column
Optional items are not rejected. They are ranked, and they act as tie-breakers when budget remains or when two options both satisfy the obligatory checks. Use three measurable attributes.
- Reach: how many people will benefit directly, counted rather than guessed.
- Time to use: weeks between finishing the training and applying it on real work.
- Cost per learner: total cost divided by participants.
Rank on those three, break any remaining ties by the requester’s own stated priority, and publish the order. A visible ranking turns a “no” into a “not yet, and here is where you stand”.
Part C: check the credential requests separately
Certification requests deserve their own pass, because they mix an obligatory component, such as a customer requirement, with a personal-development component. Two readings from our archive can help you frame them: a practical look at what holding a DevOps credential tends to deliver, and an overview of credentials suited to different career stages. Neither replaces the evidence from your own team; they only help you ask better questions about it.
- Is the credential demanded by a client or auditor, yes or no?
- If not, does the syllabus match a skill gap recorded in Part A?
- Is an exam date proposed that conflicts with a delivery milestone?
Part D: sanity-check against an outside example
The pattern of “fixed needs first, comparisons later” is not unique to engineering. Educational websites for international patients, such as BestCardiacHospitals, which sets out a staged way for overseas patients to compare care options, state that their content is informational and not medical advice. The structural lesson, not the subject matter, is what transfers to your audit: no comparison is meaningful until the conditions that cannot move have been written down.
A short illustration with six requests
Suppose six requests arrive. Two cite a customer audit that names a security qualification, so they pass check one. A third supports a database migration scheduled for next quarter and passes check four. A fourth removes the only-one-person-knows problem exposed by last month’s outage and passes check three. The remaining two, a conference trip and a general leadership course, pass nothing, so they enter the optional ranking. Four obligatory, two optional: two thirds, which is high enough to trigger the calibration test. Each yes here carries a citable source, though, so the result stands, and the manager notes that the conference trip can resurface next cycle if budget remains and its ranking holds.
Part E: document and publish
Produce a one-page summary containing: the obligatory list with evidence, the ranked optional list, the budget ceiling, and the date of the next review. Send it to every requester at the same time. Equal timing matters; staggered communication invites lobbying.
What to record for each row
- Request and requester.
- Column (obligatory or optional) with the single strongest piece of evidence.
- Decision: approved, deferred to the next cycle, or declined with reason.
- Review date, so deferred items resurface automatically.
Part F: review after the cycle
The value of an audit depends on what happens once the quarter closes. After the quarter ends, look back and ask three questions with data attached.
- Did any obligatory item turn out to be a wish? Note which check misled you.
- Did any deferred item cause a visible problem? If so, which check should have caught it?
- Were any requesters surprised by the outcome? Surprise indicates that the criteria were not communicated early enough.
Adjust the four checks accordingly. Over two or three cycles the list stabilises, and the quarterly negotiation shrinks from a week of emails to an hour of reading.
Limits of the method
This checklist is deliberately conservative. It favours demonstrable needs over potential, and it can undervalue exploratory learning whose benefits are hard to evidence. To compensate, many teams reserve a small, fixed share of the budget for self-directed learning that bypasses the audit entirely. Decide that share in advance, state it openly, and keep it modest, so the audit still governs the majority of spending.
Run the checklist once on last year’s approved requests as a dry run. Comparing what you actually funded with what the audit would have chosen is the quickest way to see how much of the old process was driven by noise.