Deploying Change: Think Big, Act Small, Move Fast

I once deployed a new pipeline model the way you deploy a slide. We had redrawn the whole thing: cleaner stages, observable exit criteria, a Bowtie that finally counted retention and expansion instead of only new logos. I walked the sales org through it in a ninety-minute all-hands, posted the new definitions in the wiki, flipped the fields in Salesforce over a weekend, and called it launched. Three weeks later the reps were stuffing deals into the old stages out of muscle memory, managers were forecasting off gut instead of the new gates, and the dashboard I was proud of was measuring a process nobody was actually running. The model was right. The deployment was a broadcast, and you cannot broadcast a behavior change.

That failure is the whole reason this chapter exists. The models in Module 2 and the disciplines in Module 4 are worthless if they live only on the whiteboard. Revenue Architecture treats deployment as its own engineering problem and gives it a method: Think Big, then Act Small, then Move Fast, executed as 21 sequenced actions. You do not need to memorize all 21. You need the shape of the three phases and the judgment about what belongs in each, because the failure mode is almost always doing them in the wrong order: acting small before you have thought big, or moving fast before you have picked anything small enough to move on.

Think Big: design it with the people who will own it

Think Big is the phase everyone wants to skip and no one can afford to. Before a single rep sees a field change, you assemble the leadership team and design the operating model at full scale. Revenue Architecture is specific about who is in the room: three layers (executives, managers, individual performers) and a core team of no more than ten. Ten is not a suggestion. A deploy team of thirty produces consensus theater; a team of ten produces decisions.

The move that makes this real is assigning a steward to each of the six models. One accountable owner per model, so that “who decides the definition of a Qualified Opportunity” has a name instead of a committee. Revenue Architecture maps the stewards to the executive whose function the model governs:

Your titles will differ. The principle does not: every model has exactly one steward, and the steward is senior enough to make the definition stick across a function. When a rep disputes a stage definition six weeks from now, you do not reconvene the deploy team. You go to the Data Model steward, because that is what the role is for.

With stewards named, Think Big sequences the work in a deliberate order: Growth Model, then GTM Model, then Data Model, then Operating Model. That order matters more than it looks. You decide how the company intends to grow before you decide which motions carry it, and you settle the motions before you instrument them. Instrumenting a business you have not yet decided how to grow is how you end up with a beautiful dashboard measuring the wrong factory. The rest of the Think Big actions are the design itself, most of which you have already done earlier in this course: map the 12 revenue breakpoints and the four growth stages, plot your top three motions on the X-Y grid, draw the Bowtie with its VM and CR markers, and write the Growth Formula for each motion so you can compare adding inputs against improving throughput.

Think Big is expensive and it is supposed to be. The last time I ran this properly, the Think Big work was a full quarter of consolidating 282 automations down to 82 and settling one data contract before a single seller saw a change. It felt slow. It was the only reason the change survived contact with the floor.

Act Small: Moments That Matter

Here is where the broadcast instinct kills you. Having designed the whole model, the temptation is to roll out the whole model. Act Small refuses that. You take the industrial-scale design and cut it down to a handful of moments precise enough to coach a person through.

The tool is the Impact Journey, and it is built deliberately backward. You start from the right side of the Bowtie, the retention and expansion end, and you relabel every stage in impact-centric terms: “Mutual Commit” instead of “Closed/Won,” language that describes what the customer gets rather than what the rep booked. Reading the journey right to left keeps the deploy honest about the thing that actually compounds, which is recurring impact, not the signature.

Across that journey you pick 7 to 10 Moments That Matter, a concept Revenue Architecture borrows from Chip and Dan Heath’s The Power of Moments: the specific interactions that disproportionately shape whether the customer moves forward. The first discovery call. The mutual action plan. The onboarding kickoff. The first realized outcome. Then you do the one thing that turns a moment into an operating target: you link each Moment That Matters to a single conversion metric and set a 10% improvement goal on it.

Ten percent per moment sounds modest until you count the moments. Throughput points multiply, they do not add.

Ten percent is also chosen for a human reason: it is believable. Tell a rep to double a conversion rate and they tune out. Tell them to move it a tenth on one specific moment and they will try it on Monday. Act Small is the phase where the deploy stops being a strategy and becomes something a person can do this week.

Move Fast: coaching sprints, one skill at a time

Move Fast is where most operators discover they have been running training, not deployment. You run the change as Agile sprints, two to four weeks each, one skill at a time, in a fixed loop: Analyze, then Train, then Coach. Analyze one metric tied to one Moment That Matters. Deliver a short masterclass, one or two hours, on the single skill that moves it. Then coach it every week against real call recordings and live deals until it holds, and only then combine it with the next sprint.

The reason for the sequence is a well-documented fact about how adults build skill: the 10/20/70 model (from the Center for Creative Leadership’s research on managerial learning). Roughly 10% of a skill comes from formal instruction, 20% from coaching and social learning, and 70% from doing the work. The masterclass is the 10%. The weekly recording review is the 20%. The reps applying it on their own pipeline is the 70%. My broadcast launch failed because it was all 10 and no 70: a ninety-minute all-hands is the classroom slice, and the classroom slice evaporates the moment the room empties.

One skill at a time is the discipline that makes this survivable. A rep can absorb one new behavior per sprint. Hand them five and they master zero. The sprint is deliberately narrow so that the 70% has somewhere to land, and narrow sprints are why the whole thing moves fast in aggregate even though each piece looks small.

Where the change actually lands

A deploy needs a place to live after the launch energy fades, and Revenue Architecture puts it in the cadence you built in the previous chapter: the monthly GTM Council, run against a permanent Bowtie dashboard, and the recurring GTM Diagnostics meeting (sixty to ninety minutes) that reviews the moments and the sprints. This is Action 11.21, and it is the least glamorous and most decisive move in the method. The Council is where a Moment That Matters that stopped improving gets a new sprint, where a steward defends or amends a definition, and where the deploy stops being a project with an end date and becomes the way the business runs. The change does not persist because you announced it. It persists because there is a standing meeting that keeps asking whether it is working, and a dashboard that answers.

The last action of the method is the first thing you should do: involve everyone, and start the cadence now, before the design is perfect. A deploy that waits for a finished model never starts. A deploy that begins with one steward, one Moment, and one sprint has already begun to compound.

The coaching sprint is the atomic unit of a deployment, and it is also the atomic unit of enablement. In the next chapter we take that same Analyze-Train-Coach loop and scale it into a productivity system: how to shorten ramp, how to read the three productivity cohorts, and how to move the middle of the team rather than lavishing attention on the top. Deployment is how you install a new operating model once. Enablement is how you keep raising the output of the people running it.