Map your organisation's AI capability in 90 days. Four competency layers, a phased process and what to do before hiring for the skills gap.
Link copied
Most organisations describing an AI skills gap have not measured one.
The complaint is usually genuine and the diagnosis is usually borrowed. Someone read that talent is scarce, looked at a stalled project, and concluded the two were connected. Sometimes they are. Often the project stalled for a different reason and the gap was never mapped.
Deloitte's State of AI in the Enterprise 2026 puts a figure on the real position. Only twenty per cent of organisations say their talent is highly prepared for broad AI adoption, and talent scores lowest of the five readiness dimensions measured. Strategy sits at forty-two per cent, technical infrastructure at forty-three, data management at forty and governance at thirty.
In the same period, worker access to AI tools grew from under forty per cent to around sixty per cent. Access roughly doubled. Readiness did not follow.
This piece sets out how to map your own position in ninety days, before you write a job advert.
Capability is not one thing, and treating it as one thing is why most training budgets underperform. Four distinct layers exist and each needs a different intervention.
Layer 1: User. Can use AI tools competently in their own work and knows when the output is unreliable. This is the widest layer and should cover most of the organisation.
Layer 2: Translator. Can look at a business problem and judge whether AI is the right instrument for it, then specify what would be needed. Sits between the business and the technical function. This layer is almost always the thinnest and the most valuable.
Layer 3: Architect. Can design the solution: data flow, model choice, integration points, failure modes. Technical, and genuinely scarce.
Layer 4: Enabler. Can spread capability through the organisation: teaches, sets standards, runs the internal community. Frequently overlooked because it does not map to an existing job title.
Most organisations start with a small User layer, a nearly empty Translator layer and no Enabler layer at all. The instinct is then to hire an Architect, which is the most expensive and least immediately useful of the four when the layers beneath are missing.
Do not survey people on whether they use AI. Ask what they produced with it.
Three inputs give a usable picture.
Output audit. Ask each team for two examples of work where AI was used in the past month, with a note on what the person changed in the output. The edits reveal the layer. Someone accepting output unchanged is not yet at User level regardless of how often they use the tool.
Problem inventory. Ask team leads for three recurring problems in their area. You are looking for Translator capability: who can already tell which of these three is an AI-shaped problem and which is not.
Tool reality check. Which tools are actually licensed, which are actually used, and where is the gap. Access data and usage data rarely match.
Thirty days is enough for this and longer usually adds precision without adding decisions.
The target is not "everyone should be AI-literate". That produces a training programme with no end state.
Set a number per layer. A workable starting shape for a mid-sized organisation: the majority of staff at User level, two to three Translators per major function, one or two Architects centrally, and a named Enabler group of five to ten people across the business.
The Translator number is the one that matters most and the one most often set too low. Deloitte's finding that the AI skills gap is the biggest barrier to integration points at this layer specifically: the shortage is rarely in people who can build, it is in people who can decide what should be built.
Gartner's projection that sixty per cent of AI projects unsupported by AI-ready data will be abandoned through 2026 points the same way. Someone has to be able to say, before the project starts, that the data required does not exist in a usable form. That is a Translator judgement.
Now the training decisions become straightforward, because each layer needs a different thing.
User layer: short, role-specific, repeated. Generic tool training does not transfer. A finance team and a marketing team need the same principles and different examples.
Translator layer: the highest-return investment and the slowest. It requires exposure to real business problems alongside enough technical understanding to judge feasibility. Usually developed rather than hired, because it needs knowledge of your business.
Architect layer: hire or contract, and be realistic that this market is competitive. Consider whether you need one permanently or need access to one periodically.
Enabler layer: identify rather than recruit. These people already exist in your organisation and are already answering colleagues' questions informally. Name the role, give it time allocation, and the community forms around it.
Deloitte's research found that education was the number one adjustment organisations made to talent strategy in response to AI. The finding is worth reading carefully: education, ahead of role redesign and ahead of hiring.
The reframe matters because it changes what you do on Monday.
A talent shortage is an external problem. It justifies waiting, budgeting for recruitment and blaming the market. A capability definition is an internal one. It produces a map, a target and a training plan, and it makes visible which of the four layers you are actually missing.
MIT Media Lab's 2025 study found that ninety-five per cent of enterprise AI pilots produced no measurable P&L impact, and attributed this to the learning gap and to enterprise integration that had not been built. Neither of those is solved by hiring. Both are solved by knowing which layer is thin and filling it deliberately.
Ninety days is enough to know. Most organisations have spent longer than that discussing the shortage.
Planning this for a Turkish audience? Read the Turkish version.
What to do this week:
1. Ask two teams for one piece of AI-assisted work each, with a note on what they changed in it. That single question starts the map.
2. Write down how many Translators you think you have by name. If the list is short, you have found your constraint.
3. Identify who in your organisation is already answering colleagues' AI questions informally. That is your Enabler layer, unnamed.
→ Enquire about an AI capability speaker or workshop
---
Adam Cheyer · Keynote Reel (YouTube)
Usually not first. An Architect is the most expensive layer and delivers least when the layers beneath are missing, because there is nobody to decide what should be built or to spread the result. Map the four layers before writing the job advert. In many organisations the binding constraint is the Translator layer, which is developed internally rather than hired.
Look at their edits rather than their usage. Someone who accepts AI output unchanged is not yet operating at User level, however frequently they use the tool. Someone who can look at three business problems and say which one is not an AI problem is showing Translator judgement. Output and reasoning are observable; self-reported confidence is not.
For mapping and planning, yes. Thirty days to see the current position, thirty to set targets per layer, thirty to build the plan. Building the capability itself takes considerably longer, particularly the Translator layer. The ninety days buys you a decision, not a finished workforce.
You almost certainly do have one, unnamed. There are people already answering colleagues' questions, sharing prompts and setting informal standards. The intervention is to name the role, allocate time to it and give it a small budget. Recruiting externally for this rarely works because the role depends on existing internal relationships.
Directly. Gartner projects that sixty per cent of AI projects unsupported by AI-ready data will be abandoned through 2026. Recognising that the required data does not exist in usable form, before the project starts, is a Translator judgement. A thin Translator layer shows up later as an abandoned project with a data explanation.
After Dinner Speakers
Contents
