AI Adoption Is an Ops Problem, Not a Tools Problem

Think back to roughly 2014. Every product team had its own button. Its own blues. Its own dropdown with its own slightly-wrong focus state. The org’s best visual designers were doing world-class work — and it spread to exactly nobody, because there was no mechanism for it to spread. The fix was never “buy a better drawing tool.” Sketch didn’t fix it. Figma didn’t fix it. What fixed it was operational: a shared library, documentation, a contribution model, governance, and someone whose actual job was to run the thing.

Nathan Curtis gave that era its defining line:

If access were the constraint, the fix really would be procurement. It isn’t, and the studies are blunt about it.

Microsoft and LinkedIn’s 2024 Work Trend Index found that 75% of knowledge workers were already using generative AI at work — and 78% of those users were bringing their own tools rather than waiting for the company to provide them. More telling for us as leaders: 52% were reluctant to admit using AI on their most important work.

That’s 2024. It’s 2026, and using AI at work has finally been embraced. But at a high cost. What message in 2024 did we really send to the bleeding-edge ICs in our orgs?

Ethan Mollick has the best name for these people:

Here’s where I find the design-system metaphor stops being decoration and starts being a blueprint. Every piece of machinery we built to scale visual quality a decade ago has a one-to-one equivalent for scaling AI practice:

• The component library → a shared library of skills, workflows, and custom tools — versioned, documented, owned. Not a Slack channel where links go to die.
• Usage documentation (“when to use this component”) → frontier documentation: what this workflow is good for, where it fails, what still needs human judgment.
• The contribution model → a defined path for a designer’s private workflow to get reviewed, hardened, and published to everyone. AKA, where are the Figma comments in your workflow?
• Governance → the same centralized-vs-federated debate you already had about tokens, now about model choice, data handling, and review norms.
• The design system team → an owner. A person or small group whose job is the practice, not the tools.

This is squarely DesignOps territory. If “DesignOps” is new to you, Kate Kaplan defines it as, “the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale” (DesignOps 101, NN/g). Notice what’s not in that definition: tools. AI adoption at scale is a DesignOps program that happens to involve AI.

There’s one way the AI version of this problem is harder than the design-system version:

A button component either works or it doesn’t. AI capability has what Fabrizio Dell’Acqua, Mollick, and colleagues call a jagged frontier: tasks that look similar sit on opposite sides of an invisible line between “AI is superb at this” and “AI will confidently ruin this.” In their field experiment with 758 BCG consultants, people working inside the frontier finished about 12% more tasks, 25% faster, at roughly 40% higher rated quality. On a task deliberately designed to sit outside the frontier, AI users did measurably worse than colleagues with no AI at all. This gap will close as models improve, but still, in 2026, “You are here.”

For a multi-discipline org, this is the killer detail: the frontier is in a different place for every one of our disciplines. What’s inside the frontier for content design (first drafts, variant generation, tone adaptation) is nothing like what’s inside it for 3D (where topology and rigging remain largely outside) or for research (where synthesis assist is inside, and unsupervised insight generation is a liability). A single org-wide AI policy is exactly as useful as a single org-wide component would have been.

This is why standardization isn’t IT finger-wagging caution — it’s how you encode the frontier. A published, owned workflow says: this path has been walked, here’s where the cliff is. Every pod that improvises privately is re-mapping the same cliff edge, and some of them are finding it the hard way.

Mollick’s “Leadership, Lab, and Crowd” framework gives this a clean shape, and it translates directly into design-org language. The Crowd is your hundred designers discovering things — they need permission and incentives, not surveillance. The Lab is your ops function turning the Crowd’s discoveries into standard, documented practice. Leadership is you, thinking out loud what this means for how the org works. Most leaders I’ve talked to have an enthusiastic Crowd, no Lab, and a Leadership layer still comparing license costs.

The Lab is the missing piece. And the Lab’s first instrument should be a map of where each pod actually stands.

Averages will lie to you here. If I’d surveyed a large org the week of that budget review, I’d have gotten a mushy middle number and learned nothing. The signal isn’t the mean — it’s the spread. Somewhere you have a pod operating like it’s 2027 and a pod operating like it’s 2021, often in the same discipline, one floor apart. The distance between them is your distribution failure, made visible.

So here’s where you get your money’s worth for reading this far: a one-page self-assessment they can score in fifteen minutes. I’ve been calling it the Pod Score. Five dimensions, four levels each, scored 0-3. It borrows its logic from design-system maturity models and NN/g’s checklist approach — deliberately, because those instruments worked.

Score each dimension 0-3. One score per pod, from the pod lead. Total: 0-15.

How to read it:

