My GTM engineer shipped forty new automations by month two. It took me until month four to admit I couldn't tell you which ten of them actually mattered.
That's the uncomfortable thing about this hire that nobody puts in the job posting: unlike a sales rep, a GTM engineer doesn't have a close rate. Unlike a marketer, they don't have a campaign with a CAC you can point to in a board deck. Their output is infrastructure, and infrastructure is invisible right up until it breaks, or until a quarter goes by and you realize revenue didn't move any faster than before you spent $150K-plus on the hire. If you're three months into this hire and grading them on vibes, they seem busy, the dashboards look nice, you're not actually measuring anything.
Why revenue is the wrong first metric
The instinct is to wait for pipeline or closed-won to move and call that the scorecard. Don't. A GTM engineer's systems sit upstream of revenue by weeks or months, through lead flow, sequencing, and rep behavior, before a dollar shows up anywhere. Waiting for revenue to grade the hire means you find out you made a bad one two quarters late, after the runway's already spent. You need proxy metrics that move in week one, not quarter two.
The six proxies that actually tell you something
Here's what I track now, and what I wish I'd tracked from day one. First, manual-touch reduction: count how many leads a human has to touch by hand to move from form-fill to a qualified conversation, week over week. If that number isn't dropping by week three or four, the automation isn't replacing work, it's just adding a layer on top of it. Second, data completeness: what percentage of new leads have accurate firmographic and contact data attached without anyone touching a spreadsheet. We went from 40% to 91% coverage in six weeks once ours was doing his job; if that number is flat, the enrichment pipeline isn't actually running.
Third, time-to-routing: how long between a lead entering the system and landing in the right rep's queue. Ours dropped from an average of six hours to four minutes. That single number is worth more than a stack of automations, because speed-to-lead is one of the few things in sales with genuinely brutal, well-documented math behind it, leads contacted within five minutes convert several times more often than leads contacted half an hour later. Fourth, experiment velocity: how many distinct GTM tests, a new sequence, a new routing rule, a new enrichment source, actually shipped and got measured in a month. A good GTM engineer should be running three to five small experiments a month once the core systems are stable. If they're still building the same one system in month three, something's stuck.
Fifth, and this one's uncomfortable to track but worth it: silent failure rate. Automations don't announce when they break, they just quietly stop enriching, stop routing, stop firing, and everyone assumes the pipeline's just slow that week. Ask your GTM engineer to show you their own error monitoring, not just their build list. If they don't have one, that's the finding. Sixth, ask your reps directly, not your GTM engineer, how many hours a week of manual list-building, data entry, or lead qualification they've gotten back. That number, self-reported by the people actually doing the work, is the closest thing to ground truth you'll get.
The read at 30, 60, and 90 days
At 30 days, you shouldn't expect new systems, you should expect an audit: a written map of every manual step in your current GTM motion and where the biggest time sink is. If they're already deep into building in week two without that map, that's a candidate who automates first and diagnoses never. At 60 days, one full system should be live end to end, not five half-built ones. At 90 days, at least three of the six proxies above should show a measurable, specific number you can say out loud in a board meeting.
The red flag that looks exactly like progress
The failure mode I didn't expect is complexity that looks like output. A GTM engineer under pressure to show value will sometimes build more instead of building what matters, a dozen new tables, a tangle of automations nobody else on the team understands or can maintain if this person leaves in six months. Ask, every 30 days: if you left tomorrow, could someone else run this? If the honest answer is no, you don't have infrastructure, you have a single point of failure with a fancy title.
Grade this hire on the six proxies, not on your gut and not on revenue you won't see for months. If none of them are moving by day 60, that's not a slow ramp, that's your answer.