I introduced Kotlin Multiplatform^kmm, blockchain platforms and different flavors of AI into companies that were already running at full speed. Dozens of engineers, separate roadmaps, basically no slack in the calendar. Each time I asked myself a simple question: how do you teach an entire organisation something new without stopping the services we already ship?

Key ingredients

When squads operate in silos, information flows through narrow pipes. Slack threads, emails and the occasional show-and-tell keep projects alive, but they rarely create shared understanding. Each team chases its own milestones, which is perfect for delivery and terrible for spreading a new skillset.

There are three key components that make the change work: communication, possibilities and knowledge. Let’s go through them.

Communication

How do you reach fifty engineers without spamming everyone? Win ten conversations—one per team. As soon as a single person feels responsible for the topic, it shows up during dailies, retros or refinement. That is when “maybe we should try this” becomes an option on the board.

I keep a single page that answers four questions. I call it the “What, Where, How, Why” brief and I link to it in every Slack thread or short announcement.

• What? Describe the tech in plain language and inside your context. If the library removes boilerplate, show a before/after diff. If the platform lowers latency, paste a benchmark. No Wikipedia clones.
• Where? Explain the path through company processes: repository access, security reviews, procurement. Everyone should know which form to fill or which script to run.
• How? Outline the learning path. If you share an article, make sure it actually teaches. Add internal code labs, recordings or example branches that show the real integration.
• Why? Tie the effort to the business outcome. “We introduce AI to speed up boilerplate coding and ship features faster.” Give people a reason to invest evenings and sprint capacity.

Possibilities

How long does it take to build new habits? I aim for a quarter-long runway. Pulling from 4 ways to introduce new technology, that window lets you mix slower internal learning with faster external sparks. Map it into phases—scoping and procurement first, then learning, then pilots—and make sure your OKRs show when the investment should start paying off.

Budget follows the same rhythm. Plan for three buckets and write them into the roadmap:

• People time — reserve explicit learning capacity in each squad and give pilot teams enough room to experiment without breaking delivery promises. Bake it into sprint plans so nobody “borrows” the time back.
• Tooling — expect temporary spikes from LLM API calls, GPU credits or vendor licenses. Decide early which costs stay in central platform budgets and which remain with product teams.
• Advisory — external trainers or short-term contractors should have clear milestones that match the overall plan. No “learning sprees” just to spend annual budgets.

Then build the environment that protects all of this. I rotate “AI office hours” with early adopters, keep a single Confluence hub with curated resources, and run demo sessions every other week. When people see how the new tech shapes customer outcomes, it stops being a side quest and becomes part of the culture.

Knowledge

Knowledge without context evaporates. Define the sources before you launch:

• Core material — vendor docs, research papers and reference books that everyone should skim (Deep Learning by Goodfellow, OpenAI API docs). Keep the list short and refreshed.
• Company playbooks — internal architecture diagrams, ADRs and compliance notes that show how the tech fits within your boundaries. This is where generic advice becomes yours.
• People — assign mentors: a staff engineer running the pilot, a data scientist to validate models, a product manager to link use cases with customer value. Make sure they hold office hours and review sessions so knowledge keeps flowing.

Typical 70-20-10 learning mixes (experience, social, formal) come from stable job environments. When you introduce brand new tech, flip the ratio early on—lean heavily on structured training, then move back toward experiential learning as the team gains confidence. Research by Johnson, Blackman & Buick^hrdq shows the framework works only when work, social and formal channels are tightly integrated, and Harding^harding warns not to treat it as a literal target—more as a narrative lens you adapt over time. Execution is the lever: align practice projects with real work, pair mentors with squads, and make sure formal sessions deliver assets teams can reuse the next day.

Every path ends with application. If we teach AI-assisted code generation, the assignment is to ship boilerplate faster in the payments service and observe merge-request flow. If we coach support teams on summarisation, track the change in ticket handling time and customer satisfaction. When the runway closes, review what the budget bought—code shipped faster, incidents avoided, user metrics moving. Investments that cannot be tied back to company goals do not roll over to the next cycle.