Building a Quality Floor: Making AI Foundational (Not Optional)

We've seen it happen: deploy the right tools properly and the early adopters get real benefit within weeks, project managers suddenly able to monitor hundreds of work orders knowing the edge cases won't slip through, engineers answering technical questions in minutes instead of hours.

But the pattern that follows is just as consistent: the value pools with the most technically capable people and stays there. The tools become something power users love, and the rest of the organization keeps working the way it always has. And that means realizing what the technology can actually do requires running two efforts at once. There's a sprint, deploying tools against clear, high-value processes where the payoff arrives in weeks. And there's a marathon, bringing everyone along until these capabilities are as expected and unremarkable as having a computer on your desk. The sprint proves the value and pays for the effort. The marathon is what makes it permanent.

What actually changes

Start with the sprint, because it's what makes the rest worth doing.

A manufacturer already operating at 99.5% accuracy, an excellent track record, implements automated daily checks across all active work orders. Now the edge cases that used to slip through, the long-lead part that didn't get ordered on schedule, the labor allocation that doesn't match the plan, get flagged before they become program delays. The operation has instrumented a process that no amount of human diligence could sustain at that volume.

Technical questions change the same way. Questions like "What's the mating connector?" or "Is this part temperature-rated?" used to queue up behind a small engineering team. With the right tools they get answered in seconds with a verifiable source attached, which means sales can handle a technical question during a customer call and purchasing can check an alternate part before ordering, and the engineering team's time shifts from routine lookups to the complex judgment calls that actually need them. And work that used to take hours or days, comparing purchase order versions, extracting a BOM from a drawing, now happens in minutes, because the first pass is automated and the human's job becomes review and decision.

We see this working in production environments right now. But everything above describes what happens for the people who lean in, and most people don't lean in on their own.

The quality floor

In any team, performance follows a distribution. Your best people produce excellent work, and at the other end there are people whose output is inconsistent in ways that create rework. That's normal, and exhortation doesn't change it.

What properly deployed tools change is the bottom of that distribution. When the basic questions get asked by the system every morning whether or not anyone remembers, and when answers arrive with sources attached even if the person asking isn't an expert, your weakest performers can't fall below a certain standard, because the tools won't let them. None of this replaces anyone. The floor itself moves, and a floor changes what the organization as a whole can be trusted to do, which is a different and more valuable claim than making your best people faster.

That framing also explains why universal adoption matters so much. A quality floor with holes in it, the three people who never touched the tools, isn't a floor.

The computer parallel

When personal computers entered the workplace, there was resistance. People had been doing their jobs successfully for decades without them. But the machines could do things nobody could argue with, editing a document without retyping it, recalculating an entire spreadsheet in seconds, and the economy responded with massive investment in making PC literacy universal, for everyone, because organizations where everyone could use a computer had a durable advantage over organizations where only some people could.

My read is that AI is at a similar point. The early adopters are already experiencing what it does. The work in front of most organizations is bringing everyone else along, and that's a different kind of work from deploying technology.

One hour with someone's real work

There's educational research from the 1980s, Bloom's "2-Sigma Problem," showing that one-on-one tutoring produces about two standard deviations better learning outcomes than group instruction. We see the same pattern with these tools: people who have ignored them for months become daily users after a single 30-60 minute session where someone sits with them and works on their actual work, their real tasks, with them at the keyboard.

The session looks like this. You ask, "What are you working on right now?" They say, "I need to update three customers about delayed deliveries and draft a production summary for management." So you do the first one together: they describe the situation and the model drafts the email; they edit it and send it. Ninety seconds instead of ten minutes. And then comes the question we hear over and over: "Wait, it can just do this? For any email?"

That's the moment. The tool stops being a special thing for special tasks and becomes useful for a normal Tuesday, and once that clicks, people start finding applications on their own.

Different parts of the team need different things to get there. Your early adopters, maybe 10-20% of the team, are already moving; give them the advanced capabilities and learn from what they discover, because they're your proof points. The middle 60-70% need to see value in their own specific work, which is exactly what the one-on-one session delivers, and the aha moment almost always lands on something mundane like drafting an email rather than on anything that sounds like AI. The cautious or resistant 10-20% respond to peer validation and mostly nothing else; when a trusted colleague mentions catching an issue before it became a problem, that moves them in a way no executive memo can.

Which is why the rollouts that work have an internal champion, someone trusted who becomes the guide. Usually it's an engineer or a project manager with relationships across the organization, someone who uses the tools daily themselves, dedicating 20-30% of their time to enablement for two or three months. They run the one-on-one sessions on people's real work, show each role its first win, hold office hours for questions, share successes in team channels, and connect people who have similar use cases.

This works because it's peer-to-peer. People trust a colleague's judgment about what helps in their environment far more than they trust a memo from above, and a respected peer saying "this caught an issue for me last week" carries the kind of evidence a rollout plan can't manufacture.

Design choices that make it feel normal

Product design carries a lot of the marathon, and we've learned to be deliberate about a few things. The start screen should open with role-specific prompts people can click, "Draft difficult email" or "Check work order status," because a blank box asks the user to already know what the tool is for. Anything that works should be saveable as a template, so "draft overdue order follow-up" becomes a one-click pattern. The capability should show up where the work already happens: a draft button in Outlook if that's where they write, a "summarize this work order" option inside the ERP if that's where they live. And when the tool cites a datasheet or a spec, opening the source has to be one click, because trust comes from fast verification, and the quality floor depends on answers that carry their evidence with them.

Measurement can stay simple. Weekly active users by role tells you whether you're bringing the whole organization along or just serving power users. Time to first value tells you whether your onboarding works. For the sprint-track tools, watch the process itself, whether issues are getting caught earlier and review time is coming down. And watch for self-sufficiency, people finding new uses and helping each other, because that's the marathon being won.

A four-week start

1. Week one: pick the two or three processes where a tool can deliver a clear, fast win, and build or deploy there first.
2. Week two: define the role-specific first win for each role, and put those on the start screen as one-click prompts.
3. Weeks three and four: the enablement blitz. Your champion runs 30-60 minute sessions with everyone, on their real work, with a follow-up scheduled.
4. From then on, run both tracks: keep pushing capability with the early adopters, and keep bringing more people to basic fluency.

You'll know it's working from the texture of an ordinary week. New hires pick the tools up from peers during onboarding without anyone scheduling it. Tips get shared in team channels unprompted. Questions shift from "how do I" to "can it also," and someone mentions in passing that they asked the AI about it yesterday. Eventually you stop tracking adoption, because it stopped being a program and became how work gets done. That's the marathon finished, or as finished as it gets.