DEV Community

pickuma
pickuma

Posted on • Originally published at pickuma.com

AI Adoption Without a Mandate: Rolling Out AI Tools When Leadership Isn't Pushing

No one sent the email. There's no AI task force, no line item, no OKR that reads "increase agent usage by Q4." There's you, a team where three people quietly keep a ChatGPT tab open, one person has loud opinions about it, and everyone else is waiting to see what happens to the first two groups.

That's the common case. Mandated rollouts get written about because they're loud, but most AI adoption inside a team starts as somebody's side project and either compounds or quietly dies inside a quarter.

Adopting without a mandate is a different problem from adopting with one. You are not managing resistance to a decision that's already been made. You are trying to produce enough evidence that a decision becomes obvious — while spending nothing you can't expense yourself, and breaking nothing anyone will notice.

What a mandate would have bought you

Name the things you're missing, so you can substitute for them deliberately instead of tripping over them six weeks in.

Budget. Most individual seats land in the $20–40/month range, which is inside the discretionary limit at a lot of companies and inside your own tolerance for a one-month test if it isn't. This is the least important missing piece and the one people fixate on first.

Security and legal clearance. This is the one that actually kills rollouts. Without a mandate, nobody has told you what data is allowed to leave the building, which means the default answer is conservative and unwritten. Don't ask for a general AI policy — you'll wait months. Ask one narrow question about one specific case ("can I paste stack traces from staging into a vendor with a zero-retention setting?") and get the answer in writing, in a channel other people can read.

A forcing function. Mandates make people try the thing at least once. Without one, first-week curiosity decays fast. Substitute by attaching the tool to something that already recurs — a weekly chore, a standing meeting, a step in your release checklist — so usage doesn't depend on anyone remembering to be interested.

Shared vocabulary. When leadership drives a rollout, everyone gets the same words. Without that, two engineers can argue past each other for an hour because one means autocomplete and the other means an agent with shell access.

What a mandate does not buy you is honest signal. Compliance usage tells you people can follow instructions. Voluntary usage tells you whether the thing is worth using. You already have the more valuable measurement instrument; you just have to point it at something.

Start with one workflow, not one tool

"Try Cursor" is not a task, and nobody has time to invent one for you. Tool-first rollouts stall at the point where a teammate installs the thing, opens their normal file, feels mildly annoyed, and closes it.

Pick a workflow instead. A good first candidate meets five conditions:

  • It recurs at least weekly, so you get repetitions inside a month.
  • It's boring. Nobody's professional identity is attached to it, so improving it doesn't read as an attack.
  • It produces an artifact somebody reads, so quality is visible without a metric.
  • It has a small blast radius — a bad output is embarrassing, not expensive.
  • You already know what good looks like, so you can grade the output in seconds.

Things that usually fit: drafting release notes from merged PRs, first-pass review comments on your own diffs before you request a human, turning a support thread into a reproducible issue, keeping a runbook current after an incident, writing the boring half of test fixtures.

Then measure, badly but honestly. Do the task by hand five times and write down the minutes. Do it with the tool five times and write down the minutes plus the time you spent fixing wrong output. That second number is the one a skeptic will ask for, and if you don't have it they will assume you're hiding it.

Before the first run, decide what data you will not paste. Consumer-tier accounts and personal API keys are the most common way a voluntary rollout turns into an incident — not because the vendor is careless, but because nobody agreed in advance whether customer records, production logs, or proprietary source could leave. Get one written yes or no for one specific data class, in a shared channel, before you have repetitions to defend.

Keep receipts a skeptic can't wave away

The output of an unmandated rollout is not usage. It's a document that makes the next decision cheap for somebody with more authority than you.

Keep a running log in a place your team already opens. Date, task, tool, minutes without, minutes with, what broke. Post it weekly whether or not the week went well. A log that contains only wins reads as advocacy and gets discounted at exactly the moment you need it to count.

Three properties make a log durable under pushback:

  1. Failures are in it, dated. "The agent rewrote a migration and I caught it in review" is more persuasive than three saved hours, because it proves you were looking.
  2. Costs are in dollars and hours. Seat price per person per month, plus the hours you personally spent setting it up. Rollouts get killed by unbudgeted maintenance nobody priced.
  3. Somebody other than you reproduced one result. One teammate repeating one workflow converts your log from a personal anecdote into a small, weak, real experiment.

The three ways it stalls

The enthusiast bottleneck. Only you get good output, because the skill lives in your head and your chat history. Fix it by moving configuration into the repo — an AGENTS.md, a rules file, a checked-in prompt for the release-notes job. If the setup can't survive you being on vacation, it isn't adoption yet.

The silent no. Someone senior is uneasy about the data question and hasn't said so, so your requests get slow-walked instead of refused. Raise it yourself, first, in writing. "Here's what we send, here's what we never send, here's the retention setting" turns an unspoken veto into a normal review.

Novelty decay. Usage spikes for ten days and then falls to nothing. That means the workflow wasn't painful enough to be worth the context switch. Don't respond by adding encouragement. Respond by picking a more annoying workflow.

If two workflows in a row decay, stop and say so out loud. A well-documented "we tried this on release notes and PR triage for six weeks and it saved less than it cost to maintain" is a genuinely useful artifact, and it buys you credibility for the next attempt. The teams that end up with real AI leverage are usually the ones that ran three small experiments and killed two, not the ones that waited for the email.


Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Top comments (0)