The AI Fluency Spectrum

TL;DR

• AI fluency has three meaningful stages: using AI to improve your own output, building systems others depend on, and redesigning how work happens at a team or org level. These aren't skill levels. They're different things with different requirements.
• The transitions between stages can be blocked by authority, permission and protected time, not just skill.
• Your trajectory matters more than your current position. Someone actively building their fluency is more valuable than someone who plateaued six months ago.

---

The AI fluency spectrum is a scope model. It describes whether someone's AI practice improves their own output, supports systems others depend on, or changes how a function operates. These stages complement the skill levels in the product competency model; they do not replace them.

A useful fluency assessment asks who benefits from the practice, not only how polished the individual interaction looks.

Three stages of AI fluency scope

Stage 1: Personal output

You use AI to work faster, produce higher-quality work, and handle tasks you couldn't previously do at scale. Your output improves. Your process changes. The team around you is largely unaffected.

Many people begin here. Personal productivity gains can be real and can compound. Someone who processes customer feedback with AI, generates prototypes faster, or writes cleaner documentation may produce better work when they also review the result.

Stage 1 evidence can be difficult to assess because the benefit is contained within one person's work. Look for a clear change in process, output quality, speed or task range rather than a list of tools used.

A useful test is whether the person can describe the previous process, the current process and where the improvement appears. Vague answers are weak evidence of changed practice.

Stage 2: Systems others depend on

You build things others use. A prompt library the team pulls from. A workflow that automates recurring work. An internal tool that surfaces insights teammates previously couldn't access. Templates, processes, documentation that embed your AI-developed methods into how others work.

This is the meaningful shift. Stage 2 requires the same skills as Stage 1, plus something different: the discipline to make your methods repeatable and the willingness to share them. A lot of Stage 1 work stays personal because it's faster to do it yourself than to document and scale it. Stage 2 demands the opposite instinct.

The evidence for Stage 2 is concrete: name the thing you built, describe who uses it, and explain the before/after. "I built a brief template that the team uses for every feature" is a Stage 2 claim. "I use AI to write better briefs" is Stage 1.

What Stage 2 operators actually do

The conceptual definition of Stage 2 is clean. The daily practice is less obvious, and it's where most people stall even after they technically understand the stage.

Useful Stage 2 practices include:

1. Deliberate comparison. They maintain working familiarity with adjacent tools or approaches when the comparison improves a real decision. Rotation is not the goal. Understanding what different systems reveal or hide about a problem is.

2. Prompt refactoring as routine. They treat a prompt like code they'll return to. The prompt library has a changelog. Failed outputs get traced back to the prompt, diagnosed, and fixed. The prompts that power shared artefacts (the brief template, the synthesis tool, the research agent) are improved on a rolling basis, not written once and forgotten.

3. Small experiments outside the scope of the current task. They run a lot of small tests that aren't connected to a shipping deadline. What happens when the output is asked for in a different format? What breaks when the prompt scales to 1,000 runs? The experiments aren't wasteful; they build the intuition that makes Stage 2 artefacts hold up under real use.

4. Sharing what works with the specific people who'll use it. Not mass-broadcasting on Slack. Handing the new prompt to the two people who'll actually adopt it, watching them use it, and iterating on their feedback. Stage 2 adoption is earned in small circles, not announced at all-hands.

These practices need protected work time. Without it, delivery pressure tends to displace the documentation, testing and adoption work required to make a personal method dependable for others.

Stage 2 also introduces accountability beyond your own work. When you build something others depend on, quality failures are no longer contained. A flawed prompt library scales flawed outputs, so the accountability principle matters more at Stage 2 than Stage 1.

Stage 3: Redesigning how work happens

You change the operating model. Not just how you or your team does existing work, but what work gets done, who does it, and what the function produces. Entire categories of work get automated or eliminated. New capabilities emerge that weren't possible before.

Stage 3 may change the capacity required for recurring operational work, compress a multi-day workflow, or shift a role from routine execution towards judgement and oversight. The evidence is a sustained change to the operating model, not a one-off efficiency gain.

The distinction from Stage 2 is that Stage 3 changes job descriptions, not just workflows. It requires permission to redesign, not just authority to build. That's why it's rare.

The transition blockers

Stage 1 to Stage 2

The transition requires skill, but time pressure, incentives and ownership can be larger barriers.

Documenting and scaling a method takes longer than using it yourself. Managers can make that investment possible by treating repeatability and adoption as part of the work rather than an optional addition to delivery.

Incentives can also discourage sharing. If recognition rewards individual output but not reusable systems, an effective method may remain personal. The builder-leader identity treats documentation, teaching and adoption as part of the contribution.

Stage 2 to Stage 3

This transition is primarily a permission problem, not a skill problem.

