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 a type of work that's become critical to startups but doesn't fit into traditional engineering or marketing roles.

The distinction matters because most startups get the organizational hierarchy 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 (content, ads, conferences) felt too slow and too expensive for the capital we had. 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.

The results were disproportionate. This took me maybe two days to build 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.

Calibration Problem

We develop intuitions about how much effort produces how much value. These intuitions are trained on thousands of observations and are mostly correct. When you see enough examples of "three months of marketing work → X pipeline," you develop an internal model. That model says: significant results require significant, sustained effort.

This model protects you from measurement errors, short-term flukes, and randomness you're misattributing to your actions. 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—the scraper was already working. 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."

Social Proof Trap

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

This heuristic usually works. But it fails when:

• The baseline is path-dependent (everyone does X because that's what you do, not because it's optimal)
• The gain requires boundary-crossing (combining skills that don't traditionally go together)
• The gain comes from doing less (markets select for "try harder," not "automate away")
• The unlock is recent (impossible three years ago, trivial now)

In these conditions, lack of social proof doesn't mean you're wrong. It means you're early. But psychologically, it still triggers the "this can't be right" response.

Why GTM Engineering Exists in This Gap

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. The reason is that modern GTM has become inherently technical. It runs on APIs, webhooks, data pipelines, and automation. The separation between technical and marketing work is now artificial.

What we used to call "growth hacking" was an early version of this, but unsystematic. 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 different. You're building infrastructure for customer acquisition. Not exploiting platforms, but creating systems that let you execute creative strategies at scale. The distinction is like the difference between picking a lock and having a key.

Here's what this looked like at Clique: We built scrapers for multiple event platforms. Lead enrichment pipelines that ran automatically. Custom demo environments we could provision instantly for prospects. Analytics infrastructure that told us what signals predicted conversion. These were all internal tools, invisible to customers, but they made our two-person team move faster than teams ten times our size.

The peculiar thing is that Clique itself was a GTM product—we were building infrastructure for how companies reach customers. Yet even we had this mental partition where product engineering was "real" engineering and GTM tooling was something you did when you couldn't afford proper resources.

The reality is that GTM infrastructure is often higher-leverage than product features. A good internal tool can make your entire GTM team 5–10x more productive. A product feature might improve some metric by 10–20%. The expected value calculation is obvious, yet most startups systematically underinvest in GTM tooling.

Compounding Advantage

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

Traditional competitive advantages take years to build and are visible while you're building them:

• Brand requires consistent investment and public visibility
• Distribution requires partnerships and public integrations
• Network effects require hitting critical mass that 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

This is why GTM engineering sits in the gap created by efficiency dissonance. It works dramatically better than baseline approaches, which triggers distrust. It requires boundary-crossing between technical and commercial work, which violates organizational structures. It looks like "doing less" because it's automation, which markets code as laziness. And the unlock is recent—AI and modern APIs made this trivial in the last few years.

Why Most Startups Miss This

Most engineers don't think about customer acquisition. Their mental model is: we build the product, someone else figures out how to sell it. This made sense when GTM was mostly non-technical (cold calling, direct mail, trade shows). But modern GTM is increasingly technical work.

Most GTM people are bottlenecked on tools or engineering resources. They depend on engineers to build things for them, or they're limited to what off-the-shelf tools can do.

The people who can bridge both worlds are rare and valuable. This is a different skill set than traditional product engineering—you're optimizing for iteration speed and learning velocity, 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.

GTM infrastructure comes in two forms. First, there are tools for your team (scrapers, automation, custom workflows, internal dashboards). The stuff that makes two people feel like twenty. Second, there's GTM built directly into your product (invite mechanics, share features, embeds, public profiles, export options). All the things that make your product itself a distribution channel.

Most engineers treat distribution as someone else's problem. Most GTM people treat technical infrastructure as something they have to wait for engineers to build. The people who can do both are bridging a gap that shouldn't exist in the first place.

Pattern

This is becoming a distinct role, similar to how "growth engineer" evolved from a weird Facebook thing into a standard position. The pattern is the same: a skill combination that seems niche at first but turns out to solve a fundamental problem that every company has.

Most startup advice optimizes for reducing false positives: don't chase shiny objects, focus on fundamentals, trust proven playbooks. This is good advice because most people overweight novelty. But it creates a filter. People who need social proof and proportional effort-to-value ratios self-select out of high-variance strategies.

I spent a year at Clique playing it safe while accidentally discovering moves that worked dramatically better, then reverting because they felt wrong. Now I recognize efficiency dissonance as a signal rather than a warning.

Practical Implications

For Metalworks, this changes everything. Not product first, then figure out distribution. Build them together—what can we create that makes distribution easier? What infrastructure do we need to test GTM strategies in hours instead of weeks?

When something works 10x better than baseline, my first instinct is still suspicion. But I recognize that as a prior to update, not a conclusion to accept. The feeling "this can't be right" is information about my model, not about reality.

The work is more interesting than pure product engineering. The feedback loops are immediate. You build something, measure whether it brings in customers, iterate. No waiting six months to see if a feature moved an engagement metric by 2%. The connection between what you build and whether the company succeeds is direct and obvious.

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 and valuable. Most engineers can build. Most GTM people understand acquisition. Very few people can do both.

And if you're starting a company, don't make the mistake I made with Clique. 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.