When not to automate
Automating a broken process doesn't fix it. It scales the breakage. The signals that tell you to stop and fix the underlying problem before touching the workflow.
Every GTM engineer gets asked to automate things that shouldn’t be automated. The person asking is usually in pain and wants it to stop. The reflex to automate is often the wrong response.
Three situations where building automation makes things worse:
The process isn’t defined yet. If the team can’t describe what good looks like in a sequence (what triggers it, what message goes to whom, what the success condition is) then automating it produces consistent bad output at scale. Define the play first. Automate it second. The automation is a multiplier, not a design tool.
The data quality is below threshold. Enrichment pipelines running on dirty data don’t clean the data. They route bad records to the wrong reps faster. I’ve seen companies automate inbound routing before fixing their CRM and end up with more leads going to wrong reps at higher velocity. Data integrity is a prerequisite.
The org isn’t ready to operationalise it. An automated system that fires sequences the rep doesn’t know about creates confusion, not pipeline. Sales ops, the rep, and the system need to be in the same model. If there’s no clear owner for what the automation produces, the automation creates noise. Adoption is part of the build scope.
The useful question before scoping any automation: what happens if this runs perfectly? If the answer isn’t clearly better than what exists today, the problem isn’t a workflow problem.
GTM engineering isn’t about chasing automation for its own sake. The job is finding the constraint in the revenue motion and removing it. Sometimes that constraint is a missing workflow. Sometimes it’s a missing process definition, a missing data layer, or a missing agreement between sales and marketing. Automation fixes none of those.