Last week I heard Nicole Goot from Clay speak at NYU's Entrepreneurship Club, and she used a term I'd been looking for: "GTM engineer." It describes work that's become critical to startups but doesn't fit into traditional engineering or marketing roles.

Most startups get this wrong. They put product engineering at the center and treat go-to-market as something that happens after you build. This is backwards. The infrastructure for customer acquisition is often the highest-leverage engineering work you can do.

At Clique, we discovered this by accident. Most of our potential customers were in SF, but we were based in NYC. Traditional marketing felt too slow and too expensive. So I wrote a scraper for Luma, pulled data on SF events, enriched it with company information, and built automated outreach to event organizers and attendees.

This took me two days and produced more qualified leads than three months of "proper" marketing. Yet it felt improper somehow. Like we were being scrappy because we couldn't afford to do real marketing.

This intuition was completely wrong.

We develop intuitions about how much effort produces how much value. When you see enough examples of "three months of marketing work → X pipeline," you build an internal model. That model says: significant results require significant, sustained effort.

The problem is it can't distinguish between "too good to be true" and "actually just better."

When you find something genuinely 10x more efficient, your threat detector treats it the same as a mistake. You reject what works because it violates your model of how value creation should look. I call this efficiency dissonance - the psychological discomfort when something works orders of magnitude better than your baseline predicts.

After the Luma scraper worked, I kept wanting to add traditional marketing back. Not because it would improve results. But because something so simple being so effective felt wrong. I was regressing toward the baseline because the baseline felt normal.

This is effort justification in reverse. Usually we think: "I worked hard, so the results must be valuable." This is: "The results came easily, so they can't be valuable."

When you're unsure if something is real, you look for social proof. If it works this well, why isn't everyone doing it? The rational inference is: you're probably wrong.

This heuristic usually works. But it fails when the baseline is path-dependent, when the gain requires combining skills that don't traditionally go together, when the gain comes from doing less, or when the unlock is recent. In these conditions, lack of social proof doesn't mean you're wrong. It means you're early.

What Clay calls GTM engineering is not a workaround for when you can't afford a real marketing team. It's a fundamentally superior approach to customer acquisition. Modern GTM runs on APIs, webhooks, data pipelines, and automation. The separation between technical and marketing work is artificial.

This is different from growth hacking. Growth hacking was about finding exploits - game Dropbox's referral system, manipulate Reddit's algorithm, find whatever loopholes haven't been patched. Clever, but not defensible. You're always one patch away from your entire strategy breaking.

GTM engineering is building infrastructure. Not exploiting platforms, but creating systems that let you execute strategies at scale. The distinction is like picking a lock versus having a key.

At Clique we built scrapers for multiple event platforms. Lead enrichment pipelines that ran automatically. Custom demo environments we could provision instantly. Analytics infrastructure that told us what signals predicted conversion. Internal tools, invisible to customers, that made our two-person team move faster than teams ten times our size.

If your GTM is 10x more efficient than competitors, you can test 10x more strategies, learn 10x faster, iterate 10x quicker. This isn't execution efficiency. It's learning rate advantage.

Traditional competitive advantages are visible while you're building them. Brand requires public investment. Distribution requires public partnerships. Network effects require critical mass everyone can see. Infrastructure advantages are invisible until they're insurmountable. No one sees you building scrapers and automation. They see you executing strategies that seem obvious in hindsight. By the time they notice, you've compounded years of learning rate advantages.

Most engineers don't think about customer acquisition. Their mental model is: we build the product, someone else figures out how to sell it. Most GTM people are bottlenecked on tools or engineering resources. The people who can bridge both are rare and valuable.

This is a different skill set than product engineering. You're optimizing for iteration speed, not perfect architecture. You care about data integration more than code elegance. You measure success by whether it helped close deals, not whether the code is beautiful.

If you're technical and thinking about startups, this is worth considering. You don't need to be an exceptional engineer. But the combination of basic technical competence with understanding customer acquisition is rare. Most engineers can build. Most GTM people understand acquisition. Very few can do both.

And if you're starting a company, don't treat GTM infrastructure as something you'll get to eventually. Build the systems early that let you test strategies quickly and execute them at scale. The companies that figure this out will compound learning advantages that are invisible until they're insurmountable.