From one unofficial user to a team of nine — how AI adoption was designed as organizational change
The company had licenses and access to AI tools, but the way the team worked hadn't changed. The reason was a lack of designed change: no one had addressed job-security fears, there was no champion and no standard. We introduced an internal topic lead, a written board statement, a three-stage rollout, and a company-wide agent configuration standard connected to repositories.
Licenses in place, change nowhere
The organization had licenses and the team had access to the tools. The impact on how they worked remained minimal. The diagnosis revealed a pattern typical for companies at this stage: one experienced developer used AI tools daily and didn't tell the team. Some employees took a purist stance toward AI-assisted code. Some voiced fears about their jobs — fears no one had addressed directly. The team consistently refused to add agent configuration files to repositories. Without a standard, everyone got different-quality results and drew different conclusions about the tools' usefulness. The problem was organizational, not technological, and it was treated as such.
What we didAI adoption designed as organizational change
- Started with observation, not training — the first month meant being present in the organization and holding individual conversations, with no presentations or programmatic declarations.
- Identified a topic lead inside the team — an employee already using the tools. The role was communicated through their direct manager, respecting the org structure.
- Obtained a written board statement — a concise document stating the business objective and explicit permission to experiment and make mistakes. Without this, any conversation about job fears has no foundation.
- Designed a three-stage rollout: a general live session, group workshops tied to specific projects, then individual work at the advanced stage.
- Established a technical standard — a company-wide base prompt ensuring code consistency, supplemented with a personalization layer for individual developers. Attached to repositories as a dependency module, always current.
- Introduced a fixed rhythm — a weekly team meeting dedicated exclusively to this area.
What changed
The team works to a shared standard, and every member has experience working with AI tools. Coding and architecture rules were written once and propagate automatically to all projects. A new developer joining the team enters a ready-made working environment. The team began submitting their own improvement proposals instead of waiting for instructions.
“If licenses were bought and the way of working didn't change, the reason usually isn't tool quality — it's the absence of designed change. A topic lead from within the team, an unambiguous board statement allowing trial and error, and a standard that gives everyone comparable results. The rest is consistency and rhythm.”
Let's write down how your company actually works.
- 45 minutes, and no preparation needed
- An honest read on where you sit today
- The first process worth automating — and why that one
