The empty seat: why GTM engineer reqs stay open

Why does a GTM engineer req stay open for half a year?

One company in our pipeline this year arrived with a GTM engineer req that had been open since spring. Nobody was treating it casually. They had built an interview case study out of their real problem, brought candidates through to the final round, and watched the process collapse there more than once, always at the moment the questions stopped being technical. After the most recent of those interviews, the company's technical leader reached the conclusion that finally changed the search. She could probably build the system herself. She could not confidently hire someone else to.

Everyone in that story behaved sensibly. The req was thoughtful, the candidates were real professionals, and the interview design was more rigorous than most. What was missing was a definition. The role is new enough that nobody has written down what good looks like, and the people who would have to write it are the same people trying to hire for it. The req stays open because the definition is missing, and the definition is missing because producing it is most of the job.

That reading is generous to everyone involved, and we think it is also the accurate one. This post lays out what our own coded sales conversations show about the empty seat, what the open req costs while it stays open, and how the search resolves, with the limits of our data stated plainly along the way.

Why is the role unhireable as written?

The work a GTM engineer req describes is decisions, not implementation. Which accounts belong in the first tier. Which records are excluded, and who owns the exception when the system is unsure. Whether the list refreshes on a schedule or by hand. What the system is allowed to decide without asking a human. A competent builder can implement any answer to those questions in days. The req is quietly trying to hire the answers themselves.

The candidate market makes this harder in a specific way. In our conversations with hiring managers, two archetypes come up again and again. Technical candidates who have never worked in marketing gravitate toward systems built behind their own stack, optimized for cost, that nobody else can log into. Marketing candidates carry deep judgment in one lane and have never had to wire two systems together. When we described that split to one marketing leader mid search, her response was that she had been circling the same thought, that the role might genuinely be two roles. We agree, and one GTM engineer is not a capability is the long version of the argument: the smallest unit that ships a capability is an executive sponsor, a subject matter expert, and a builder, and a single req is trying to compress all three into one salary band.

The final round collapse follows directly. Early rounds test skills, and skills are testable. The final round tries to test judgment against a specification nobody has written, so the process fails at the last step, each time for a different visible reason, and after two or three repetitions the pattern starts to read as a talent problem. One marketing leader in these conversations described the state this produces, "I'm just a little bit suspicious of everybody." Her real question was sharper than that. Were those candidates weak, or is the role simply not hireable yet? That question has no answer until someone writes down what the job decides.

What did our 11 coded sales conversations show?

We went back through our 2026 meeting archive, screened 420 meetings, and kept the 11 that were sales conversations, meaning calls where we were pitching or scoping rather than delivering. We coded each one for two facts. Did an unfilled or under-resourced seat come up in the conversation, and did a dated event. A seat appeared in 8 of the 11. A dated event appeared in 8 of the 11. Both together appeared in 5. And no conversation arrived with neither.

Two coding rules matter for reading the table. A seat counted as present when the conversation named an unfilled role or a function running under-resourced: an ads contractor never replaced, a marketing team of one, a sales leader on leave. A date counted as present when the event had a calendar position, a board meeting, a launch month, a proposal deadline. Halves that appeared only weakly, a company that is always hiring, a counterpart returning from leave at some unstated point, were coded as absent in the totals.

Crossing the two halves makes the shape easier to see. The conjunction we once treated as the whole trigger holds in fewer than half of the conversations. Each half on its own shows up in roughly three quarters. And the quadrant with neither is empty.

Does the empty seat cause the conversation?

We coded this data to test our own earlier claim, formed on a five call sample: that the window opens only when the seat and the date arrive together, and that either alone stalls. The 11 call table does not support it. With both halves present in fewer than half of the conversations and each half alone in about three quarters, the empty seat looks less like a selection signal and more like a description of the market that talks to us. Nearly everyone who takes this kind of call has a seat problem somewhere.

The refinement that did survive the coding is about timing. The seat qualifies, the proximity of the date times it. The conversations that moved carried a specific near date, a board meeting the next day, a CFO meeting that week, a proposal due in five days. The conversations anchored to vague end of year goals sat still. On our data, an open req plus a dated event is the ordinary shape of the moment a company starts talking to firms like ours, and the date is the half doing the scheduling.

What does the open req cost per month?

An honest dollar figure does not exist for this, and we will not invent one. The costs we can observe directly in these conversations are paid in two other currencies, time and decision debt, and they accrue monthly whether or not anyone books them.

definitionDecision debt

The backlog of decisions a role exists to make, accumulating while the seat is empty. It behaves differently from a work backlog. Work waits for hands, and a contractor can burn it down. Decisions wait for an owner, and while they wait, defaults decide instead: the tier nobody defined, the exclusion nobody wrote, the routing rule inherited from a different quarter. Every one of those defaults is a decision too, made by nobody, and the eventual hire inherits all of them on top of their own ramp.

The time cost is the visible half. Somewhere in the org, a leader is covering the seat on top of the job they were hired for. In one account in our pipeline, the growth manager had been covering paid since a contractor left in the spring, and described the channel, in her own words, as neglected for most of the year. That is what interim ownership looks like from inside. The channel stays technically alive, and every decision about it gets deferred.

The decision debt is the half that compounds. The scoring model is the cleanest example. When one finally gets built, by the eventual hire or by anyone else, it fails in a predictable way if the tiers were defined in a vacuum: the reps who work the leads never helped build them, so the score populates a field and changes nothing. The reps have to define the tiers before anything gets built, and the open req is burning exactly the period in which that could be happening.

The last row of that table is the one that changes behavior. Interim hours come back when the seat fills, and a decayed channel can be rebuilt. The board meeting does not reschedule because the req is open. In our coded conversations, a specific near date was what separated the conversations that moved from the ones that sat, which is another way of saying the calendar was making the decision the org had not made yet.

What resolves the search?

The choice is usually framed as hire versus buy, and we wrote the full decision out at GTM engineer or agency. The version that matched the conversations that closed for us is a parallel path rather than a fork. Start now with a team that has stood the system up before. Keep the search running in the background. Plan the overlap and the step down in writing, so the outside cost has a stated end date and the handoff is on the calendar from day one.

Two things about that shape do the work. First, everything gets built in the company's own accounts and runs without us, so the engagement lowers key-man risk instead of relocating it to a vendor. Second, it dissolves the definition problem as a side effect. By the end of the four month sprint we describe at how we work, the workflows exist, the rules of engagement are written down, and the tiers were defined with the reps who work them. At that point the req can stop asking one person to be a specification, a sponsor, and a builder at once, and start describing a real job: own this running system and extend it.

Hiring changes character at that point too. Interviewing against a running system is a different exercise from interviewing against an unwritten spec. You can walk a candidate through the actual routing logic and ask what they would change, and the answer separates candidates in a way no case study built on a hypothetical can. The final round stops collapsing because the thing it was trying to test finally exists.

The empty seat, on our data, is close to universal among the companies that end up talking to us, so we treat it as qualification rather than urgency. The date is the part with a deadline. If there is a board meeting, a launch, or a proposal on your calendar, the months between now and then are the period the open req is currently spending, and decision debt is the one line on that bill that never recovers.