Measure Twice, Cut Once Is a Marketing Ops Strategy

I should confess something up front: I am the person who reads the migration guide. All of it. Before starting. I make project plans for my project plans. My idea of living dangerously is deploying a change on a Thursday. At parties, people ask what I do, and I say "I write things down before doing them, professionally," and they refill their drink, and honestly? Fair.

But I've had ten years to watch how this industry works, and I've arrived at a position I'm no longer embarrassed about: in marketing operations, being boring is a strategy. Arguably the strategy. "Measure twice, cut once" isn't a temperament I happen to have — it's the correct engineering response to a specific property of this field that almost everyone underrates.

That property is this: in ops, the cutting is automated. Your mistakes don't ship once — they ship at batch-job scale, to everyone matching the smart list, at 3am, while you sleep.

Why this field punishes improvisation specifically

Every discipline has a cost asymmetry between planning and redoing. Ours is unusually brutal, for three reasons.

First, most cuts can't be uncut. A sent email is sent. A deleted field takes its history with it. A bad sync mapping doesn't just write wrong data — it propagates wrong data into every downstream system that trusted it, and there is no ctrl-Z that spans four platforms. Carpenters at least get to keep the wood they measured wrong. We often don't get to keep the database.

Second, the blast radius is invisible at decision time. The change looks small — one field, one filter, one trigger. Whether it is small depends on everything referencing it, and in a mature stack that dependency graph lives partly in the platform and partly in the memory of people who no longer work there. "Quick change" is a claim about the graph, made by someone who hasn't seen it.

Third, feedback is slow and quiet. Code that breaks, breaks loudly and immediately. Ops mistakes prefer stealth: the sync that starts skipping records, the suppression list that stops suppressing, the score that drifts. By the time the symptom surfaces in a report, the cause is weeks old and cold. When feedback is delayed, the only protection is up-front rigor — you can't iterate your way out of an error you won't detect until next quarter.

Put those three together and the economics are lopsided: measuring costs hours, cutting wrong costs weeks — and sometimes it costs things money can't buy back, like deliverability reputation or the sales team's trust in the funnel numbers. (Ask anyone who's rebuilt that particular asset how long it takes. Bring snacks.)

What measuring twice actually looks like

Since "be careful" is advice-shaped noise, here's the method in its five honest steps — the same skeleton whether the job is a field change or a full platform migration:

Inventory before intent. Before deciding what to do, document what is — every automation touched, every field referenced, every system downstream. The unglamorous truth of my best projects: most of the timeline was archaeology, and the build was almost an afterthought.

Write the plan where others can attack it. A plan in your head is a mood. Written down, it becomes a target — colleagues can find the flaw, the compliance question, the "wait, that field is load-bearing." I want my plan attacked on paper. Paper is where attacks are cheap.

Decide the rollback before the change. "How do we undo this" is a question with two prices: nearly free before you act, occasionally unpayable after. If the honest rollback answer is "we can't," that's not necessarily a stop — but it moves the change into a different category, with different ceremony. Knowing which category you're in is the seniority.

Stage the cut. Ten records before ten thousand. One region before global. A soft launch running silently next to the old system before anything is decommissioned. Every migration that's gone well in my career went well because the old system was still alive to catch us; every horror story I've collected involves a bridge burned on schedule rather than on evidence.

Document while it's warm. The final step of any change is writing down what was done and why — not for the auditor (though she'll be delighted), but because undocumented decisions are how haunted stacks happen, and I've sworn an oath about that.

None of this is exotic. That's rather the point. It's a checklist a careful person can run every single time — and "every single time" is where the value lives, because the discipline only protects you if it's boring enough to be habitual.

"But isn't that slow?"

This is the objection, always, and I understand it — the plan-first way feels slow, the same way stopping for fuel feels slow. So let me make the paradox explicit: over any horizon longer than about two weeks, the boring way is the fast way.

The improvised change ships today, then spends three weeks in remediation: the incident, the forensics, the apology email about the apology email, the rebuilt trust. The measured change ships Thursday — carefully, obviously — and then stays shipped. Rework is where speed actually dies in this field, and rework is precisely what measuring buys down. I've run this race from both lanes, and the tortoise doesn't just win — the tortoise wins while the hare is still writing the incident retro.

Speed and rigor aren't opposites; they're sequenced. Rigor is how you go fast later, on purpose, safely — because the inventory exists, the dependencies are mapped, and changes land on a known surface instead of terrain.

Where I'll happily move fast

Full honesty requires the counter-case, so: not everything deserves ceremony. Drafts, mockups, experiments in a sandbox, anything reversible with a small blast radius — improvise freely; I do. The discipline isn't "always go slow." It's knowing which kind of change you're holding. Reversible and contained: move quick, learn, adjust. Irreversible or wide: measure, stage, document, then cut once.

The judgment call between those two categories is, I'd argue, most of what senior actually means in this field. The tools can be learned in months. Knowing where the ctrl-Z ends — that's the decade.

So yes: I read the manual, I write the plan, I schedule the change for Tuesday. I've made my peace with being the least exciting person in the room during planning — because I've noticed, over and over, that it's very exciting to work somewhere nothing is ever on fire.