If you have ever taken over a marketing ops system that someone else built, you already know what I am about to describe. If you haven’t, this is the part of the job nobody warns you about, and the part that determines whether your first year goes well or badly.
The system I inherited had 491 active workflows in HubSpot, six lead source fields with different sync rules, an undocumented scoring model, a routing tool nobody had touched in two years, and a Salesforce instance that one of my colleagues co-owned but couldn’t fully explain because half of it had been built before she joined. The person who built most of it had left the company three months before I arrived. He had written onboarding documents, which I want to be fair about. They were thoughtful. They were also nowhere close to enough.
That gap, between “thoughtful documentation” and “enough documentation,” is what I want to talk about. Because the gap is where the real work of the first six months lives.
Here is what inheriting an undocumented system actually feels like. Every change you consider making is a gamble, because you cannot predict the downstream consequences. You don’t know which workflows depend on which fields. You don’t know which reports break if you rename a property. You don’t know which automations fire when a contact moves between lifecycle stages. The person who knew is gone, and the system itself doesn’t tell you. Tools like HubSpot and Salesforce will happily show you a list of 491 workflows. They will not tell you which ones matter, which ones are dead, and which ones are silently corrupting data right now.
The instinct most people have is to start fixing things. Don’t. Not yet. The instinct is wrong, and I learned this the way most people learn things, by doing it anyway and watching it not work.
What actually works is a sequence that feels too slow until you realize it’s the only one that doesn’t make the problem worse.
Map before you touch. Spend the first month producing a document that explains how the system works in its current state. Not how it should work. How it does work. Every spine workflow, every field used in scoring, every integration setting, every sync rule. You will discover, while doing this, that you don’t actually understand the system as well as you thought. That discovery is the point of the exercise.
Triage by signal, not by alarm. Not everything broken is urgent. A workflow that has 84,000 contacts enrolled and is moving 1,300 people a week into the wrong segment is urgent. A workflow that hasn’t fired since 2023 is not, even if the configuration is wrong. Sort your findings by how much data is being corrupted right now, not by what’s most visibly wrong.
Document what you find, not what you intend to do. A property record that says “this field is not used by any active flow, no dependencies confirmed in Object Manager” is more valuable than a slide deck explaining the future architecture. The first one prevents the next person from inheriting the same fog you walked into. The second one is for your stakeholders, and you’ll need it too, but the documentation that has the highest long-term return is the kind that captures the current state in writing for the first time.
Align before you change. Every structural change in a marketing ops system has stakeholders who don’t know they’re stakeholders until you change something that affects them. Sales leadership cares about routing. Demand gen cares about scoring. Finance cares about pipeline reporting. The person who runs your QBR cares about how attribution numbers move. Find them, tell them what you’re proposing, and let them push back before you ship. Surprise changes are how trust gets destroyed in this role.
The deeper lesson I took from this is that a marketing ops system that has been running for years without documentation is not a system in the engineering sense. It is an oral tradition. Knowledge lives in the heads of the people who built it. When those people leave, the system doesn’t break right away. It continues to run on momentum, doing whatever it was doing before, including the things that were already wrong. The break happens later, when someone makes a reasonable-looking change and discovers that the system has been holding together by coincidence.
The job of the person who comes in next is to convert the oral tradition into something written down. That is the unglamorous, slow, foundational work of the first six months. It is the work that makes every change afterward safer. And it is almost never how the role gets described to you when you take it.
If you are in the first month of inheriting a system, the most valuable thing you can do is the thing that looks least productive: write down what you have, before you change any of it.