Upskilling Your IT Staff and Management for Private Investment

The question that goes badly

In diligence, the technology questions that damage a process are almost never about capability. The system works; that is observable. The question that goes badly is the follow-up: who decided that, on what basis, and what happens when they are not here?

When the answer requires fetching one person from another meeting, an investor learns something no architecture diagram will offset. They are not assessing the stack; they are assessing whether it is governable by anyone other than its author.

Key-person risk is a legibility problem, not a headcount problem

The instinctive response to key-person risk is to hire. That is slow, expensive and misses the point: the risk is not that one person does the work, but that the work exists only in their head and is therefore untransferable.

Untransferable knowledge is discounted for a straightforward reason: it cannot be scaled, cannot be covered, and can walk out in the period when continuity matters most. The remedy is legibility. Run-books written by the operator, not a contractor. Decision records that include the discarded options, because the discards are what a successor needs. Cross-cover where a second person has genuinely done the task rather than been shown it.

Legibility is cheaper than hiring and achievable on a diligence timeline. Hiring usually is not.

What investors are testing in management is framing, not fluency

There is a persistent misreading that leadership teams need technical fluency before an investment process. They do not. What they need is to explain technology spend in the language of the business: which spend protects revenue, which reduces cost, which reduces risk, and which is optional this year.

The distinction changes what upskilling should contain. A managing director who can say why the integration programme is sequenced ahead of the reporting programme, and what is being accepted by doing so, will hold a room. One who can name the technologies but not the trade-off will not, and no technical course closes that gap.

Practise it as it will be tested: an unscripted challenge from someone with no attachment to the plan.

The direction nobody upskills in

Upskilling programmes run one way: teach the managers about technology. The reverse direction is rarer and often produces more, because it changes decisions taken daily rather than quarterly.

A technical team that understands gross margin by channel, the cost of a day’s delay at month-end, or which customers carry contractual penalties will prioritise differently without being told to. Prioritisation improves when the person doing the work can estimate its value, and degrades when they cannot, not through indifference but because in the absence of value information people optimise for what they can see, which is effort or noise.

The counter-argument: upskilling is often the wrong instrument

Training is the default answer to a capability gap and regularly the wrong one. The honest question is which kind of gap you have. A knowledge gap responds to training in weeks. A skill gap responds to deliberate practice over months. A judgement gap (knowing which risks are worth taking, having seen a migration fail before) responds only to experience, and cannot be manufactured inside a transaction timetable.

Where the gap is judgement and the deadline is fixed, the realistic options are to bring in seniority (a hire, or fractional technology leadership), or to declare the constraint openly and manage it. A named constraint with a plan reads far better than a capability claim that dissolves under a second question.

The corollary, plainly: do not use a training programme to avoid a conversation about seniority.

Evidence is a product, and products decay

Businesses preparing for investment build a data room. The process concludes and within two quarters the roadmap is out of date, the risk register has not moved and the control evidence has gone stale, which is the condition the next raise, refinancing or exit will find it in.

The alternative is to make the artefacts operational rather than presentational. A roadmap genuinely used to sequence work stays current because people rely on it, and a risk register reviewed monthly, where risks are closed or accepted by name, stays current for the same reason. Control evidence generated as a by-product needs no assembly at all.

The test is simple: could you produce the pack in a day, from what the business already does? If producing it requires a project, it will be out of date again by the time it is needed.

What changes after the money arrives

Investment readiness is treated as a finish line. It is closer to a change of operating rhythm: reporting cadence tightens, month-end assembled by hand becomes untenable, and technology decisions acquire an audience with a defined holding period and a firm view about when value must appear.

If the plan involves acquisitions, a further capability is needed before the first deal: running diligence on someone else’s systems, deciding what integrates and what is left alone, and standing up a Day 1 that breaks neither business. That is a different skill from running your own estate, better built in advance than during the first transaction. Both patterns are familiar to private equity-backed businesses, and both are foreseeable.

A workable sequence

Attempting everything at once produces documentation nobody maintains. A sequence that survives a real timetable tends to run in this order.

• Make the estate legible first (systems, owners, suppliers, dependencies), since everything else references it.
• Record decisions from today onward, discarded options included. Reconstructing historic ones adds little; explaining the last six months does not.
• Give the technical team commercial context before giving managers technical training. It changes more decisions per pound.
• Rehearse the difficult questions with someone who has no stake in the answers.
• Address judgement gaps by bringing in seniority, not by scheduling a course.

The objective is not a team that performs well in diligence, but one that runs the business well enough that diligence is uneventful: the only version that still holds afterwards.