Access Is Not Adoption

A few weeks ago I caught myself doing something that should have been impossible two years ago.

I was on a customer call, and while the conversation ran, I had an agent quietly driving my browser in another window, pulling a week's worth of reports, no clicking, no me. Earlier that morning a scheduled task had already dropped yesterday's metrics into my lap at 7:45. Later I'd ask another agent to read a new spec and write the test cases for it, and it would hand me back forty-five of them, cross-linked to a related spec by shared dependencies. None of this required me to write a line of code. Most of it required me to do nothing at all.

I'm not telling you this to brag. I'm telling you because of the uncomfortable thought that followed. I was one of only a handful of people at my company working anything like this. I'd been open about it the whole way, happy to show a colleague what I'd rigged up, forever experimenting out loud. And still, the way I worked hadn't really spread.

The ladder I climbed without noticing

When I trace how I got here, it isn't a story about better models. It's a story about better context.

• It started with ChatGPT for research and brainstorming, a brilliant stranger with no memory. I brought all the context, every single time.
• Then NotebookLM, loaded with our product documentation so the support team could troubleshoot customer questions on their own and lean on me less. That was my first taste of giving AI a managed body of knowledge to work from instead of starting cold, and the first time the leverage landed on someone other than me.
• Then a custom GPT pointed at one project's specific docs. That was my first real taste of retrievable AI, context that persisted and could be addressed. The model stopped being the point. What I fed it became the point.
• Today: Claude and Obsidian, running on something close to auto. My second brain is built on Andrej Karpathy's LLM-wiki pattern, the same architecture I wrote about in The CPO's New Reality, now pointed at two things: my job (a CPO wiki) and my life (a personal one).

Every rung on that ladder was a step up in context, not capability. The reason I'm fast isn't that I prompt better than my team. It's that I spent two years building the scaffolding underneath the prompt. The model was never my advantage. The harness was.

Which is exactly why "how do I get my team as productive as me?" turned out to be the wrong question.

The wrong question

The instinct, when you've found leverage, is to hand people your tool. Here's a login, go be 10x.

It doesn't work, and I have proof at both ends of the scale.

At my end: I set a north-star goal of fully automated bookings, with no human needing to step in. Months in, with the tools available to everyone, we were still stuck with a human touching roughly one in ten, and I found myself reviewing the exceptions one by one to understand why. The tools were never the constraint.

At a far bigger scale, Ramp told the same story. In We Built Every Employee at Ramp Their Own AI Coworker, Seb Goddijn writes that they hit 99% adoption of AI tools across the company, then noticed most people were stuck. So they built their own internal AI product, which they call Glass, to turn every employee into a power user without the configuration pain. Their diagnosis is perfect: "The models are good enough. The harness isn't." People were driving a Ferrari with the handbrake on.

That's the whole thing in one sentence. Access is not adoption. Giving everyone a model is not the same as making everyone effective. The gap between the two isn't technical. It's human, and it lives below the feature line, in the unglamorous territory of fear, ownership, and context.

