Rolling AI tools and AI features out across an organisation, measuring what changed, and keeping quality and risk in check.
5 questions in Executive & Engineering Leadership.
Write the AI usage policy around data classification, not tool names. Map each class of code and data to where it may go, approve tools only after legal and security confirm retention, training use, region and IP terms, give exceptions an owner and an expiry, and enforce with controls that assume people will paste.
Bring AI impact evidence in three labelled strengths: what moved against a baseline, what you observed but did not measure, and what you cannot attribute. Put spend and risk beside it. Refuse a productivity percentage, a headcount equivalent or survey hours times salary, and say when real evidence arrives.
Treat junior engineers as your future senior bench, not as cheap throughput. Size early-career hiring from the senior pipeline you will need, redesign the work so juniors still build judgement alongside AI coding assistants, hire for reading, debugging and review, and promote on diagnosis, not output.
Treat AI coding assistants as a practice change, not a licence purchase. Settle data policy and contract terms first, capture a baseline, pilot with contrasting teams, train people to review generated code, then expand in waves. Measure flow and stability against teams not yet switched on, not seat usage.
Require AI governance in proportion to risk. Apply risk tiering to what the output does, who sees it and whether errors reverse. Every tier needs a named owner, a tested kill switch and fallback, data rules and monitoring; higher tiers add pre-agreed evals, adversarial testing, human review and legal sign-off.