Creating the Moment

You can’t tell people to experience the moment. You cultivate the conditions for it.

That sounds passive. It isn’t. The work is real and demanding, and it has a structure: each layer of people who’ve had the moment becomes the engine for creating it for the next layer. You start with yourself. You build a small group. The small group enables team-level coaching. Team coaching enables organization-level events.

Stalled → This people-centric work runs in parallel with the technical work in the next chapter — not in sequence. Coaching sessions on a codebase the agent can’t reason about produce frustration. Hackathons that depend on agent productivity in unprepared repos produce demos that don’t ship. If you’re stalled, check whether you’ve been treating these as sequential phases.

Layer one: yourself

Before any of this can spread, it has to be real for you.

If you’re leading the transformation, you need to be using the tools yourself, on real work, with the same constraints you’re going to ask others to accept. Engineers can tell when someone is selling them on something they haven’t used.

This is harder if you’re not currently writing code. Pair with a developer who’s open to the transformation. Work through a real ticket together. Build something small for your own team’s tooling. The point isn’t to become a working developer again. It’s to have first-hand experience with what you’re asking everyone else to do.

The credibility this earns is significant. I tried this last week with our code, and here’s what happened is a different conversation from one where you cite metrics or quote vendors.

Culture → If you haven’t written code in years, the discomfort of getting back into the tools is part of the work. Don’t skip it. Your team is watching whether you’re willing to do what you’re asking them to do.

Layer two: a small group of agentic leaders

Before team-level coaching, you need a small group who’ve had the moment and can help create it for others. These are early adopters, but treating them as evangelists misses what they actually do.

Their real job is to test the hype against reality. They try things, find what works and what doesn’t, and report back. They become the people other engineers ask when they’re stuck or skeptical. They share what they’re learning in informal venues, and the sharing builds the social proof that pulls more people in.

Grow this group deliberately:

• Look for curiosity, not seniority. The first adopters aren’t always your strongest engineers. They’re the ones willing to play with new tools on their own time. Some will be junior. That’s fine.
• Create a recurring venue. Weekly or biweekly. Whoever has been doing something interesting comes and shows. Low-stakes, no agenda, no requirement to attend. Early sessions will be sparse. Attendance grows.
• Encourage boundary-pushing. Don’t constrain them with how work was done before. Let them surprise you.
• Watch the stories that come out. When someone demos that an agent scaffolded a cross-platform feature in 45 minutes, the response from their team isn’t skepticism, it’s how do I do that? That’s the social proof loop starting.

Stalled → If you’ve rolled out the tools and adoption is climbing but no internal practitioner group has emerged, the gap is usually a venue. People are using the tools privately. Without a place to share, experiments don’t compound. Create the venue, even if only two people show up.

Layer three: team-level coaching

Once you have a small group, you can create the moment for whole teams at a time.

The format that works: bring a team together for a fixed block, three or four hours, and work through real backlog items together with agents, hands-on. Not a demo or a workshop. Real work, in their codebase, with their constraints. Pick something the team thought was impossible.

Coaching session run-of-show (~4 hours):

A few things make this work:

• Pick real work, not exercises. Hypothetical problems produce hypothetical learning. Real backlog items produce real outcomes the team has to integrate.
• Cross-repo context matters. Most real work doesn’t live in one repo. The patterns the team learns about cross-repo context become the patterns they use for the rest of their work.
• No manual coding during the session. Harder than it sounds. The instinct, when an agent gets stuck, is to take over and type the fix. The point is to keep the developers in the steering role.
• Prompting and context are the skills being taught. Make them explicit as they come up.

The output of a good session is two things: real work moved closer to done, and a team that has had the moment together. They’ll talk about it for weeks. Some will become your next layer of agentic leaders.

Developer steering → The most common failure mode is teams skipping the planning step and jumping to “build me this feature.” The agent needs context and intent before it can produce anything useful. Make planning conversations part of the session itself.

Layer four: hackathons

Hackathons come when enough people have already had the moment. Run them too early and they produce demos that lack scale. Run them at the right time and they’re when the transformation becomes visible to the entire organization.

A few things matter:

• Set rules that match the practice. No manual coding, real work that affects the product or business, agent-led implementation.
• Include non-developers. Product managers, designers, program managers. The work they produce with agents is often the most interesting output. It also signals the transformation isn’t an engineering thing.
• Use it as a momentum gauge. The number of people who show up, the energy in the room, what they attempt — all of it tells you where the organization actually is.
• Watch for innovation, not just execution. The interesting outputs are rarely the planned roadmap items finished faster. They’re the unplanned bets people made because the cost of trying was suddenly low.

Watch out → A hackathon run before the layers underneath are ready will produce a memory people use against you. We tried this and it didn’t work is hard to recover from. If you’re not confident the layers are there, run more team-level coaching first.

What this looks like over time

These layers don’t run hard forever. After enough cycles, the flywheel sustains itself. The early adopter group keeps growing. Team coaching keeps happening, often led by people you’ve coached. Hackathons become an occasional rhythm rather than a regular event. You stay involved, but it’s lighter.

The point at which the transformation runs without you is the point at which it’s actually working.

Culture → Many leaders find this disorienting. The temptation is to keep being central. Resist that. Your job at this stage is to make sure the layers stay healthy, not to keep being the engine.