Free: the GTM BlueprintThe stack, by funding stageThe CRM data model, written downSeven steps, six handoffsRoles, and when to hire themA 90-day plan you can run on MondayThe three numbers that decide itNo PDF, no drip sequenceGet the blueprintFree: the GTM BlueprintThe stack, by funding stageThe CRM data model, written downSeven steps, six handoffsRoles, and when to hire themA 90-day plan you can run on MondayThe three numbers that decide itNo PDF, no drip sequenceGet the blueprint
RevOpsXL
GTM Diagnostic Book the audit

Everyone says the system is basically fine. It just needs a few tweaks.

Five names for one company. The top rep’s private pipeline. The beautiful dashboard on the team that’s furthest behind. None of it was stupid — that’s the confession.

On this page

Every engagement starts the same way. Someone tells me the system is basically fine. It just needs a few tweaks.

It is never a few tweaks.

So here is what it actually is. I have caused some of these myself, which is why they’re confessions rather than complaints.

One company, five names, four opinions about punctuation

Acme Corp. Acme Corporation. ACME. Acme Corp (do not use). acme.

Five records. One company. Every one of them created by someone doing their job properly, because nobody ever told them a rule existed. Then someone runs a report on customers by account and the number is wrong, and the instinct is to blame the report.

The report is fine. The report is the only honest thing in the room. Cleaning it up is a governance problem wearing a data problem’s coat.

The adoption number is forty per cent and everyone calls it a training problem

It is not a training problem. People are extremely good at learning systems that help them. Nobody needs a workshop to learn their phone.

Forty per cent adoption means sixty per cent of your team found a faster way to do their job, and the faster way is a spreadsheet. They are not being difficult. They are being efficient, in the only direction the system left open. A CRM built for everyone gets used by no one.

The feature one team begs for is the feature another team quietly hates

Sales wants a field. It takes four seconds and it saves them a conversation.

Marketing hates that field, because it’s free text, and free text means the segmentation is now a guess. Both teams are right. Both are advocating correctly for their own work.

Nobody in the room is wrong, and the meeting still ends badly, because the actual question — what is this field for, and who has to live with it — is an architecture question and there is no architect in the meeting. So it gets decided by whoever is more senior or more tired.

The top rep gets whatever they ask for

And they should be listened to. They’re closing. They know things.

But it starts as one exception. A stage that only makes sense for their deals. A rule that skips their pipeline. A field only they fill in. Every one of those is granted for a good reason, by a manager protecting the number, and each one is individually defensible.

Then you have a system with a dialect. And the forecast can’t roll up, because two pipelines mean different things by the word “proposal,” and now nobody can tell you what’s real. You optimised for the person who needed the least help and made the system worse for everyone who needed the most.

“We need more sales” before anyone has asked what caused the last ones

The target goes up. The activity goes up. The headcount goes up.

Nobody can tell you which of last quarter’s deals came from the same place, because source was overwritten at some point by a rep who typed what they remembered. So you scale effort instead of scaling the thing that worked, and effort doesn’t compound.

You can’t do more of what’s working until someone can say what worked. That’s not a philosophical point. It’s a field on a record.

The team that’s furthest behind has the most beautiful dashboard

This one is almost a law.

Impressions. Reach. Emails sent. Meetings booked. All up and to the right, all technically true, and not one of them is a decision anybody could make differently on Monday.

Vanity metrics aren’t dishonesty. They’re self-defence. When the real number is bad and nobody feels safe, people report the numbers that are good — and they genuinely believe they’re being useful. The dashboard is a symptom of the culture, not the cause. Fix the culture and the dashboard fixes itself, which is annoying, because the dashboard is much easier to fix.

The migration happened and the cleanup didn’t

Everyone agrees the data needs cleaning. Everyone agrees it should happen before the move. Then the date gets set, the date gets close, and cleanup becomes the thing that can slip, because it’s the only task with no external dependency.

So the duplicates cross the border. And now you’re cleaning inside a system nobody trusts yet, where every fix looks like a migration bug. The order matters more than the effort.

The tool was announced on a Thursday

Somebody senior saw a demo. It was a good demo. They were right that the current thing is bad.

And the switch is announced with a date and no map: nobody has asked which workflows run through the old tool, what writes to it, who reports from it, or which of the four integrations nobody remembers setting up will quietly stop firing. Three weeks later something breaks that nobody connects to the change, because the change was three weeks ago.

The tool wasn’t the problem. The tool is never the problem. It’s that a stack is a system, and you can’t swap an organ by announcing it.

You made the field required, so now every deal says n/a

The data was missing. Making it mandatory is the obvious fix, and it works: the field is now one hundred per cent complete.

It is also one hundred per cent worthless, because you didn’t create information, you created a toll booth. And people pay tolls with whatever’s in their pocket. In this case, “n/a,” “.”, and “asdf.”

A required field only works when the person filling it needs the answer too. Otherwise you’ve just moved the missing data somewhere harder to find.

The integration nobody owns

It was set up by someone who left. It runs on their API key. It writes to a field three reports depend on.

Nobody knows it exists until it stops, and it stops on a Friday.

The quick fix that became the architecture

It was meant to be temporary. It was a workflow, built in an afternoon, to get through a launch.

It is now load-bearing. Two other things depend on it. Nobody documented it because it wasn’t going to last. That was two years ago and it has a nickname.

Every system I’ve ever audited has at least one. Usually the person who built it is embarrassed about it, which is the wrong reaction — it worked, and it lasted, and those are the two hardest things in software. They should be annoyed nobody replaced it.

The part I’m least comfortable with

None of these were stupid. That’s the confession.

Every one of them was a reasonable call, made by a competent person, on a Tuesday, with too much to do and no time to think about the second-order effect. Nobody set out to build this. It arrived one sensible decision at a time, and each decision was defensible on the day it was made.

Which is why the answer is never a few tweaks.

If you’re now wondering what fixing it actually involves, the FAQ covers the scope, the pricing and how an engagement runs.

If more than three of these landed, the problem isn’t any one of them. It’s that nobody owns the shape of the whole thing.

Book a RevOps diagnostic session Run the GTM diagnostic

Get the next one

New field notes twice a month. We don’t do newsletters — follow RevOps XL on LinkedIn instead.

Follow on LinkedIn

Sound familiar?

If this is happening in your stack, tell me about it. A senior expert reads these, not a bot — and you’ll get a real answer, whether or not you ever hire us.

← More field notes