You cannot talk someone into trusting a tool they’ve never used. I’ve watched leaders try — the all-hands, the polished deck, the ROI slide with the hockey-stick curve — and I’ve watched the room nod politely and go right back to doing the job the way they did it last year. Persuasion doesn’t create trust. Reps do. You believe the agent can refactor the module because you watched it refactor the module, disagreed with one call, fixed that one line, and shipped. That’s not an argument you can hand someone. It’s a thing they have to do with their own hands.
Which lands every leader rolling out agentic tooling on the same cliff: the value is real, it’s on the far side of a dozen frustrating reps, and almost nobody makes it across on their own. So how do you get an entire org to the far side?
You mandate it. And I know exactly how that sounds.
Trust is earned in reps, not slides
Start with the thing the deck can’t do. Belief that survives contact with a hard week doesn’t come from being told — it comes from having done it yourself. Psychologists have a stiff name for this — self-efficacy, the conviction you can pull something off, built almost entirely from having pulled it off before. Watching someone else do it barely moves the needle. Being told it’s possible moves it less. You have to accumulate your own evidence.
That’s why the standard playbook stalls. You run the demo, the agent does something genuinely slick, the room is impressed for about ninety minutes — and then Monday arrives with a real deadline and a task they know they can do by hand in twenty minutes, and they do it by hand. Of course they do. The hand-built way is a known quantity; the agent is a gamble that might eat an hour and spit out garbage. The first ten reps with these tools are often slower and more annoying than doing it yourself. The payoff is real and it is back-loaded — it shows up around rep thirty, once you’ve built the intuition for what to delegate and how to write the intent so the thing actually lands. (I covered writing that intent in leveraged time and lean on the tools.)
So the trough is structural. Cost up front, payoff later, and a perfectly rational human bailing at rep four. Left alone, most people never reach the part where the tool earns its trust — and then they conclude, from real experience, that it wasn’t worth it. They’re not wrong about their experience. They just quit the experiment one chapter before the twist.
The contrarian part: you mandate the reps
Here’s where I break with the change-management catechism. The gospel says you cannot mandate desire — push people toward a behavior and they push back on principle, dig in, do the opposite. Psychology calls it reactance, and it’s real; tell a person they must love the new tool and you’ve taught them to resent it. So the orthodox move is soft: make it available, evangelize, wait for organic pull, let the enthusiasts convert the skeptics.
That approach assumes the payoff is front-loaded — that if the tool were any good, people would feel it fast and adopt on their own. But we just established the opposite. When the value is back-loaded, “wait for organic pull” means waiting for a signal that only fires after the reps that people won’t do without a push. The soft playbook quietly guarantees the outcome it’s trying to avoid.
Everyday — a constraint that makes a behavior happen whether or not you feel like it — a door built to open only one way, so you can't push when you're supposed to pull.
In agentic development — a deliberate mandate that pushes people through the reps to the far side of the trust-trough, where the tool's value finally reveals itself. It is scaffolding — you put it up to get people to the evidence, and you take it down once they've earned the trust themselves.
And the frontier is already doing it — not quietly, either. In April 2025, Shopify CEO Tobi Lütke published an internal memo, later posted publicly, declaring that “reflexive AI usage is now a baseline expectation” at the company. Microsoft followed: in a memo reported that June, Julia Liuson, president of its Developer Division, wrote that “just like collaboration, data-driven thinking, and effective communication, using AI is no longer optional — it’s core to every role and every level,” and told managers to fold it into how they assess performance. And Coinbase’s Brian Armstrong went furthest — in a 2025 podcast interview with Stripe’s John Collison, he described giving engineers a one-week deadline to onboard onto Copilot and Cursor, then hosting a Saturday meeting for the holdouts, where some, he said, “got fired.” He called it heavy-handed himself. He also said it worked: Coinbase reported roughly a third of its code AI-generated and climbing.
Reasonable people can hate the Coinbase version — I’m not endorsing firing your way to adoption. But notice what all three are betting on: that the only way past a back-loaded payoff is to make the reps non-optional. That’s the forcing function. It’s contrarian, and it’s on-trend at the exact same time.
A naked mandate teaches people to hide
Now the load-bearing caveat, because the mandate alone is a loaded gun pointed at your own foot.
Reactance is real, and if all you do is issue the decree, you don’t get adoption — you get malicious compliance and shadow AI. People log the minimum usage to clear the bar, quietly route their real work around the tool, and stop telling you the truth about where it’s failing them. A mandate without cover doesn’t teach people to trust the tool. It teaches them to hide from you. And now you’re flying blind and resented.
So the sequence matters more than the mandate. Two things come first, before you require a single rep:
- The why, out loud and honest. Not “leadership decided.” The actual argument: the payoff is back-loaded, we know the first reps feel worse, we’re asking you through the trough because we’ve seen what’s on the other side. People will walk through fire for a reason and mutiny over a directive. Same ask, different outcome.
- Psychological safety, explicitly. Bad early output can’t be a performance ding, or people will hide it — and hidden failure is the one failure you can’t coach. Say it plainly: fumbling with the new tool is the expected state right now, and the only wrong move is pretending you’re fine when you’re stuck.
And then — this is the part orgs get wrong by sequencing it wrong — coaching runs concurrently with the mandate, not after it. Not “mandate now, we’ll set up enablement next quarter.” Concurrent. The day the requirement lands, the office hours, the pairing sessions, the prompt-and-intent workshops land with it. The mandate creates the reps; the coaching makes the reps count instead of curdling into thirty repetitions of the same frustration. One without the other fails. Whip with no map is cruelty; map with no whip is the soft playbook that never gets anyone moving.
Measure usage to help — not to punish
You do need to watch the numbers. Adoption data is how you coach at scale: who hasn’t logged in three weeks, whose usage is a mile wide and an inch deep, which team’s override rate says they’re rubber-stamping the model instead of reviewing it. That’s a heat map of where your people are stuck — and it tells you exactly whose desk to walk to. Usage data is a diagnostic for coaching, full stop.
The instant it becomes the scorecard, you’ve broken it — and this is where the whole series ties off. Back in measure the right thing the villain was Goodhart’s law: when a measure becomes a target, it ceases to be a good measure. Make “AI usage” the target and you’ll hit your number gloriously — people will pipe every trivial task through an agent to juice the metric, ship confident garbage they didn’t read, and the dashboard will glow while the codebase rots. You’ll have mandated the motion and gotten none of the value. It’s the exact same trap as rewarding tickets closed over problems solved, wearing a shinier hat.
So split the two cleanly, and let this be the line the whole series has been walking toward:
Usage tells you where to help. Outcomes tell you if it’s working.
Usage is the diagnostic — never the goal. The goal is outcomes: problems solved per unit of human attention, depth of adoption, a healthy override rate that proves people are still reviewing and not just accepting. Because the review is the work now, and an agent used without judgment isn’t leverage — it’s a faster way to be wrong. Measure the thing you actually want. Watch usage only to find the people who need a hand.
You can’t mandate what you won’t do yourself
Here’s the one that humbles the org chart: the mandate is void the second your leaders are exempt from it.
If the VP who signed the memo has never opened the tool, the whole thing reads as do as I say — and reactance eats it alive. But when a leader sits down in the shared session and says, out loud, “I don’t actually know if this’ll work, let’s find out together,” and then fumbles the first prompt in front of everyone — that’s the unlock. Not because it’s charming. Because it’s the same self-efficacy engine, run on the room instead of the individual: they’re watching someone they respect survive the trough, in public, without pretending to be past it. Modeled fallibility gives everyone else permission to be a beginner. And beginner is the correct state right now — this stuff is genuinely new, the person three desks over is faking their confidence too, and pretending otherwise is how you rot a team’s ability to learn. (Leading the change is the whole muscle here; the incongruent org is what breaks when leaders skip it.)
Then take the whip away
Now the part almost everyone forgets, and the part that makes the mandate defensible in the first place: you sunset it.
The forcing function is scaffolding, not architecture. Its entire job is to get people to the far side of the trough where the tool proves itself — and once it has, once usage is habitual and the trust is earned rather than ordered, keeping the mandate on is no longer a bridge. It’s a whip nobody needs, and it breeds exactly the resentment the soft playbook warned about. Name the off-ramp up front: “we’re requiring this until it’s second nature, and then we’re not.” That framing is the difference between “we’re forcing you across the bridge” and “we’re forcing you forever.” One is a mandate people forgive once they’re across. The other is the thing they mutiny over. When you take the scaffolding down and the building stands on its own, you’ve finally gotten what you actually wanted — not compliance, but a team that reaches for these tools because they decided the tools are worth reaching for. That’s the whole arc: you can’t tell them to trust it, so you engineer the conditions where they discover the trust themselves, and then you leave.
One more thing, and it’s the humility clause. Some of your resisters are scared, and the reps will fix that. But some of them are right. The senior engineer refusing to route a particular class of work through an agent may be handing you a real critique — a place the tool genuinely isn’t ready, a failure mode you haven’t priced in — dressed up as stubbornness. A forcing function is for the fear. It is not for steamrolling the person whose objection is a load-bearing observation. Mandate the reps; still listen to what the reps teach you. That’s how you avoid becoming the new caste system with a mandate stapled to it — and how you keep from turning your team into easy-bake-oven developers who push the button without ever learning what the button does.
What the whole series was actually about
Seven posts back I started with a hiring loop that measures a job that no longer exists — grading people on the code, when the code got cheap and the judgment got scarce. Every post since has been one turn of the same screw: the value moved up the stack, from execution to intent, from typing to reviewing, from doing the work to directing the work — and almost every institution we’ve built, the interview, the promotion ladder, the velocity dashboard, the change-management playbook, is still optimized for the world we just left.
The forcing function is where that finally becomes a leadership problem instead of a technical one. Because the whole shift depends on your people trusting a way of working they can’t trust until they’ve lived it — and you can’t hand them that trust, you can only build the ramp that gets them to earn it, then have the discipline to take the ramp down.
So here’s the question I’ll leave the whole series on — the one I don’t have a clean answer to yet, and the one that keeps me up: when you finally take the mandate away, are your people reaching for these tools because they’ve genuinely learned the judgment to wield them well — or just because they’ve gotten used to the button? Because those two look identical on the dashboard, and only one of them is the thing we were actually trying to build.
This is the finale of Leadership in the Agentic Era — seven posts on leading engineers through a shift that changed what the job is. Thanks for reading it through. The question above is a real one; if you’ve run a rollout like this, I’d genuinely like to know which side of it you landed on.
Comments