AI widens performance gaps until teams copy what works
You buy generative AI licenses for three departments and wait for performance to even out across the company. Six months later, two people have rebuilt how they work and everyone else is still using a chat window to rewrite polite emails. When leadership asks what the rollout changed, you have a handful of isolated power users and no company-wide result you can stand behind.
GenAI does not automatically close skill gaps across a department. Left to individual experimentation, AI widens performance gaps until teams copy what works. Moving from isolated power-user habits to measured company results takes three operating choices: redesign real workflows instead of counting tool logins, verify what a local experiment actually changed, and put working initiatives in one company portfolio so other teams can reuse them.
Why a few self-taught users pull ahead
Leaders often expect GenAI to act as an equalizer. Give everyone the same assistant, and lower performers should catch up through ready-made templates and drafts. That happens in narrow, scripted tasks where software pushes a suggested reply onto a screen in the middle of a call.
It does not happen in jobs that bundle routine preparation with human judgment. In an October 2026 Harvard Business Review study of 236 sales professionals at Stripe and Checkr, alongside interviews with 8 revenue executives, Christopher Stanton, Justin Shriber, and Simon Rudat found that the biggest gains went to top performers. Managers assigned higher-value work to 44% of top-quartile reps after AI adoption, compared with 12% of bottom-quartile reps (survey-reported share). Managers were also 16 percentage points more likely to report quality improvements for top-quartile reps than for bottom-quartile ones.
The gap did not come from blind trust in the model, which had almost no link to reported gains. On a 1-to-5 scale, each 1-point step up in AI literacy was associated with a 0.71-point average increase in reported benefit (survey-reported rating). Literacy in that study meant something specific: the ability to choose tools, test competing outputs, spot errors, and decide when a human must stay in control.
Top performers act like self-taught builders. They do not wait for a training course or stop at faster note-taking. They use AI across an entire workflow to pressure-test strategy, rehearse difficult objections, or prototype a local helper over a weekend. In a typical 250-person company (illustrative), that creates a quiet trap: your two sharpest people invent a better way to work on Friday, keep it in their personal bookmarks, and leave the rest of the department working the old way on Monday.
Stop asking who uses AI and start redesigning the work
Most AI programs react to uneven adoption by counting prompts, tracking weekly logins, or asking job candidates whether they use GenAI. Vendor usage telemetry only tells you a license was opened. It never tells you whether the workflow improved.
If you want to find people who will move a metric, ask how they learn and where they draw the line. Ask a candidate or a team lead to walk through a workflow they rebuilt, an AI output they rejected because it was wrong, or a customer step where they refused to use AI because the context was too sensitive. One revenue leader quoted in the 2026 Harvard Business Review study asks candidates to share the exact AI session they used to prepare for the interview.
The same logic applies to entry-level roles that feed your senior talent pipeline. When a role mixes repetitive research with judgment—such as initial prospect research, first-line ticket triage, or invoice exception checks—handing out chat licenses without changing the job leaves people doing the same manual steps slightly faster. Automating the role away entirely breaks the training ground that produces next year’s specialists.
In the HBR study, Brex took a more deliberate path with its entry-level sales development role. It automated 20% to 40% of repetitive manual prospecting (company-reported range) and redesigned the role so ambitious reps used the freed time to run full-cycle deals against a clear promotion threshold. The team did not start from a generic idea list; it looked at the steps people already ran, separated routine preparation from human judgment, and changed the workflow. Map the work before you brainstorm the AI.
Generic tools stall without local workflow context
Self-taught power users can only go as far as the context they can reach. When employees have to copy and paste across six disconnected places—ticket queues, spreadsheets, call transcripts, chat threads, and folder trees—only the most persistent tinkerers bother connecting them.
That is why the build-versus-buy decision inside an AI program is really a question about local context. When a task is generic and the market tool is mature, such as recording calls or extracting standard meeting notes, buying off the shelf works. Where generic tools stall is the step that depends on your company’s own definitions, segment rules, and process documents.
Leaders at Stripe, Brex, and Vercel interviewed in the 2026 Harvard Business Review study drew the same boundary: off-the-shelf tools handle generic extraction, while differentiated performance depends on structured company context and domain logic. For a Head of AI or Transformation Director in a 300-person organization (illustrative), that does not mean hiring an engineering team to build custom models. It means grounding every workflow opportunity in the process documents and notes a department already has, and agreeing how the change will be measured before anyone builds.
A demo is not adoption. A clever weekend prototype only becomes a company asset when a team runs it on real work, measures it against a baseline recorded before the change, and has a result owner confirm the outcome.
Decentralize discovery, centralize the record, and copy what works
Once you recognize that practitioners inside departments spot better workflow opportunities than a central committee ever will, you face an operating choice. What belongs to the departments, and what belongs to the central program?
If you centralize everything, discovery slows down and produces generic catalogs that teams ignore. If you decentralize everything, four departments quietly build the same helper, definitions conflict, stale notes produce wrong answers, and nobody can prove what changed. The programs that turn individual experiments into durable results split the responsibility cleanly.
| Program layer | Department responsibility (decentralized) | Shared program standard (centralized) |
|---|---|---|
| Finding work | Map recurring workflows, friction, and local process documents | Keep one company portfolio where promoted initiatives are visible to all teams |
| Testing ideas | Prototype local helpers, test prompts, and run peer show-and-tells | Set data guardrails, approved context, and rules for when a human stays in control |
| Proving results | Run the changed workflow on real work over a defined period | Require one measurement plan per experiment: baseline, after figure, source, and result owner |
| Spreading wins | Adapt another team’s working initiative to local department rules | Retire duplicate tools and keep workflow metrics separate from business outcomes |
Consider how this works in an illustrative 30-person support team. A team lead builds a ticket-investigation helper grounded in the department’s troubleshooting notes. Before rolling it out to the rest of Support, the Department Head locks a measurement plan: one workflow metric, ticket analysis time, against a baseline of 45 minutes per ticket recorded from June helpdesk records. After a month of adoption across the team, analysis time moves from 45 → 15 minutes per ticket in July (measured workflow metric, High evidence confidence), confirmed by the Head of Support as result owner. That 30-minute reduction is reported as a workflow metric, never multiplied by an hourly wage and dressed up as euro cost reduction.
Copy what already works.
Because the initiative lives in one company portfolio rather than on one person’s laptop, the Head of Finance sees it the following week. Finance copies the initiative to adapt it for invoice-exception checks. The copy starts as a new idea with Support credited as the source, and Finance agrees its own baseline and its own result owner rather than inheriting Support’s verified result.
What to do on Monday
- Interview your two strongest power users about one workflow, not their favorite prompts. Spend 20 minutes mapping the exact steps they changed, the local process documents they rely on, and the checks they run by hand before trusting the output.
- Put a measurement gate between a local prototype and a team rollout. Before you ask the rest of a department to adopt a power user’s tool, record one metric, the baseline before the change, the comparison period, and the result owner accountable for confirming the after figure.
- Publish every active initiative in one shared view across departments. Give Department Heads one place to see what other teams have already tested and verified, copy what fits their own work as a new initiative, and retire duplicate experiments.
You do not need every employee to invent AI workflows on a weekend. Copy what already works.
HardTally gives your program one place to map a department’s real workflows, see every initiative running across the company, and record before-and-after results confirmed by their owners. If your best AI experiments currently live in personal bookmarks, start with one team’s work: Map AI opportunities in one department, free.
Evidence note Based on: Christopher Stanton, Justin Shriber, and Simon Rudat, “What Top Performers Do Differently with AI—and Why They See the Biggest Benefits”, Harvard Business Review (2026), and practitioner experience. Illustrative: the 250-person and 300-person organization scenarios, and the 30-person support and finance workflow example (45 → 15 minutes per ticket). Confidence: Medium, one multi-company research study combined with practitioner experience.