Ask three people on a sales team how many qualified opportunities there are this month and you’ll get three numbers. Not because anyone is lying, but because each one is reading a different system: the CRM, the spreadsheet the SDR team keeps, and the enrichment tool’s dashboard.
The instinct is to blame the tools. The actual cause is that nobody decided which one wins.
What one write path means
A single write path means exactly one system is allowed to be edited by a human, and every other system is a read-only projection of it. Everything else is a job that either succeeds or alerts.
This is stricter than it sounds. It means the spreadsheet goes away, or becomes a generated export that nobody edits. It means the enrichment tool can propose a field but can’t overwrite one. It means when two systems disagree, the disagreement isn’t resolved by whoever looked last, it’s resolved by rule.
The cost is real: people lose the small freedoms they were using to work around the system. Someone who has been tracking their own pipeline in a sheet will resist, and they’re not wrong to, because the sheet was faster for them. The reason to take it away anyway is that their speed was being paid for by everyone else’s confusion.
The failure mode nobody notices
Sync jobs fail quietly. A token expires, a field gets renamed upstream, an API starts rate-limiting at a different threshold. The job doesn’t crash, it just stops moving records, and the dashboard keeps rendering the last good state. Two weeks later someone notices that no deals have been created since the 14th.
A pipeline you can’t trust is worse than no pipeline, because it produces confident decisions from stale data.
So instrument it like production infrastructure. A record count per day, an alert if the job writes zero rows, a freshness timestamp on every dashboard that shows when the data was last verified. A dashboard without a freshness stamp is a decoration.
The order of operations
Teams usually want to start with reporting, because reporting is what hurts. That’s backwards. Build the write path first, then the reporting is a query rather than an assembly job.
- Pick the system of record. Usually the CRM, occasionally a database that feeds it.
- Define the schema: only the fields a decision depends on. Every extra field is a field that will disagree.
- Migrate and dedupe. This is the part that takes the time nobody budgeted.
- Close every other write path. Revoke the API keys that allow it.
- Build the sync jobs with alerting from day one, not after the first failure.
- Then build dashboards, each stamped with its freshness.
What it buys you
The obvious win is a number everyone trusts. The less obvious one is speed: when the data is right, you can change a segment rule, a scoring threshold or a sequence and see the effect the same week. When it’s wrong, every experiment is inconclusive, so nobody runs any, so nothing improves.
Data plumbing is the least visible work in growth and the highest leverage. It doesn’t demo well. It just makes everything downstream stop lying.
Written by the Max Momentum team.
See GTM engineering