Most teams that say they have "adopted AI" have not adopted AI, they distributed Copilot licenses, opened a ChatGPT account for the team and marked the task as done. Six months later the result is predictable: two or three enthusiastic developers extracting real value, the rest producing PRs with the same generic bug that the LLM hallucinated across three different repositories, no data to sustain a conversation with the board, and an API cost that nobody can explain. AI did not fail. The adoption method failed.
The Steply framework for corporate AI adoption has 7 phases organized into 3 movements: Foundation (are we ready? who owns it?), Structure (how to adopt without amplifying chaos?) and Sustaining (how to keep it working at scale?). It is not a cake recipe, it is a mandatory sequence, skipping Movement 1 and jumping straight to Movement 3 is exactly what produces the amplified chaos this framework exists to prevent. This post walks through each phase, what it delivers, and the symptom that appears when it is ignored.
Why skipping a phase amplifies chaos instead of generating productivity
AI is not a neutral tool that improves what is good and worsens what is bad equally. AI is a multiplier. It pushes the team's signal up when there is process clarity and down when there is ambiguity. A team that already produces code without a clear owner, without a review standard, without a definition of done, will produce more code without an owner, without a standard and without criteria, now generated in seconds instead of hours. The bug is the same, it just scales.
This is why the order of the movements is not aesthetic. Foundation first because without a diagnosis you do not know what you are optimizing, without AI enablers you have no infrastructure to run anything serious, and without a pilot you are betting the annual budget on a hypothesis. Structure next because it only makes sense to remove bottlenecks once you have measured where they are, and progressive adoption only works when there is a successful pilot to use as proof. Sustaining last because governing and scaling something that is not running is process theater, you are documenting expectation instead of reality.
Movement 1, Foundation: are we ready? Who owns it?
This is the phase where most companies cheat. "We are already ready, the team is senior, no diagnosis needed", a phrase that precedes 100% of the AI projects that sink in 4 months. The Foundation answers two questions nobody wants to answer honestly: where it really hurts, and who takes responsibility for the result. Without those two answers, everything else is improvisation.
Phase 1, Diagnosis
It is not a half-day workshop with colorful sticky notes. It is an honest mapping of three things: (1) where the team spends time that does not deliver value (circular reviews, regression debugging, broken builds, meetings about meetings), (2) which processes have a clear rule but repetitive manual execution (issue triage, ticket classification, release notes generation, writing documentation from the code), and (3) what the leadership's real tolerance for risk is, risk of model error, risk of data exposure, risk of process change. Without a diagnosis, any tool looks good because there is no comparison criteria.
Phase 2, AI Enablers
Before any use case, you need what makes AI possible inside the company: a clear data policy (what can go to the external model, what needs to stay in-house), contracts with providers (Anthropic, OpenAI, Google or self-hosted) with a no-training clause, cost control (limit per key, alert per consumption, attribution per team), and technical access (corporate proxy, model gateway, call observability). A company that gets into AI without enablers discovers, two months later, that token consumption doubles every two weeks and nobody knows who is calling which API with which data.
Phase 3, Pilot
A single use case, with a short scope, short deadline, measurable success. It is not "let's see where AI helps", it is "let's solve this specific problem in 6 weeks and measure before/after". The pilot serves three purposes: concrete proof of value for leadership, operational learning for the technical team, and generation of internal evidence to overcome the cultural resistance that always exists in the next phase. A pilot without a metric is a pretty demo that nobody takes seriously.
Movement 2, Structure: how to adopt without amplifying chaos?
With the Foundation in place, the problem stops being "whether AI works" and becomes "how to expand without breaking what is already good". This is where the framework differs from the naive approach of "release Copilot for everyone and pray". The Structure is deliberate about where to apply it (real bottlenecks, not fads) and how to apply it (progressively, ring by ring, not in a big bang).
Phase 4, Bottlenecks
With the pilot delivered, you have a much more honest map of where AI actually moves the needle. Now the question is: which are the 2 or 3 bottlenecks of the engineering flow that, if removed, unlock the greatest throughput? It is usually boilerplate code, test generation, API documentation, bug triage, writing migrations, mechanical refactoring. It is not "every developer uses AI all the time", it is "the identified bottlenecks start using AI with a well-defined process". Surgical application beats diffuse application in every scenario where the metric matters.
Phase 5, Progressive Adoption
Concentric rings. Ring 1: the pilot team becomes the reference squad, operates with AI in production, documents patterns and antipatterns. Ring 2: two or three adjacent teams adopt the same pattern under mentorship from Ring 1. Ring 3: general rollout, with onboarding material ready and an internal support channel working. Each ring only opens after the previous one has stabilized. A big-bang adoption ("next week everyone is using it") is the most expensive known way to burn AI credibility inside the company, when an untrained team fails in public, the narrative that remains is "AI does not work here", not "the adoption was done badly".
Movement 3, Sustaining: how to keep it working at scale?
It is the most frequently ignored phase, and the one that charges the most interest later. Adoption without sustaining degrades in 6 to 12 months, the standard dilutes, the cost escapes, the initial enthusiasm turns into frustration when the model changes version and breaks the flow, and the company goes back practically to the pre-AI state with the difference of having a monthly invoice to justify.
Phase 6, Governance
Governance here is not a committee. It is a small and operational set of things: (1) a named owner for each AI use in production (with a name, not a job title), (2) a policy for reviewing prompts and system instructions versioned in git like any other code, (3) minimal auditing of critical outputs (1-5% sampling per use), (4) an approval process for new use cases (not to block, to register and measure), and (5) a quarterly review of what still makes sense. Good governance is the kind that fits on one page. Bad governance is the kind that needs a committee to explain why it exists.
Phase 7, Scale
Scale is not "more AI in more places", it is making the use of AI as routine as using CI/CD. It means: a prompt standard versioned in an internal library, a model gateway with fallback and cost-based routing, observability of latency/cost/quality per use case, a migration plan between model versions (because it will change), and onboarding of a new developer that includes AI like any other tool in the stack. When phase 7 is mature, nobody in the company talks about an "AI project" anymore. They talk about the product. AI became the substrate.
What this framework explicitly is not
It is not agile methodology renamed. It is not a certification. It does not have a Bronze/Silver/Gold level. It does not sell training. It is a diagnosis of order. If your company is in phase 6 without having gone through phase 1, the symptom will appear in 90 days in the form of process fatigue over technology nobody really understands. If it is in phase 4 without having gone through phase 3, it will choose the wrong bottleneck and burn the pilot budget in the wrong phase. The order is the contribution.
For the technical team reading this and thinking "we are clearly in phase 5 but we skipped 1 and 2", that is exactly the most common diagnosis and the most correctable one. Going back is not a regression, it is an unblock. The alternative, continuing without a foundation, is the scenario in which you spend the whole year optimizing something nobody can explain to leadership in Q4. The framework exists to avoid that conversation.