- DOC
- writing/every-marketing-stack-is-a-haunted-house
- VER
- 1.0
- STATUS
- MAINTAINED
- LAST REVIEWED
- 2026-08
Every Marketing Stack Is a Haunted House
I've spent about ten years of my life inheriting other people's marketing stacks, which means I've spent ten years opening smart campaigns the way you open a fridge in an abandoned apartment. You know something's in there. You know it was reasonable once. You're just not sure whether it's still food.
In that decade I've migrated companies off customer.io and onto Marketo, built Segment from an empty workspace twice, consolidated five consent tools into one, and at one point was personally responsible for a CDP pushing a hundred million events a month, which is a fun thing to think about at 2am. Different companies, different industries, different tools. One constant: every stack I have ever opened was haunted.
Not broken — haunted. There's a difference, and it took me embarrassingly long to learn it.
What a ghost actually is
A ghost is a decision that outlived the person who made it.
The smart campaign called TEMP - fix routing DO NOT DELETE, running since 2021, author's account deactivated. The field called Lead_Status_NEW_v2_FINAL, which is load-bearing. The sync filter excluding one country, for reasons that were absolutely critical and completely undocumented. The workflow that emails a weekly report to three people, two of whom no longer work there, one of whom has never once opened it but would notice its absence immediately.
None of these are bugs. Every single one worked. Every single one was a smart person solving a real problem under real deadline pressure — and then leaving, taking the "why" with them, and leaving the "what" running in production forever. A haunted stack isn't a stack where things fail. It's a stack where things succeed for reasons nobody can explain, which is worse, because you can fix a failure. You can only inherit a mystery.
The fridge rule applies: you didn't put it there, you can't identify it, and you're the one who has to decide whether it's safe to remove.
The ghosts are never in the software
Here's the part that changed how I work. Early on, I treated hauntings as technical debt — messy instances built by messy people, waiting for someone organized to arrive. (I am extremely that someone. I have opinions about folder structures the way other people have opinions about football teams.) So I'd clean. Rename, restructure, document, admire.
And then I watched a beautifully cleaned instance re-haunt itself in under a year, and had to sit with what that meant.
Every ghost, traced back far enough, is organizational. TEMP - fix routing exists because two teams couldn't agree on lead routing, so an admin built a workaround instead of forcing the meeting. The undocumented sync filter exists because a compliance question got answered verbally, once, by someone senior, and writing it down felt unnecessary. The five consent tools I consolidated weren't a technology accident — they were five teams making five reasonable purchases because no one owned the question. The stack doesn't have an architecture problem. The stack is a fossil record of every reorg, every deadline, every argument that ended with "fine, we'll just handle it in the automation."
You can read a company's entire history in its marketing stack the way you read tree rings, except the tree is on fire and also somehow still hitting its email KPIs. Show me your instance and I'll tell you about your org chart. I have never once been wrong about this, and I've stopped expecting to be.
Migrations: the exorcism that isn't
You'd think migrations would be my favorite thing, then — burn the haunted house down, build a new one, carry nothing across but the good decisions. That's certainly the pitch every migration makes for itself.
Here's what a decade of them taught me instead: a migration without an inventory is just a haunted-house relocation service. The ghosts don't live in the platform; they live in the undocumented decisions, and those pack themselves into the moving boxes for free. Migrate a routing mess without understanding it and you'll faithfully rebuild the mess in the new tool — I've seen it done with impressive attention to detail, workaround by workaround, like restorers of a cursed painting.
The migrations that actually worked — the customer.io-to-Marketo one is the one I'd frame — worked because we spent the boring weeks first: inventorying every automation, writing down what each one did, why it existed, and whether the reason still did. Most of the project was archaeology. The build was almost an afterthought. Measure twice, cut once — except in ops the ratio is more like measure nine times, and the cutting is done by a intern-shaped batch job at 3am, so the measuring had better have been right.
Living with ghosts, professionally
So after ten years, my honest position on haunted stacks is this: you don't fix hauntings with heroics, and you don't prevent them with talent. You prevent them with the most unglamorous tool in the industry — writing things down — applied with the discipline of someone who has been the next admin too many times to do that to another human being.
Every automation ships with a sentence explaining why it exists. Every workaround gets a named owner and an expiry question. Every "we'll document it later" gets treated as what it is — a ghost, requesting permission to be born. This is not exciting work. Nobody gives out awards for it. It has quietly been the highest-ROI habit of my entire career, and the teams that adopted it are the only ones whose stacks I'd describe as merely lived-in rather than haunted.
I love this work, for the record. Genuinely. I love it the way some people love restoring old houses — the moment when a mystery workflow finally confesses its purpose is, to me, better than most television. But a decade in, I've made peace with what the job actually is. I'm not really a technologist. I'm a translator between the people who left and the people who stayed.
The tools change. The ghosts are eternal. Bring a flashlight, and label everything.