Redesigning how a function works requires authority over that function. It means changing processes other people depend on, which creates disruption even when the outcome is better. Most people who are capable of Stage 3 work haven't done it because the mandate was never explicit, the disruption risk felt too high, or there was nobody to authorise the change.

When strong AI practitioners remain at Stage 2, inspect their mandate as well as their skill. They may need permission to change a shared process, not another tool tutorial.

Proficiency levels within each stage

The scope stages describe who benefits from how you use AI. Proficiency describes how deeply you've internalised the tools within whichever scope stage you're operating at: how deliberately you reach for AI, how reliably you get useful output, and how well you evaluate results.

Neither dimension proves adoption. A workflow is adopted only when the intended group uses it repeatedly, reaches value, and can operate the change. The AI adoption operating model covers that organisational layer.

A useful way to think about proficiency:

Level 0: Sometimes uses AI tools. Hasn't changed any workflows. Treats AI as a fancier search engine or occasional draft generator.

Level 1: Has built something: a reusable instruction, a small workflow, or a shared template. Starting to see what is possible. Has not scaled it yet.

Level 2: Has automated part of their job and built something others depend on. The output is concrete, repeatable, and available beyond the original operator.

Level 3: Builds infrastructure that levels up others. Publishes skills. Creates platforms. Changes how their team or function works. These are Stage 3 scope people: force multipliers whose impact extends well beyond their own output.

The transitions between levels aren't primarily skill barriers. They're design problems.

Getting people from Level 0 to Level 1 requires low-friction tools. If someone has to configure a terminal, install dependencies, or request IT access before they see value, most won't reach Level 1. The tools need to meet people where they are: accessible without technical setup, connected to the data and systems they actually use, delivering a useful result on day one.

Getting people from Level 1 to Level 2 requires clear expectations and support. Where AI proficiency is relevant to the role, it should appear in performance conversations, hiring criteria, and onboarding. It is not an end in itself; it is part of doing the work well.

Match the mandate to the available tools and support. Raising expectations before people can reliably complete the work burns credibility. If Level 1 remains painful, a Level 2 requirement produces compliance theatre rather than useful adoption.

Getting people from Level 2 to Level 3 requires a stage. Systems builders need visibility, resources to build at team scale, and permission to redesign rather than merely improve. Give them a forum to share their work and peers who can challenge it.

Permission remains a common constraint at this transition. The work also needs a real audience. Without adoption, feedback, or organisational support, infrastructure that could improve a function remains an isolated side project.

Why trajectory matters more than where someone is now

Where someone sits on this spectrum at a single point in time is useful information. It's not the most useful information.

The more valuable signal is how fast they're moving and in what direction. Someone actively iterating their Stage 1 practices and starting to share methods with their team is doing something more valuable than someone who reached Stage 2 a year ago and hasn't touched their approach since.

The Zapier AI fluency rubric makes a similar distinction between current practice and trajectory. A static level is less informative than the evidence of what someone has learned, shared, and redesigned.

This matters for hiring and team development. A candidate who can describe an evolving arc, from what they tried to what they learned and changed, is demonstrating how they develop new capabilities. Assess the learning process and role-relevant evidence, not novelty for its own sake.

The same applies to teams. If their collective approach has not changed over a meaningful review period, inspect whether they are learning, sharing methods and improving systems. Tool usage alone does not demonstrate increasing fluency.

What this means for managers

A manager's personal AI fluency is a starting point, not the goal.

A manager with a well-developed Stage 2 practice and a team still constrained to Stage 1 has developed a personal skill, not a team capability. Any benefit from AI-native team design depends on shared methods, sufficient review, and reliable systems rather than one advanced operator.

Leadership fluency means moving your team along the spectrum, not just your own position on it. In practice, this requires:

Making the expectation explicit. "I expect everyone on the team to be actively developing their AI fluency" is a different statement than making AI tools available and hoping people use them. The first is a performance expectation. The second is an invitation.

Creating time for Stage 2 work. Building repeatable systems takes time. If the sprint is entirely full of product delivery, nobody will invest in the workflow improvements that compound. Protecting time for this isn't a nice-to-have; it's how you get teams off Stage 1.

Modelling the progression. The manager who shares what's working, documents their own methods, and openly iterates in front of the team is showing what progression looks like. The manager who uses AI quietly and never discusses it is not.

Removing blockers to Stage 3. If team members are capable of redesigning significant workflows and aren't doing it, the manager's job is to find out why. Usually it's permission, political risk, or time. Often it's all three.

Personal AI fluency is now a baseline for managers leading AI-enabled product work. Team fluency is the leadership outcome. The AI-native team design chapter covers the operating conditions, while taste covers the judgement layer that makes the capability useful. For individual development choices, use the career scenario framework to test which skills remain valuable across several plausible futures.