I Don't Want to Sell You a Data Transformation

Five principles shaped by years of finding what actually needs to change - and what doesn't.

There’s a funny thing about expertise.

The more experience you have, the easier it becomes to walk into a room already convinced you know the answer.

I’ve been on both sides of that table.

I’ve listened to smart people arrive with polished decks, proven frameworks, industry benchmarks, and a suspiciously convenient solution that happens to align perfectly with what they sell.

Sometimes they’re right.

And sometimes I’m mentally wondering whether we’re even talking about the same business.

Expertise should help us recognize patterns. It should help us know where to look and what questions to ask. It should not give us permission to skip the part where we understand what is actually happening.

That distinction has always mattered to me and remains paramount as I build SynergyWorks.

I don’t want to build a consulting practice around having the answer.

I want to build one around knowing how to find the way forward.

That thinking is rooted in my core principles.

Not corporate values destined for a poster. Not a five-step proprietary framework with a clever acronym. And definitely not rules carved into a stone tablet. (Though, admittedly, I have committed pretty hard to the rock theme.)

They’re guardrails for the work.

1. Come informed. Stay curious. Find the way forward.

There is no prize for walking into a meeting knowing absolutely nothing.

If your company has a website, I’ve read it. If you’ve announced a new strategy, launched a product, changed leadership, entered a market, or talked publicly about where you’re headed, I want to know that too.

That’s homework.

It isn't discovery.

Research can tell me what your business says it does. It cannot tell me that three people manually reconcile the same customer information every Friday because nobody trusts the system. It won't tell me that a “temporary” spreadsheet became mission-critical eighteen months ago. And it definitely won't tell me that everyone quietly asks Maria before changing anything because Maria is the only person who knows how it really works.

That requires curiosity.

There’s a difference between bringing expertise into the room and bringing a conclusion into the room.

Funny enough, one of the first times I remember feeling truly seen for working this way was during a major integration project at Bloomberg.

I had been brought in to fix a problem. So I investigated the problem.

Apparently, that wasn't as obvious as it sounds.

One afternoon, an executive reminded me to take a break and enjoy the salad sitting neglected at my desk. He told me he'd already been through at least three other “fixers” before me. I was the first one, he said, who hadn't walked in assuming I knew the solution.

I had asked questions. Followed the problem. Tested what I thought I knew. And let the answer emerge from what I found.

A few weeks later, he made a short phone call on my behalf. It resulted in a job offer I hadn't expected and, for reasons unrelated to the compliment, couldn't accept.

The offer wasn't really the important part.

Someone I respected had recognized the value in not rushing to prove I had the answer.

That stuck.

Come informed. Stay curious. Find the way forward.

2. Stay with what the business needs to do - not what the data needs to do.

Data doesn't wake up on Monday morning with quarterly goals.

Your business does.

Your people do.

And yet somewhere along the way, it became remarkably easy for organizations to start talking about data as though it has objectives of its own.

“We need a data lake.”

“We need better dashboards.”

“We need AI.”

“We need a new CRM.”

Maybe!

But what does the business need to be able to do that it cannot reliably do today?

Know which customers are profitable?

Launch a new line of business?

Understand capacity before hiring?

Close the books without an archaeological expedition?

Give five people the same answer to the same question?

Start there.

The Why and the What give meaning to everything that follows - how your people, processes, data, and technology work together as a system.

Otherwise, we risk solving a perfectly legitimate data problem that wasn't actually the business problem.

Stay with what the business needs to do - not what the data needs to do.

3. Agree on the principle. Question what gets in the way.

This may be my favorite place to work, every single time.

“We all agree customer information should be entered here.”

Great.

Does that happen?

Well...

And now we're getting somewhere.

I love when we can agree in principle but not in practice, because the gap is useful information.

Why aren't people following the process?

Is it too cumbersome?

Does another team need the information differently?

Are people measured against a goal that unintentionally rewards the workaround?

Does the official process make perfect sense on a diagram and absolutely no sense on a Tuesday afternoon when six customers are waiting?

Or have leaders simply tolerated the workaround long enough that it became the real standard?

I’ve written before that what you tolerate, you maintain. But finding a gap doesn't mean we immediately blame the people living inside it.

We question what gets in the way.

Sometimes the problem is behavior. Sometimes it’s process. Sometimes information is missing. Sometimes the technology genuinely stinks.

And sometimes two perfectly reasonable parts of the business are rubbing against each other and creating a whole lot of sand.

Always, always, always find the friction before prescribing the fix.

Agree on the principle. Question what gets in the way.

4. Today's solution shouldn't become tomorrow's problem.

I've already confessed my complicated history with the phrase Quick Win. You can read that particular rant in Beware: Buzzwords Can Bite!

The short version: I've learned that quick isn't the problem.

Quick can be smart. Practical can be smart. Phased can be smart. A spreadsheet can even be the right answer.

What matters is understanding the trade-offs.

Does today's shortcut create a dependency nobody will remember?

Does this fix require someone to maintain it forever?

Are we eliminating friction or simply relocating it?

Are we solving the problem or making it quieter?

Today's solution doesn't have to be perfect. It just shouldn't quietly become tomorrow's problem.

5. Make just enough change to matter - and to last.

This one took me the longest to put into words.

Because just enough can sound suspiciously like do the minimum.

That is not at all where I'm coming from!

There is a unique confidence that comes from knowing what not to do.

Think about an expert craftsperson, an artist, a great editor. Their work isn't necessarily distinguished by how much they add. Often, it's distinguished by what they're willing to take away.

Simplicity can look easy from the outside.

It rarely is.

It takes experience to know what is essential. It takes judgment to know what can safely disappear. And it takes confidence to stop when adding more would make the result worse, not better.

Sometimes simplicity is what decades of experience look like.

I think the same is true of meaningful business change.

Organizations can absorb only so much at once. People still have jobs to do while we're redesigning how those jobs get done. There are budgets, dependencies, competing priorities, customer commitments, learning curves, and plain old human behavior involved.

Too little change and nothing meaningfully improves.

Too much and the organization can't absorb it.

The skill is knowing the difference.

Maybe we change one critical definition instead of redesigning an entire operating model.

Maybe we fix ownership before buying technology.

Maybe we intentionally leave a perfectly imperfect process alone because another Big Rock matters more right now.

And maybe the most experienced person in the room isn't the one proposing the biggest transformation.

Maybe she's the one who knows what can be taken away, what must remain, and where enough really is enough.

Make just enough change to matter - and to last.

That's not thinking small.

That's knowing enough to respect the system you're changing.

Principles Before Practice

Years ago, if you asked me where I would start a long-term Data Governance program, my answer wouldn't have been a masking standard, a client master, or an operating model.

I would have told you to start with principles.

And I stand by that advice today.

Because data governance is change management. Data strategy is change management. Most meaningful business transformation eventually becomes change management.

An email announcing the new process has never magically made human beings change their behavior.

We need something sturdier to come back to when the easy answer and the right answer aren't the same.

That's what these five principles are for.

They remind me to do the homework without assuming I know the story.

To keep the business need bigger than the data problem.

To get interested when principle and practice don't match.

To look beyond the immediate fix.

And to resist changing more, simply because we can.

There will always be another framework. Another tool. Another trend. Another perfectly polished answer looking for a problem.

I'd rather ask better questions.

That's usually where the interesting stuff starts.