what a go-to-market engineer actually does

the role nobody posted a job listing for

I was an SDR. 200 emails a day. manually building buying committees in spreadsheets. copy-pasting templates. warming domains the wrong way and tanking sender reputation before I understood what sender reputation was.

the work taught me everything. not the tools, the domain knowledge. I learned what makes someone reply. I learned what data you actually need on a lead before you reach out. I learned that most outbound fails not because the message is bad, but because the targeting is lazy.

then I started automating. first it was spreadsheet formulas. then basic scripts. then full pipelines with enrichment waterfalls, qualification logic, and automated routing. the SDR work didn't go away. it got compressed into systems that run while I sleep.

that's what a go-to-market engineer is. someone who took the tribal knowledge from doing the work and turned it into infrastructure. not a developer who read about sales. not a marketer who learned to code. an operator who got tired of clicking.

the evaluation layer

the first thing I do in any engagement is evaluate the stack. not by brand name or pricing page. by automation ceiling.

I run every tool through an MCP + CLI litmus test. three levels: does it have an API? does it have a CLI? does it ship an MCP server? a tool stuck at GUI-only has a ceiling. you can hire more people to click, but you cannot scale the process.

then I look at cost transparency. most teams have no idea what they spend per lead, per campaign, per pipeline dollar. they buy 10,000 credits and watch them disappear without attribution. I implement credit tracking in the first week of every engagement. a simple layer that logs spend per campaign alongside outcomes. campaign A burned 2000 credits for 8 meetings. campaign B burned 3000 credits for 2. the decision is obvious when you can see it.

the third piece is storage architecture. most GTM teams treat enrichment as a per-campaign expense instead of a compounding asset. you enriched 500 leads last quarter. 200 of them overlap with this quarter. you just paid twice. a data lake approach turns enrichment into an investment that compounds over time instead of a cost that resets every campaign.

the agency gap

I see the same pattern in almost every engagement. the company hired an agency. the agency runs campaigns. the campaigns produce activity. activity does not equal pipeline.

the structural problem is incentive alignment. agencies bill for campaigns shipped, not pipeline generated. they are optimizing for their metric, not yours. that's not malice. that's business model mismatch.

I built an agency evaluation checklist after auditing enough stacks to see the pattern. eight questions that separate agencies building real infrastructure from agencies running generic playbooks. who owns the tool logins? can you export the data? is the workflow documented?

the biggest red flag is workspace ownership. if your agency runs campaigns from their accounts using their logins, you own nothing. two years of outbound data, campaign performance, enrichment results, all living in someone else's infrastructure. if you leave, you start from zero.

this isn't a knock on agencies. some are excellent. the checklist exists because most founders don't know what questions to ask.

the independent model

the reason I work as an independent consultant instead of an agency is structural.

agencies retain clients through dependency. the retainer continues because the client cannot operate without them. I build in client accounts from day one. every login, every workflow, every piece of data belongs to the client. documentation is written as the system is built, not after. when the engagement ends, the client has a running system with full ownership.

there's a defined endpoint. audit the stack, recommend tools, build the infrastructure, transfer ownership, leave. no ongoing retainer for maintenance. no quarterly reviews that justify continued billing. you either built something that runs independently or you didn't.

the tool evaluation framework applies the same principle. I don't recommend tools based on partnerships or commissions. I recommend what fits the client's volume, budget, and technical capacity. sometimes that means Clay. sometimes that means a spreadsheet and Apollo. sometimes that means they don't need to buy anything new at all.

that independence is the value. same tribal knowledge. aligned to your outcomes, not anyone's retainer.