Which Technical Roles Need Retraining First?

Every technology and data leader rolling out an AI literacy programme eventually hits the same wall: there is not enough budget, time or delivery capacity to train every technical team at once.

Meanwhile, AI adoption inside technical teams rarely waits for a formal programme. Developers are already experimenting with AI coding assistants. Data engineers are already feeding pipelines into AI-assisted models. Some of this happens with governance. Much of it does not.

The question is not whether to train technical staff in AI literacy — that decision has effectively been made already. The question is which teams to train first, and on what basis that decision can be defended to a steering committee or a regulator.

This article sets out a practical way to answer that question.

Why sequencing, not scale, is the real problem

Most technology and data organisations in financial services now contain a dozen or more distinct technical disciplines: platform engineering, data engineering, application development, MLOps, quant development, compliance technology, risk technology, infrastructure, security, and more.

Training all of them simultaneously is rarely realistic. Delivery capacity is limited, and forcing a uniform rollout often produces shallow training that satisfies a tick-box requirement without changing behaviour.

The risk of delay is not neutral, however. While a programme is being designed, technical staff continue to adopt AI tools informally — inside code editors, inside data transformation scripts, inside third-party integrations. Every month of delay increases the gap between actual AI usage and governed AI usage.

This makes sequencing a risk decision, not just a scheduling one.

How technical training priorities have traditionally been set

In practice, most organisations default to one of three approaches when deciding which technical teams to train first.

The first is departmental request: whichever team asks loudest, or whose manager is most engaged, gets scheduled first. This rewards visibility rather than risk.

The second is project urgency: teams tied to an active, high-profile initiative are prioritised because training is bundled with a delivery deadline. This can work well when the initiative genuinely involves AI, but it often means teams with lower-profile but higher-risk exposure — such as data engineering or compliance technology — are left waiting.

The third is seniority or headcount: larger or more senior teams are trained first on the assumption that impact scales with size. This ignores the fact that a small compliance technology team configuring surveillance tooling may carry more consequence than a much larger general engineering team.

None of these approaches directly measures what actually matters: how exposed a team already is to AI tools, and how much operational or regulatory impact results if that exposure is left ungoverned.

A simple exposure-and-impact framework

A more defensible approach scores technical roles against two dimensions.

AI exposure — how directly the team already uses, builds, or depends on AI systems. This includes developers using AI coding assistants, data engineers whose pipelines feed AI-assisted decisioning, and model-adjacent roles such as MLOps engineers and quant developers.

Operational impact — the consequence if that exposure is misunderstood or ungoverned. This includes regulatory consequence, downstream data integrity risk, and consequence to control functions such as surveillance or reconciliation.

Plotting technical roles against these two dimensions consistently surfaces four categories worth prioritising first:

• Data engineers and pipeline owners, because poor data practices propagate directly into model risk downstream.
• Developers already using AI coding assistants, because this usage is often already happening without governance.
• Model-adjacent roles — MLOps engineers, quant developers, data scientists — because they sit closest to model behaviour and failure modes.
• Risk, compliance and audit technology teams, because misconfigured or misunderstood AI controls in surveillance, monitoring or reconciliation tooling can go undetected for long periods.

General infrastructure, platform support and less AI-adjacent engineering teams typically follow in a second wave, once the highest-exposure teams are trained.

Where AI-assisted assessment helps

Deciding exposure by guesswork or self-reported readiness is unreliable. Teams under time pressure often underreport informal AI usage, either because they are unaware it counts or because they are wary of scrutiny.

AI-assisted skills and usage audits can help build a more accurate exposure map. These tools can review code repositories, pipeline configurations and tool access logs to surface where AI assistants, third-party AI services or model-adjacent workflows are already in use — including usage that has not been formally declared.

This does not replace judgement. A steering committee still needs to weigh operational impact, regulatory context and business priority. But it replaces guesswork with evidence, which materially strengthens the case for why one team is trained before another.

Human oversight remains essential throughout. The output of an exposure audit should inform, not dictate, the final sequencing decision — particularly where a team's declared usage does not match its actual risk profile.

Example

A London-based clearing member's technology division is rolling out an AI literacy programme ahead of increased regulatory scrutiny on AI use in trade processing. The CTO must decide which of twelve technical teams to train first, given only enough budget for three teams in the initial quarter.

Using an exposure-and-impact assessment, the CTO prioritises the data engineering team, whose pipeline outputs feed AI-assisted reconciliation checks, the compliance technology team, who must understand AI limitations to properly configure surveillance alerts, and the developer team already using AI coding assistants informally.

General infrastructure engineering is deferred to the following quarter, with a clear rationale documented for the steering committee.

FAQs

• Should data scientists always be trained before software engineers?

  Not necessarily. Prioritisation depends on exposure and impact, not job title alone. Software engineers who are already using AI coding assistants in production systems may need governance-aware training just as urgently as data scientists working directly on models.

• What about technical roles in third-party or outsourced teams?

  Outsourced or vendor-managed technical teams that touch the firm's data or systems should be included in exposure mapping. Accountability for AI-related risk typically remains with the firm regardless of who performs the underlying technical work.

• How often should the prioritisation list be reviewed?

  A quarterly review cycle is a reasonable starting point. AI tool adoption within technical teams often moves faster than annual training planning cycles, so sequencing decisions can become outdated quickly if left unreviewed.