The 60-90 Day Plan Nobody Gives You When AI Adoption Goes Wide
For the leader who has a handful of teams using AI well and twenty teams wondering when it is their turn.
The message arrived on a Wednesday morning.
“We need to scale this. Leadership wants all 20 teams on AI tooling by end of quarter.”
I had seen this moment coming. The early adopter teams had been running for three months. The metrics were moving. A few people were genuinely excited. And now the machine wanted to replicate it everywhere, at speed, without asking whether everywhere was ready.
I put my coffee down and looked at the screen for a moment.
This is the part nobody writes the playbook for.
Not the early adoption. Not the proof of concept. The moment between “it works for a few” and “it works for everyone” is where most AI rollouts quietly fall apart. Not dramatically. Quietly. Teams adopt the tools without the foundations to use them well. Metrics get created that measure activity instead of outcomes. Engineers who were genuinely curious become people going through motions. The culture of experimentation that produced the early wins gets replaced by a mandate to demonstrate compliance.
This post is the playbook I wish someone had handed me.
Not a consultancy document. Not a framework with sixteen boxes. The actual sequence of decisions, in the order they need to happen, with the reasoning behind each one.
Start With What Good Actually Looks Like
Before you do anything else, before you send a single calendar invite or set up a single training session, you need to answer one question clearly.
What does success actually look like?
This sounds obvious. It never gets done properly.
What usually happens is that someone decides success looks like adoption. Percentage of teams using the tools. Number of AI-assisted commits. Completion rate on training modules. These are measurable. They are also almost entirely useless as indicators of whether anything valuable is happening.
Go and sit with the one or two teams that are already using AI and genuinely seeing results. Not the teams who report using it. The ones where something is actually different. Ask them specific questions. What changed in how you work? What are you doing now that you were not doing before? Has your PR cycle time moved? Are you catching more bugs before production or fewer? Are you able to move through legacy code faster?
The answers will be specific and often surprising. You will probably find that the value is not where you expected it. It is usually not the headline use case. It is something more mundane. Teams generating scaffolding faster. Engineers writing better tests because they have a patient collaborator who never judges them for not knowing something. Documentation that actually gets written because the friction is low enough that someone does it in the moment instead of promising to do it later.
From those conversations, pull out two or three signals that you can track across all 20 teams. Not AI-specific metrics. Real engineering outcomes where AI is a contributing factor. PR cycle time. Test coverage trends. Bug escape rates. Code review turnaround. Pick the ones that connect to outcomes your organisation already cares about, and embed the AI signal into the existing measurement rather than creating a parallel AI dashboard that everyone will ignore by month three.
Then set a baseline. Write down where you are today. Agree on a realistic target for 90 days. Not a target that justifies the investment to leadership. A target that tells you honestly whether this is working.
That baseline conversation is the most important meeting in the first two weeks. Everything else flows from it.
Stop Treating All 20 Teams the Same
This is the mistake that turns a promising rollout into a slow disaster.
Not all 20 teams are in the same position. Some have solid test coverage, reliable CI/CD pipelines, clear coding standards, and a culture that can absorb a new tool without everything falling over. Some do not. Some have significant technical debt, unreliable builds, and engineers who are stretched thin just keeping the lights on. Giving those two groups the same AI rollout plan is not equitable. It is naive.
Before you design any training or stand up any governance, run a lightweight readiness screen across all 20 teams. A simple self-assessment covering five areas. Test coverage: how much of the codebase is covered and are those tests actually trusted? CI/CD maturity: how often do teams deploy, how reliable is the pipeline, how safe are production changes? Coding standards: are there clear conventions and does everyone follow them? Batch size: are teams working in small incremental changes or in large risky chunks? And psychological safety around AI: have you actually asked how people feel about this?
That last one is the one that gets skipped. The psychological safety question. Engineers who are anxious about AI replacing their role will find subtle ways to resist adoption that no metric will surface. Engineers who are genuinely curious but have never been given permission to experiment will default to caution. You need to know where your teams are before you design the programme, not after.
Once you have the data, sort the 20 teams into three groups.
The foundations-first group needs to fix their SDLC hygiene before AI can help them. Pushing AI tools onto a team with 20% test coverage and a CI pipeline that fails randomly is not scaling AI-enabled engineering. It is adding noise to a system that is already struggling. Help these teams get to a baseline first. Then bring AI in.
The ready-to-accelerate group has the foundations in place and is positioned to adopt AI-enabled practices quickly. These are your showcase teams for the rest of the organisation. Invest here early, document the outcomes, and use the stories to pull the other groups forward.
The early-adopter group is already there. Your job with them is different. Extract what they know. Turn their practices into something teachable. Make them the internal training force rather than the isolated exception.
This sorting is not a judgment. It is a service. You are matching the support to where the team actually is, rather than pretending they are all in the same place.
Build the Curriculum From the People Who Already Know
The temptation at this stage is to buy a training programme. Or to hire a vendor to run a two-day workshop. Or to assign someone in L&D to build something from scratch.
Resist all of these.
The best curriculum for your organisation is the one built from what is actually working in your organisation. Your early adopters know things that no external trainer knows. They know the specific friction points in your codebase. They know which prompting patterns work for your stack. They know the failure modes that are particular to your systems. That knowledge is worth more than any generic course.
Design a three-module curriculum that your early adopters can deliver.
The first module covers the basics. What the model is, what it is actually good at, what it reliably gets wrong. How to think about context and why it matters. What hallucinations look like in practice and how to catch them. How to use the tool iteratively rather than expecting a perfect answer in one pass. This module should be grounded in real examples from your own codebase, not hypotheticals.
The second module covers more structured use. How to build agents and skills that solve specific bounded problems. How to keep those agents focused rather than turning them into do-everything assistants that do nothing well. How to share what you build across teams so people are not reinventing the same solutions in parallel. The idea here is not to turn everyone into an AI engineer. It is to give people a way to contribute to a shared capability rather than accumulating individual knowledge that leaves when they do.
The third module is the one that gets skipped. The human side. What worries people about this technology. What should be handled manually and why. What can be shared with the model and what cannot. This should be a dialogue, not a lecture. Engineers who feel heard in this conversation become advocates. Engineers who feel that their concerns were managed rather than addressed become quiet resistors.
Run this curriculum through a train-the-trainer cohort first. Take your 10 to 15 early adopters through the material. Let them practice delivering it. Collect their feedback and improve it. Then let them run it with their own teams. This scales the training without making it generic. The person teaching is the person doing, which is the only version that actually lands.
Pair People. On Real Work. With Real Deadlines.
Workshops do not change habits. Working alongside someone who is already doing the thing changes habits.
The most effective enablement in this kind of rollout is structured pair programming. Not contrived exercises. Real tickets. Real code. Real deadlines. An engineer who is confident with AI paired with an engineer who is curious but uncertain, working together on actual work for two or three sprints.
This works because the learning happens in context. When the AI-savvy engineer pauses to explain why they phrased a prompt a particular way, or how they caught a hallucination in the output, or why they chose to rewrite rather than accept, the learning sticks in a way that no module can replicate. The curious engineer sees the thinking in real time and can ask questions without feeling judged for not already knowing.
After each session, run a short retrospective. What worked. What did not. What you learned about using AI in this specific context. Write it down somewhere shared. Over weeks this accumulates into a living document of hard-won lessons that becomes the most valuable part of your playbook.
Keep it time-boxed. A few focused sessions over a few weeks is enough to shift how someone relates to the tool. You are not trying to produce AI experts. You are trying to move people from anxious hesitation to confident experimentation. That is a smaller shift than it sounds, and it happens quickly when the conditions are right.
Someone Needs to Own the Playbook
Without coordination, AI-enabled engineering fractures. Each team develops its own patterns, its own agents, its own conventions. The early coherence dissolves into a mess of incompatible approaches that is harder to work with than what you had before.
You need a small working group that owns the playbook.
Not a governance committee. Not an AI centre of excellence with a budget and a roadmap and quarterly reviews. A small cross-functional group, four to six people, that meets monthly and does three things.
Reviews what is working and what is not. Looks at the two or three metrics you defined at the start and asks whether they are moving in the right direction and whether anything needs to change.
Keeps the shared resources current. The agents, the skills, the prompting patterns, the documentation. This is the difference between knowledge that circulates and knowledge that disappears when the person who had it leaves.
Handles the incidents. When something goes wrong, which it will, this group is where the learning lands. Not in a blame meeting. In a practical conversation about what the failure revealed about where the playbook needed to be clearer.
The governance layer should be light. A short policy document about what can and cannot go into a model prompt. A simple checklist for decisions that need human review. A template for documenting AI-assisted changes so the reasoning is visible when someone reads the code six months later.
Simple enough that following it costs less than ignoring it. That is the test.
Bring External Help In After You Have Something
This is the sequence most organisations get backwards.
They bring in external help first. The consultancy runs the training. The vendor deploys the tooling. The programme launches with energy and external momentum. Then the external people leave and the internal people look at each other and wonder how to maintain something they did not build.
Do the internal work first. Run the 60 to 90 day cycle yourself. Build the readiness screen, design the curriculum, run the pairing sessions, stand up the working group. By the end you will have something real. Metrics. Practices. A playbook that came from your organisation, not from a slide deck.
Then bring in external help to pressure-test what you have built. Let them challenge your assumptions. Let them surface blind spots you cannot see because you are inside it. Use them to accelerate the operating-model changes that require outside perspective, like how AI usage should appear in career frameworks or how appraisal processes need to evolve. Use them for targeted acceleration in specific areas where you lack bandwidth, legacy migrations, CI/CD bottlenecks, specialist domains.
This sequence changes the relationship. You are not a client receiving a service. You are an organisation stress-testing its own thinking with external expertise. The work stays yours. The knowledge stays inside. The people who will maintain this over time are the people who built it.
Keep It Alive
At 90 days you have a foundation. Not a finished product.
The tools will change. The models will improve. New patterns will emerge that make your current playbook look dated. Teams that were foundations-first will develop and need different support. New engineers will join who have never worked without AI assistance and will have different questions than the ones you designed the curriculum for.
Build the habits that keep it current.
Revisit the metrics every quarter. Ask whether they still reflect what matters or whether they have become a performance that no longer tracks anything real.
Re-run the readiness screen periodically. Teams change. Their position changes. The support they need changes.
Update the curriculum when the ground shifts under it. Not as a project. As a continuous practice.
Share the wins loudly. When a team reduces PR cycle time by 20 percent, when a legacy migration finishes ahead of schedule, when an engineer ships something in two days that would have taken two weeks, make sure those stories circulate. Not as propaganda for the programme. As evidence that something real is happening, which is what pulls the sceptics toward curiosity.
The message came on a Wednesday morning.
By the end of that day I had a plan. Not a perfect plan. A sequenced one, which is different. Each step creating the conditions for the next. Each week producing something concrete enough to build on.
The rollout that fails is the one that treats all 20 teams as one team, builds the curriculum from the outside in, and calls adoption success. The rollout that works is the one that starts where people actually are, learns from the people who already know, and keeps the knowledge inside the organisation where it can compound.
The tools are not the hard part.
The sequence is.
About the Author
Tino Almeida is a tech leader, coach, and writer reshaping how we think about leadership in a burnout-driven world. With over 20 years at the intersection of engineering, DevOps, and team culture, he helps humans lead consciously from the inside out. When he’s not challenging outdated norms, he’s plotting how to make work more human, one verb at a time.
Thanks, this is a good AI implementation plan; a good 'change' plan generally.