Skills & Roles

Overview

Skills & Roles covers what people must be good at once AI takes part in delivery. The work shifts from writing everything to specifying, verifying, orchestrating and judging, and that shift makes domain knowledge and review skill matter more, not less.

Every other discipline assumes a competent human at the gate: a reviewer who can spot a plausible but wrong change, an owner who can judge a generated specification, an approver with the authority to say no. This discipline makes sure those people exist, are trained for the tier of work they approve, and keep the judgement the organisation relies on as AI takes over more of the typing.

The eight ScaledAIOps roles are responsibilities, not necessarily new headcount. Most evolve from roles organisations already have, and small organisations combine several in one person.

What changes in existing practice

Key practices

Redefine the competency model

When AI drafts the code, the scarce skills are stating intent precisely, recognising when output is subtly wrong, knowing the domain well enough to challenge a confident answer, and deciding what must not be delegated. Write these into competency frameworks at every level, alongside the technical skills they build on.

Map the roles to responsibilities

Each role has a clear mission and evolves from work people already do. Assign them as responsibilities first; create a dedicated post only when the load justifies it.

A startup might give one lead engineer the orchestrator, context and platform responsibilities and ask a founder to act as governance officer. A bank will staff most roles separately. The responsibilities are the same; only the headcount differs.

Organise teams around the work

Stream-aligned teams own delivery with AI, including the outcome of every AI-assisted change. A platform team provides the AI-aware pipeline, the approved tools and the shared context those teams build on. An enabling team, led by the AI Adoption Lead, spreads practice by pairing with teams for a while and then stepping back. Governance works as a second-line partner: it sets the rules, assures that they are followed and is involved early, not only at the final gate.

Enable in proportion to tier and role

Everyone who uses AI tools gets baseline AI literacy: what the tools can and cannot do, the data boundaries, the tiers and how to record AI involvement. Depth then follows responsibility. Reviewers of high-tier work get deeper training on AI failure modes such as plausible but incorrect logic, invented dependencies, weakened security checks and tests that assert the wrong behaviour. Approvers of critical work hold a recorded competence check, renewed at a defined interval.

Protect skill formation

Judgement comes from having done the work. Early-career engineers need deliberate practice, including tasks and reviews done without AI assistance at times, so they learn to recognise good and bad solutions for themselves. Without it the organisation slowly loses the reviewers it depends on. Plan this into onboarding and rotations rather than leaving it to individual choice.

Recognise review and specification work

As AI generates more output, careful review and precise specification become the work that protects quality, yet they are easy to overlook in promotion cases. Make them visible in career paths, credit them in performance conversations and give senior engineers a path that grows through orchestration and judgement, not only through output.

Controls by risk tier

Maturity path

1. Ad hoc — people teach themselves; nobody knows who is competent to review AI-assisted work.
2. Experimenting — pilot teams share practice informally; some introductory training exists.
3. Managed — baseline AI literacy for all tool users; roles assigned as responsibilities; approval authority defined per tier.
4. Governed — training records and competence checks enforced at the approval gate; roles staffed; second line assures.
5. Optimised — enablement adjusted from review quality and incident data; career paths reward review and specification.

Assess your organisation →

Measures

• AI literacy coverage by role (target: everyone using AI tools)
• Qualified reviewers per team for high-tier work
• Time to proficiency for new joiners
• Review quality indicators: defects escaping review, sampled review depth
• Share of high and critical approvals made by people with a current competence check

Anti-patterns

• Usage as performance — rewarding prompts sent or code generated, which rewards volume over judgement.
• A new title per role — hiring for eight roles before anyone has done the work, instead of assigning responsibilities.
• Tool training only — teaching which buttons to press but not how AI output fails.
• Hollowed-out juniors — early-career engineers who never build the skill to judge what AI produces.
• Seniority as authority — approval rights assumed from job grade rather than recorded competence.

Regulatory anchors

The EU AI Act requires providers and deployers to take measures to ensure a sufficient level of AI literacy among their staff (Art. 4); baseline literacy and training records provide it. Deployers of high-risk systems must assign human oversight to people with the necessary competence, training and authority (Art. 26), which the tiered approval authority makes explicit. AI used to evaluate or monitor workers is high-risk (Annex III, point 4), so performance frameworks must not rely on AI-derived individual metrics. ISO/IEC 42001 requires determined competence and awareness for people doing work under the AI management system (clause 7); competence checks and training records are the documented evidence.

Related roles and principles

• AI Adoption Lead — leads the enabling team and spreads practice
• Engineering Orchestrator — models the specify, verify and judge way of working
• Context Engineer — turns team knowledge into shared, reviewed context
• Human accountability, always · Adopt incrementally