• 0-4: Dark. Your risk isn’t under use — it’s invisible use. Start with amnesty.
• 5-8: Pockets. You have secret cyborgs and no Lab. Your leverage is capture and distribution.
• 9-12: Practice. Standardize and instrument. This is where measurement starts meaning something.
• 13-15: System. This pod should be teaching. Point its lead at your lowest-scoring pod in the same discipline.

Two rules that make this real. First, leads score their own pods — this is a self-assessment, not an audit, and the moment it smells like performance review the secret cyborgs go deeper underground. Second, you read it as a portfolio: plot all your pods, look at the spread within each discipline, and treat every large gap between similar pods as a distribution failure you own, not a talent failure they own.

Here’s the sequence I’d hand a design leader who wants to run this starting Monday.

1. Monday: send the Pod Score to every pod lead. Ask for scores by Thursday, with one sentence of evidence per dimension — the evidence sentence is what keeps a 2 from being an aspiration. Decision point: lead-scored vs. pod-wide survey. Lead-scored is faster and good enough for round one; add an anonymous pod-wide pulse in round two if you suspect leads are grading generously — most do, by about a point.

2. Tuesday: declare amnesty, in writing. One paragraph from you: personal-account experimentation to date is forgiven, showing your AI-assisted work will never be used against you, and discoveries that get adopted will be credited — visibly. This is from the Mollick playbook: people hide because policies read as lists of punishable offenses. Until you drain the fear, every other step runs on false data. Trade-off: legal and security will want caveats about data handling going forward. Give them the forward-looking rules; don’t let them make the amnesty retroactively conditional, or it isn’t one.

3. Wednesday: run a show-and-tell. One hour, each pod brings its best real workflow — the thing someone actually does, not a demo. Decision point: org-wide vs. per-discipline. At 100+ people, per-discipline. A content designer watching a 3D modeler workflow learns almost nothing transferable; the frontier is too different. You’re looking for the workflows your Pod Scores said existed — and the ones they didn’t mention.

4. Thursday–Friday: read the spread. Plot the scores. Find your highest and lowest pod in the same discipline and sit with both leads separately for thirty minutes each. The high pod tells you what’s possible in your org, with your constraints — which is worth ten conference talks about what’s possible in someone else’s.

5. Pick one workflow per discipline to standardize. Only one. Selection criteria, in order: it’s frequent (weekly-or-more work), it’s inside the frontier (a human can verify the output quickly), and it already has a proven owner — one of your surfaced cyborgs. Trade-off: the flashy workflow (generative hero imagery) will have more internal PR value than the boring one (research-synthesis first pass, UI copy variants, previz). Pick boring. Boring compounds weekly; flashy demos once.

6. Give the library an owner and treat it as a product. This is the Nathan Curtis move, and it’s where most efforts quietly die. A shared drive of prompts with no owner is a project — it ships once and rots. Decision point: dedicated role vs. rotating responsibility. Under ~30 designers, a fractional lead can carry it; at 100+, this is a real DesignOps mandate with real hours, or it will lose every priority fight for the next year. Their backlog: intake contributions, verify workflows against current models, maintain the “good for / bad for” docs, retire what breaks.

7. Instrument adoption, not licenses. Three numbers, monthly: how many pods use each standard workflow in real deliverables, how many contributions came in from pods, and the Pod Score spread. Note what’s not on the list: seat utilization, hours “saved” self-reported to one decimal place, prompt counts. Then re-score quarterly — models change fast enough that a Pod Score has a shelf life of about one quarter.

Everything referenced above, and what each is actually useful for:

• Co-Intelligence — Ethan Mollick — the best single book to hand a skeptical exec; its organizational chapters are the argument behind steps 2 and 3.
• Detecting the Secret Cyborgs — Ethan Mollick — the hidden-adoption problem and the incentive design that fixes it.
• Making AI Work: Leadership, Lab, and Crowd — Ethan Mollick — the org-design frame; map “Lab” onto your DesignOps function.
• DesignOps 101 — Kate Kaplan, NN/g — the canonical definition and framework; useful for positioning this work with your leadership peers.
• DesignOps Maturity: Low in Most Organizations — Kate Kaplan, NN/g — the 34-item checklist this article’s Pod Score borrows its self-assessment logic from.
• Anthropic Economic Index (and the September 2025 report) — real usage data; the task-concentration findings are your evidence that laissez-faire adoption stalls narrow.
• Navigating the Jagged Technological Frontier — Dell’Acqua et al. — the field experiment behind the frontier argument; cite it when someone asks why you’re “restricting” AI use to defined workflows.
• Microsoft & LinkedIn 2024 Work Trend Index — the BYOAI and hidden-use numbers for your next leadership deck.
• Figma 2025 AI Report — designer-specific adoption and trust data; the closest thing to a benchmark for design orgs specifically.
• A Design System Isn’t a Project — Nathan Curtis — the product-not-project argument you’ll re-run for your workflow library.