Before you deploy your CDP, train your crew

I’ve said this before, but it bears repeating → CDP projects don’t just test your tech stack, they test your team. And most of the time, that test happens in real time, under pressure, with stakes that no one thought to rehearse.

After I published the piece on CDPs as a kind of digital transformation stress test, the comments and direct messages lit up with something that felt oddly familiar. People weren’t just reacting to the tech insights; the internet is filled to the brim with those. They were describing moments of confusion, panic, last-minute scrambles, and hard lessons. And that took me back to my days before data, even before Salesforce was founded.

Back to a different kind of readiness drill.

In my earlier post, This is me, who are you?, I wrote about my time in the military. What I didn’t fully explain there was how structured our preparation had to be. Before every deployment, we trained like hell. Weeks, sometimes months, of work-ups. No real missions, just simulation after simulation… after simulation. We were running drills in our dreams. Real pressure, imagined stakes. Everyone in sync.

You weren’t just practicing your own role. You were learning how your actions, or inaction, affected the next person. You drilled communications, reactions, fallback plans. You trained for the fire that never broke out. For the flooding that never happened, which of course was simulated *sigh*. For the equipment failure that, thankfully, stayed hypothetical. Because you didn’t want to figure that out for the first time when it was real.

And we didn’t do it alone. As part of a NATO member country’s military, as a dual citizen I served in both the US Navy and Royal Dutch Navy, we worked closely with allied forces. Some of them were better trained for certain things, ASW, AEW, AAW, fire control, damage containment, and when it mattered, we brought them in. They didn’t run the show. They helped us sharpen our edge and they did not kid around. You fail, you start over.

Towards the end of my military career, I served as a non-commissioned officer in communications, working with everything from semaphore and signal flags to LF/HF/UHF radios and encrypted satellite systems. My role was to process and distribute high-clearance message traffic across the command, in peacetime and in wartime simulations. There was zero room for guesswork… Crimson Tide anyone?

Everyone needed to know their role like the back of their hand and their responsibility when things got loud, fast, and unpredictable… you know, shit-hits-the-fan level events.

Some of our most intense drills took place at Flag Officer Sea Training in Plymouth, renamed to Fleet Operational Standards & Training and relocated to Portsmouth, FOST for short. It was where ships went to prepare for real deployment, and where we were pushed to operate as one unit under extreme pressure. The goal wasn’t perfection. It was cohesion. Readiness to the extreme. Knowing what to do when systems fail and time runs out is crucial. How do you fight a fire when you have lost water pressure throughout the ship?

That’s where the link back to my current work clicked into place.

Most companies love the kickoff, not the training

Here’s the thing that I have seen repeated in the research I have been doing this past year, and in discussions in my podcast, in dealings with customers, most teams don’t prepare. They kick off.

There’s a project lead, a few department heads, maybe a Notion doc or some RACI chart that looks like it means something. Then they hit the ground running, straight into integration problems, ownership confusion, data issues, and activation mistakes. And suddenly everyone’s scrambling to figure out who does what when the alarms go off.

But the issues, as I have been saying over and over again, are rarely technical. They’re team issues. Behavioral. Cultural. Collaborative. Everyone assumes someone else has trained for this. That the process is known. That the structure will hold.

It usually doesn’t.

I’ve seen CDP implementations stall because the CRM team didn’t know what "consent sync" meant, or because marketing assumed engineering had QA’d the event stream. And I’ve seen the aftermath of a misfire, or should I say misfires, a customer journey trigger gone rogue, identity mismatches causing real brand damage, activation campaigns pulled mid-flight. These are preventable errors. They’re the result of engaging in ‘battle’ before training.

And while the Martech world obsesses over composability and favorite flavor of AI, mine is Claude by the way, most teams I see still haven’t practiced the basics. With that, I mean working together under pressure.

If I learned anything from my time in uniform, it’s this:

Pressure doesn’t create discipline. It reveals it.

What a work-up could look like in business

Let’s imagine we took preparation seriously.

Before going live with a new CDP, or rolling out a major Martech initiative, the team would run structured drills. Not more alignment meetings, but actual dry runs:

Run a simulation where the identity graph breaks. See what happens when a field gets dropped from the data layer. Practice escalation when a campaign goes out to the wrong segment. Not just post-mortems after failure, pre-mortems before launch.

You’d get marketing, data, CRM, product, and compliance in a room, not to agree on vision, but to respond to a scenario. Work out protocols, communication plans, first response mechanisms. You’d find out quickly whether roles are understood, whether systems talk to each other, and whether the trust is there when things get messy.

And yes, you might bring in outside help. Not to run the project, but to help simulate failure, surface blind spots, and speed up the learning curve. The same way we brought in allies during our work-ups who had deeper experience in certain failure scenarios.

Please, don’t consider this a luxury you cannot afford. Consider it a form of respect. For the project. For the customer. For your own team.

Why I still work like a NATO partner

This is where it gets personal again. Because these days, I often find myself playing a familiar role. Not part of your standing crew, I have not done that in over 10 years, but not just an outsider either. I come in to help sharpen the edge before it gets real.

Sometimes that means running drills with your data team. Sometimes it’s helping marketing and product rehearse a crisis response. And sometimes it’s just being there to spot the blind spots that haven’t surfaced yet, the ones that usually wait until things go live.

Like those NATO allies we used to train with, or the instructors at FOST, I’m not there to run your ship. Your team needs to learn that. I’m temporarily attached to your crew. My job is to challenge internal assumptions, improve collaboration, and help your people prepare for the mission ahead. Because you don’t build readiness by reading a deck. You build it by rehearsing what might go wrong.

Because it always does.

And when it does, you don’t want your first real test to also be your last chance to get it right.

This article also marks a turning point in how I think about the project I am developing. Beyond structure, capability, and process, I’m starting to believe that response readiness, the ability to function as a team under pressure, may be the true indicator of maturity. More on that soon.

If you found this helpful, you can subscribe to my Substack and learn more about my vision of maximizing Martech value for your company. It’s free 👇🏻