Monday morning. Forty-five minutes before the AI implementation meeting with the wider team, and Alex and I are already going at it. Not a productive disagreement — a messy one. He's been sick all week in Bali, barely upright, sweating through his first day back. I've been sprinting for seven straight days, building dashboards, training people one-on-one, shipping at 2am. I walk into the leadership planning session immediately after and Paul has to diplomatically note that disagreeing in front of a group isn't ideal. He's right. I'm running hot and it's obvious.
That same afternoon, I'm building a Google Ads visualisation during the SharkNinja meeting. Already in "I'll do it all myself" mode. This is not a polished retrospective. This is what happened across 48 hours when I got the rollout wrong.
Three things, specifically.
I didn't align with Alex before the meeting. Alex co-founded Webprofits. He runs operations. He'd been out sick for a week and came back to find I'd been moving at full speed without him — building dashboards, training individuals, deploying to my own domain. His first interaction back was walking into a room where we were already arguing about approach. That's a failure on my part.
I had no training structure. Matt nailed this in the leadership session later that morning. He brought up how a friend's agency rolled out Midjourney — they didn't just say "everyone download it and have a play." They got the whole team in a room for three or four days, structured the learning, set the new standard, then removed the old tools. "What is our syllabus?" he asked. "What are the specific skills we're actually trying to get them to learn?" I didn't have an answer. I'd been doing one-on-ones, which work — but I had no framework for what "trained" actually looks like.
I was building everything myself. Five client reports overnight. A daily optimisation dashboard. Automated slide decks. Proposal templates. Every time something needed doing, I did it. Which meant the team watched. The companion piece covers the capability proof — but capability concentrated in one person isn't a rollout. It's a bottleneck wearing a cape.
Aleksey — who'd been quietly observing both meetings — cut through it. Not dramatically. Diplomatically. "I think we just need to put together a list of the things that we need to do," he said. "Work through it iteratively. One to a hundred per cent, then the next one, the next one." Sequential sprints. Not me building five things at once while everyone else figures out what happened.
Within the hour, I was in Slack apologising. The energy I'd brought into that meeting wasn't productive. The intent was right. The approach was wrong.
What stuck with me was Aleksey asking — twice — for clarity on what he should communicate to the team. That gap is the story. The distance between how fast I was moving and the organisation's ability to process what I was doing. I couldn't even articulate clearly what the team should be told, because I hadn't stopped to think about it from their perspective.
The plan fundamentally shifted in 48 hours.
Monday: I'm building everything. Five reports shipped at 2am. Dashboard prototypes. Automated slide generation. The team gets a message in Slack with links.
Tuesday: Agent files as starting points. A shared folder with branding guidelines and a CLAUDE.md file the team can use. Structured sessions planned for Friday where people build their own reports — not watch me build them. Skills uploaded to the organisation's Claude account so everyone starts from the same foundation.
The clearest signal it could work: Alex — the same person who told me I was moving too fast on Monday — was building his own Waterdrop report by Tuesday night. Connecting the Klaviyo MCP. Setting up the data pulls. Not because I trained him. Because the infrastructure was there for him to build something real, on his own terms, at his own pace.
That's the pattern from Training Doesn't Transfer playing out in real time. Not training. Building.
Being fast isn't the issue. I'll defend the pace every time. The tools are there. The opportunity is real. Every week a director hasn't crossed over to building with AI is a week of exponential output left on the table.
But being fast in the wrong direction compounds the damage. When I build five reports overnight without a plan for how the team absorbs them, I've created five things nobody knows what to do with. When I train people one-on-one without a syllabus, every session teaches something slightly different. When I don't align with the co-founder before walking into a room with the leadership team, I burn trust that takes weeks to rebuild.
Speed in the right direction is the most valuable thing in the company right now. Speed in the wrong direction is the most expensive.
The shift wasn't slowing down. It was pointing the speed at the right things: infrastructure the team can use, frameworks they can build within, sessions where they do the work instead of watching me do it.
The plan is still evolving. We're running one-week sprints because we can't think further ahead than that right now. The branding isn't finalised. The hosting isn't solved. The training syllabus Matt asked for doesn't exist yet.
But Alex building Waterdrop on Tuesday night — unprompted, on his own, because the starting point was there — that's worth more than five reports I shipped at 2am. The willingness to be told you're wrong, and the willingness to change within 48 hours, is the rollout working. Not the technology. The people.
This article covers the vulnerability side. The capability proof — five reports overnight, the $40K contrast, and why being right still isn't enough — is in the companion piece.
Read: $40,000 for Zero Dashboards. Then Five in One Night. →