Why people get stuck (it isn't the model)

Fear is the blocker, not capability. My slow adopters aren't lazy or unambitious. They're afraid of being wrong, and in real work wrong has consequences. A number that comes out off in a report someone sends to a customer. An edit that quietly breaks something and takes days to trace back. When the cost of a mistake is real, "just try the AI" is not the invitation it sounds like. Ramp names the same root cause: they had "created urgency without providing enough infrastructure." Pressure without scaffolding doesn't create adopters. It strands people.

So the leadership job isn't to force usage. It's to engineer low-stakes places to be wrong, and to start where a mistake costs nothing. Brainstorming, research, and first-draft design are fear-free zones. Anything that touches money or a live customer is not. You begin adoption where being wrong is cheap, not where it's catastrophic.

Adoption decays without an owner. Here's the part nobody admits: adoption isn't a launch, it's a maintained state. I've had to realign my team on a single critical automation three separate times. Each time we aligned. Each time it quietly reverted, not from disagreement, but because no one owned the heartbeat. It only held once I named one person accountable for it daily. Adopted-and-left-alone is just delayed un-adoption.

A demo is not adoption. I spent weeks on an AI voice agent to handle routine phone calls to vendors. In a demo it's magic. In live conditions it's brutal: an agent that goes off script the instant a human picks up, a model that says "press one" out loud instead of actually pressing it. So it sits behind a gate, fifty percent clean-call success before it touches the pipeline. We're at ten. It stays out. Enthusiasm that ships before it's gated doesn't become adoption. It becomes operational debt.

What actually moved the needle

Once I stopped trying to mandate AI and started trying to transmit it, three things worked.

1. Show the work, on a problem they already hate

Not "look what AI can do," but "look what AI just did to the thing you dread."

The one that turned the most heads was the wiki. I built a product wiki on the LLM-wiki pattern: every decision, account, and roadmap debate captured as linked notes that an agent keeps current. Now, instead of digging through old threads and documents to answer "wait, why did we decide this?", anyone can just ask the wiki and get an answer with its sources attached. The dreaded archaeology of institutional memory, gone. The colleague I showed it to didn't want a lecture on AI. They wanted their own wiki by the end of the call.

Then the writeups everyone hates. Drop in an hour-long meeting recording, get back a structured summary with decisions and action items, already filed where the team can find it. Then the blank page: a rough product idea turned into a working prototype in an afternoon, help-center articles drafted straight from product screenshots, usability feedback on a design before it ever reached a real user. None of it arrived as a mandate. All of it arrived as a "watch this."

Ramp found the identical thing: the people who got the most value "weren't the ones who attended training. They were the ones who installed a skill on day one and got a result." The result is the teacher.

2. Hand over context, not chatbots

The reason a teammate with ChatGPT open isn't 10x is that they're stuck on rung one of my ladder, re-feeding context every session. My real job, as the person who climbed it, is to build rung three for them: the shared knowledgebase, the project-specific custom GPT, the wiki their agent can read. Ramp's sharpest principle is this exact idea: "one person's breakthrough should become everyone's baseline." The failure mode was never that people couldn't figure it out. It's that everyone had to figure it out alone. Adoption compounds when context becomes shared infrastructure, not when everyone gets a login.

3. Wire it into who owns what

The one adoption that truly stuck was a rework of our QA process, and the idea wasn't even mine. Our CTO proposed it. My part was building the accountability in: developers now generate their own structured test reports with AI, and the lead audits them for completeness instead of re-running everything by hand. It wasn't "please use this tool." It became "this is how the job is done now." Adoption sticks when it's load-bearing, not optional. And it doesn't have to start with you. Some of the best adoption ideas will come from your team. Your job is to harden them into process.

You don't need to build Glass

Here's where my story diverges from Ramp's, and why I think it's more useful to most of you.

Ramp's answer, Glass, was to build a product: a full workspace, a marketplace of hundreds of shared, reviewed skills, a memory pipeline, an engineering team behind all of it. It's magnificent. And almost none of us can do it.

I don't have a platform team. My "AI coworker for everyone" isn't homegrown software. It's ChatGPT, NotebookLM, a few custom GPTs pointed at real workflows, and Claude with Obsidian on a borrowed wiki pattern. My version of Ramp's skills marketplace is a folder of markdown and a knowledgebase the team can query. Total platform engineering invested: zero.

So take Ramp's principle and shrink the implementation to fit your reality: raise the floor, don't lower the ceiling. The philosophy scales down beautifully. The build does not have to. You can start raising your floor this afternoon with tools you already pay for.

Why this is worth the unglamorous slog

None of this, the wiki, the named owners, the fear-free zones, the shared context, shows up in a changelog. It's all below the feature line. So why pour a product leader's scarce hours into it?

Because internal adoption is a rehearsal for the product you'll have to ship.

In a few years, the customer touching your product may not be a human at all. It may be their agent, calling your system. I've made that bet explicit in my own roadmap, and I've argued elsewhere that you should build the differentiation and buy the commodity. A team that's already fluent, support reasoning over a live knowledgebase, QA gating with evals, designers prototyping at the speed of thought, is a team that can build for that agent-first world, because it already lives there internally. The org that adopts AI inside first is the one that survives the agentic shift outside.

Transformation like this is never won at the summit, in the flashy demo. It's earned in the foothills, in the slow, deliberate work of raising one teammate's floor at a time.

I got fast with AI by my side. The harder, more valuable work is helping everyone else get there too. We don't lower the ceiling. We raise the floor, for everyone, at once.