The Year I Helped Lead 700 People I Couldn’t Order Around
I was twenty-one, an intern, and one of four leads coordinating a twenty-four-person team that recruited and ran the 700 volunteers behind a world robotics championship in Mexico City. I had no title anyone respected, no budget to speak of, and no authority to make a single one of those people do anything.
Here’s the thing nobody tells you about volunteering: you have zero authority. The people you’re coordinating have full-time jobs or studies, and lives of their own. They’re there because they care. You can’t demand. You can only inspire, organize, and make it easy for good people to do good work.
That constraint turned out to be the most useful management education I ever got — because it’s the exact shape of the problem every organization now faces with AI. You have a powerful new capability, a workforce that’s busy and skeptical, and a strong temptation to force adoption from the top. And forcing it does not work. I want to explain why, and what works instead.
(This piece is about spreading the practice. If you want the practice itself, I’ve written about the shift it represents in From Vibe Coding to AI Engineering and the review discipline at its core in Review Is the Product. Here I’m answering the harder question: how do you get an organization to actually adopt any of it?)
Mandates Produce Compliance. They Don’t Produce Capability.
Walk into most AI rollouts, and you’ll find the same playbook: buy licenses, mandate usage, put a number on a dashboard counting how many people opened the tool. It feels like progress. It measures nothing that matters.
The predictable result is compliance theater. Engineers open the tool because they were told to, use it shallowly, route around it in practice, and the organization congratulates itself on an adoption metric while the actual capability — the ability to plan work an agent can execute and review what it produces — never develops. You get the appearance of transformation without the substance.
There’s real research behind this split, and it’s worth sitting with because it’s genuinely contradictory. GitHub’s own study of Copilot found developers finished a task 55% faster and reported feeling markedly more satisfied. Yet a separate study by Uplevel, tracking around 800 developers, found the ones using Copilot introduced 41% more bugs — with no real productivity gain to show for it. Both are true. The variable that reconciles them was never the tool. It was the practice around the tool — and practice doesn’t spread by decree.
The Two Roads
The organizational research I keep returning to is a study of two companies chasing the same goal through opposite leadership models. One cascaded the change top-down through annual planning and slowed under its own coordination weight. The other led it distributively — the authors call it “cultivate and coordinate,” creating space and support for initiatives to grow inside the teams doing the work — and that approach compounded faster against the goal.
The honest reading isn’t “distributed always wins.” It’s that a distributed posture compounds faster, because it works with the grain of how busy people actually change their behavior: not when they’re told to, but when a peer shows them something that makes their own week better.
That maps onto AI adoption exactly. My 700 volunteers didn’t move because I mandated anything. They moved because we gave them a clear frame, the tools to act, and the room to lead their own corner of it. Every engineer who picks up a planning habit, tries it on one real ticket, and shows the person next to them is doing more for adoption than any mandate ever will.
Engineers Adopt What Visibly Makes Their Week Better
Underneath the org chart, adoption runs on something simpler and more honest. Engineers are pragmatists. They pick up a tool the moment two things are true: it’s genuinely easy to use, and it visibly gives them something back — time freed, more shipped, a tedious thing made painless. Not promised value. Seen value.
And the fastest way to kill adoption is friction. If getting value out of the tool means a week of figuring out how it works, how to configure it, how to tweak it to fit the actual job, most engineers — already buried in deliverables — will quietly decide it isn’t worth it. And they’ll be right. The bar was never “is this powerful?” It’s “can I get value from this today, without a research project?” The more frictionless and embedded the tool is in the workflow they already have, the faster the buy-in.
This is why a demonstrated win beats a mandate every time. When an engineer watches a teammate finish in an afternoon something that used to eat two days — and sees that the teammate didn’t have to become an AI expert to do it — buy-in stops being a decision. It’s just obvious. The value sells itself, and it spreads sideways faster than any rollout plan could ever push it down.
It also tells the architecting and enabling leaders exactly what their job is: not to evangelize, but to remove friction. Make the good pattern the path of least resistance. Embed it where the work already happens. Take the effort out of understanding it. Every bit of friction you remove is a week of adoption you buy back — because the moment engineers see easy value, the buy-in takes care of itself.
Name the Three Roles — and Make Sure All Three Exist
If I could hand a manager one framework for this, it’s the idea that a nimble organization needs three distinct kinds of leadership present at once. It doesn’t need a single hero. It needs all three roles filled somewhere on the team:
- Architecting leadership designs the system that makes the work repeatable — the person who sits down and writes the planning template and the review checklist that the next hundred engineers will use. It’s high-leverage and thankless, because the architect rarely gets credit for the tickets that ship downstream. Under-invest here and you get a thousand engineers each privately solving the same problem. (That is precisely what’s happening across the industry with AI right now.)
- Enabling leadership supports the people doing the work — giving them time inside an overloaded sprint to learn the new practice, and air cover when a first attempt doesn’t ship. This is the manager’s real job in AI adoption, and it’s the one most managers currently skip in favor of watching a usage dashboard.
- Entrepreneurial leadership is the front-line engineer experimenting on a real ticket and bringing the lesson back. This is where most of the actual change happens, whether anyone calls it leadership or not.
Take any one of the three away, and the room produces nothing. The architect with no enabler never reaches the engineers. The enabler with no architect has nothing to spread. The entrepreneurs with neither reinvent the same wheel in isolation. Naming the three roles gives a manager three concrete behaviors to back on Monday morning instead of one fuzzy mandate to enforce.
The Shipping Unit Is No Longer the Individual
There’s a subtler shift underneath all of this, and it’s the one I think most adoption plans miss.
When we say “AI-assisted engineering,” we picture a single engineer and their agent. But the thing that actually ships a change is a small team crossing several boundaries: whoever holds the business intent, whoever knows the customer reality, the engineer who owns the system and carries the accountability, the agent doing the implementation, the reviewer holding the risk and compliance line, and the maintainer who will inherit every shortcut taken today.
A useful way to hold this is a three-part rhythm: explore — gather the context and intent from outside your own boundary before generating anything; exploit — the disciplined internal execution the agent accelerates; and export — push the learning back out to peer teams and the people downstream who’ll inherit the work. The engineer who treats AI as a solo productivity hack is doing exploitation with no exploration and no export — and is solving the wrong problem quickly. The throughput limit was never how fast one person types. It’s how well those roles coordinate across the boundaries between them.
This is also why “just take a short course on the tool” isn’t enough. The course teaches the solo relationship with the agent. The capability that moves an organization is learning to work across all three modes — and that’s a leadership problem, not a tooling one.
Don’t Wait for Perfect
One more principle, from a lecture that stuck with me: waiting for AI to be perfect before you adopt it isn’t caution — it’s a category error. The technology will never hold still long enough to perfect. The advantage goes to the organizations whose people are already practicing on real work, this sprint, with human verification designed into the workflow. Start where learning is already happening. Prefer stories over metrics when you teach people what “good” looks like. Ship an imperfect first cut and make the next one better.
That’s not recklessness. It’s the same lesson those 700 volunteers taught me, and the same one a low-income robotics team taught me years later when the team beating them stopped, mid-competition, to hand over spare parts so their rivals could finish. This work was never about the ranking. It was about building an environment where people help each other get better. Adoption is culture, and culture is human. The tool follows the people; it never leads them.
You cannot install a capability. You can only cultivate it — architect the patterns, enable the people, back the ones already experimenting, and measure the thing that actually matters. That’s the whole difference between an organization that mandated AI and one whose engineers got good at AI: the first is a slide, the second is a year of compounding advantage.
Measure adoption by the business value it ships, not by how many people opened the tool. Lead the change from where the work already happens.