Big bang: "let's buy 100 licenses"

The big-bang license purchase is the most common first move in enterprise AI adoption, and the most reliable predictor of failure. Leadership sees competitors adopting AI, attends a vendor demo, and makes a decision: buy 100 GitHub Copilot or Cursor licenses, send an announcement email, and declare that the organization is now "doing AI." The logic seems sound - get everyone access, let adoption happen naturally, measure results in a quarter.

What actually happens is a predictable arc. The announcement generates real enthusiasm. Early adopters start experimenting. A few developers have genuinely good experiences and share them in Slack. Then, quietly, usage drops. Developers who tried it a few times and didn't get value stop using it. The enthusiasts keep going, but they're a small minority. By month three, 80% of licenses are unused. By month six, the program is effectively dead - but the licenses are still being paid for.

The failure mode is not the tool. Modern AI coding assistants are genuinely powerful. The failure mode is the assumption that access equals adoption. Buying licenses solves the access problem. It does nothing about the workflow integration problem, the skill development problem, the social proof problem, or the measurement problem. Organizations that succeed at AI adoption treat it as a change management initiative, not a procurement exercise.

The "100 licenses" pattern also tends to buy the wrong thing for the stage. Organizations at L1 often purchase enterprise-tier tools with features that require L3-L4 maturity to use effectively - agent orchestration, custom context injection, team-level configuration. These features sit unused because the team hasn't built the foundational practices that make them valuable. You don't need a Ferrari to learn to drive.

• Wasted budget without foundation - license costs compound monthly while adoption flatlines; organizations spend $50-200K/year on tools that 20% of developers use sporadically
• Creates organizational cynicism - failed big-bang deployments make the next AI initiative harder; engineers who tried it and didn't get value become skeptics who slow future rollouts
• Misallocates the real cost - the tool license is 10% of the total cost of adoption; the other 90% is workflow integration, training, and organizational change - none of which a license purchase addresses
• Signals the wrong model to the organization - announcing "we bought AI tools" frames AI as a product rather than a capability, which shapes how engineers think about the investment required
• Delays the real work - every month spent on a stalled big-bang deployment is a month not spent building the structured adoption infrastructure that actually works

1. Resist the big-bang impulse - When pressure comes to "do something about AI," resist the urge to announce a broad rollout. Instead, frame the response as: "We're going to run a structured pilot with 2-3 teams to understand what actually works in our environment."
2. Buy a small number of licenses first - 10-15 licenses for a pilot cohort is enough to generate real signal. This limits downside if the first approach doesn't fit your stack, and forces the focused investment that makes pilots succeed.
3. Pair licenses with a champion - Every license in the pilot cohort should go to a developer who is paired with an internal champion (see the Internal Champion guide). Access without guidance produces the enthusiasm-to-shelfware arc.
4. Define success before buying - Before purchasing, write down what you will measure at 30, 60, and 90 days. "Developers feel good about it" is not a metric. PR throughput, time-to-first-green, and active usage rates are metrics.
5. Plan the rollout before the announcement - Don't announce broad availability until you have: training materials, a designated champion, a feedback channel, and a clear answer to "what should I use this for first."
6. Set a review gate - Commit in advance that at 90 days you will make a data-driven decision: expand, pivot, or stop. Having this gate makes the pilot credible and forces the measurement discipline that big-bang deployments skip.

Announcing before infrastructure is ready. Sending "we now have Copilot licenses available" before training materials, a champion, and onboarding documentation exist guarantees that early adopters will have a mediocre experience. First impressions in AI tools are sticky - developers who try it once and don't get value rarely try again.

Buying for the average developer instead of the early adopter. Big-bang purchases are often scoped to "everyone" to be fair. But the first 90 days of AI adoption should be scoped to the developers most likely to succeed - the ones who are already curious, already experimenting, already technically comfortable with new tools. Broad coverage dilutes the signal and buries the success stories.

Measuring adoption by license activation instead of active use. "95% of developers activated their account" is a vanity metric. The relevant metric is weekly active usage - how many developers are using the tool at least 3 times per week. License activation and actual use diverge dramatically in big-bang deployments.

No owner for the initiative. Big-bang deployments often have a sponsor (the VP who approved the budget) but no owner (the person responsible for driving adoption day-to-day). Without a named owner with time allocated to the program, the initiative operates on enthusiasm alone - which runs out by month two.

Treating the first tool as permanent. The AI tooling market is moving fast. The tool that makes sense at L1 may not be the right tool at L3. Big-bang deployments often create organizational lock-in that makes it hard to switch when better tools emerge. Pilot-based adoption preserves optionality.