The Team AI Map: How to See Your Org's AI Adoption in One Chart

Most organizations measure AI adoption the way they measure a software rollout: seats assigned, seats active, prompts per user, a line going up and to the right. It's the number that fits in a board slide, and it has one fatal property, it tells you the size of the gap without telling you the shape of it.

Two departments can post the identical 46% and be in completely different situations. In one, the active half is inventing genuinely new uses that never leave their laptops, and the inactive half is waiting for someone to show them a real example. In the other, half the team is quietly using AI ahead of policy, and the inactive half includes every person who would have caught the errors. Same chart. Opposite problems. Opposite next moves.

A team AI map is what you get when you stop counting usage and start plotting relationships, how each person actually relates to AI at work, and then look at the distribution across the group.

What the map plots

The underlying model is a typology, not a scale. Instead of ranking people from "bad at AI" to "good at AI," it measures seven factors (Creation, Crossover, Autonomy, Advocacy, Systemization, Verification, Engagement) and resolves them into 15 AI usage types. Every person lands somewhere with a main type and a second and third face, and the team map is simply everyone's results layered into one picture.

Read across the group and the picture sorts itself into a handful of clusters. The builders invent uses nobody asked for, remix tools into new combinations, or go unreasonably deep on a single use case. The systematizers turn other people's inventions into templates the rest of the company can run. The spreaders translate capability into someone else's job, curate which tool fits which problem, or provide the budget and air cover that let everyone else move. The steady adopters pick things up alone, or once shown, or by knowing exactly whom to ask. The guardians ask "source?" before anyone ships. And the edge cases, the person already using AI ahead of policy, and the one who says "looks useful" and never opens it, are usually the two groups your dashboard understands least.

No position on this map is the good one. That's the design, and it's what makes the data usable: a chart with no losing answer gets honest responses from the skeptics and non-users whose behavior your rollout actually depends on.

Reading the chart: it's about the holes

Once a team's distribution is in front of you, the interesting information is rarely where the bars are tall. It's where they're flat.

Builders with no systematizers. The most common shape in an enthusiastic team. Clever uses get invented every week and none of them survive contact with the next quarter, because nobody converts them into something repeatable. The org keeps paying the discovery cost over and over. What it needs isn't more experimentation; it's one person whose instinct is to write the template.

No verifiers anywhere. A team where nobody's first question is "what's the source?" is not a fast team. It's a team that hasn't found its first serious error yet. If the map shows this hole, the fix isn't a policy document. It's identifying who has the instinct and giving them the role explicitly, which is the entire argument of turning your loudest skeptic into your quality layer.

Everything concentrated in one or two people. The map makes key-person risk visible in a way usage counts never do. If the whole department's AI capability sits with two builders, an org chart change quietly deletes it.

A large quiet cluster. Dashboards read this as apathy and prescribe pressure, which reliably backfires. The map reads it as a group waiting for evidence from a person rather than a promise from a product, which points at a completely different intervention, usually a peer sitting down with them on their own task for five minutes.

Shadow adoption. People using AI ahead of policy show up as a cluster rather than an incident. That reframes the conversation from enforcement to catching the rules up to what is already happening.

What changes when you have the map

The practical value is that assignments stop being guesses. Who should pilot the next tool, the person whose profile is invention, not the person with the most seniority. Who should own the internal playbook, a systematizer, and the map tells you if you have one. Who should run the training, the spreader who translates into other people's jobs, who is very often not your most advanced user. Who should own quality gates, your verifier. And who needs nothing more than the rules clarified before they'll engage at all.

It also changes how you read your own numbers. A department at 46% with a healthy spread of builders, systematizers, and verifiers is in far better shape than one at 70% that is all enthusiasm and no quality layer. The distribution is the diagnosis; the usage rate is just a symptom.

How to run one without poisoning the data

Three conditions matter more than the tooling. Make it typological, not evaluative, the moment people believe a result can be scored against them, you get the answers they think you want, and the map becomes worthless precisely for the groups you most needed to see. Say plainly what it will and won't be used for: a sentence stating this is not an evaluation and won't feed into personnel decisions is not boilerplate, it's the thing that makes the non-users answer honestly. And include everyone, especially the people who don't use AI. A map built only from volunteers is a map of your enthusiasts, which you already had.

Then keep it cheap enough that people actually finish. Ours takes 24 questions and about four minutes, and there's a deliberate reason it's that short: the map is only as good as the participation rate, and the people least likely to finish a long survey are exactly the ones whose absence would skew it.

Re-run it a couple of times a year rather than once. A single map tells you your shape; two maps tell you whether anything you did actually moved it, and movement between types (a quiet abstainer becoming a learner, a critic becoming a verifier) is a far more meaningful signal of progress than a usage line ticking upward.

Start with your own square on the map

The fastest way to judge whether this is a useful lens for your organization is to take the assessment yourself and see whether the result describes something true about how you work. It's free, needs no signup, and takes about four minutes. If it lands, the team version is the same assessment distributed by code, layered into one distribution with the role gaps called out, that's what team assessments do.