A recruiter posted a thread in r/gtmengineering recently that sorted the people now hired as GTM engineers into four types. There's the AI growth marketer who builds campaigns out of workflows. There's the RevOps person who grew into the title. There's the former AE who automated their own prospecting and now does it for a team. And there's the data builder, the one who lives in warehouses and APIs.
The comments added a fifth: the customer success or account management builder who automates expansion and renewals. Then they argued for a while about whether the ex-AE "rainmaker" is really an engineer at all.
It's a useful map. Read it again, though, and look at the inputs each archetype works with. Firmographics. Technographics. Intent. Job changes. Website visits. Product usage. Enrichment waterfalls.
Nobody in the thread mentions the one input that decides whether a buyer actually reads the message: who already knows them.
Why relationship data never makes it into the stack
It isn't because GTM engineers think it doesn't matter. Ask any of them whether a warm intro converts better than a cold sequence and they'll say yes before you finish the question.
It's missing for three practical reasons.
You can't buy it. Every other column in the stack comes from a vendor. Relationship data comes from your own people: your team's inboxes and calendars, your customers, your investors and board, your partners. No provider sells "who at your company knows the CFO of this account", because nobody outside your company has it. In the signal ladder we use, this is the fourth rung, the one competitors can't see.
It doesn't look like a row. Firmographics are one row per account. A relationship is an edge between two people, with a strength, a history and a willingness to help that changes over time. Most GTM tables have nowhere to put that.
It has a budget. You can send a thousand cold emails without asking anyone's permission. You can't ask your board member for a thousand intros. Relationship data is the only input in the stack where using it costs someone else something, so it needs rules that enrichment data doesn't.
What the relationship column actually contains
If you were adding relationship data to a GTM table today, this is the minimum it needs. One row per path, meaning one connector to one target person:
- Target: the person you want to reach, linked to the account and the opportunity if there is one.
- Connector: who knows them, and which network they come from (team, customer, investor or board, partner).
- Relationship type: worked together, sold to them, invested together, sat on a board, went to school together.
- Strength: a score built from recency, frequency, depth and reciprocity of real interactions. Our connector score glossary covers how that is usually built.
- Last ask: when this connector was last asked for an intro, by whom, and what happened.
- Willingness: whether the connector has opted in, opted out, or set limits on what they will pass on.
- Outcome: asked, accepted, intro made, meeting held, opportunity created.
The last three columns are the ones most teams don't have, and they're the ones that keep the channel alive. Without "last ask" you burn your best connectors. Without "outcome" you can't prove the channel to finance. And once a workflow finds 30 paths into one account, you need a rule for which three to use.
The play each archetype would build
The interesting part is that every archetype in that thread already has a workflow where this column changes the result. Here's where it slots in.
The AI growth marketer
Builds signal-triggered campaigns: a funding round or new executive fires a sequence.
The relationship play: before the sequence fires, check for a path. If one exists above a strength threshold, route the signal to the connector as a drafted ask instead of to the cold sequence. Cold becomes the fallback, not the default. Same trigger, different sender.
The RevOps to GTM engineer
Owns routing, territories and the CRM.
The relationship play: assign accounts by path strength first and territory second. The rep whose manager used to work with the buying committee should get the account, even if it sits one zip code outside their patch. RevOps people also tend to be the ones who should own the connector budget: caps per connector per month, cooldowns after an ask, and an opt-out list that every workflow respects.
The AE turned rainmaker
Automated their own pipeline and now packages it for the team.
The relationship play: multithreading. For every open deal over a set size, list the people on the buying committee the team hasn't reached yet, find a path to each, and draft the ask for the connector. This is the archetype most likely to have done it by hand already. The job is to make it run without them.
The data builder
Lives in the warehouse, builds scoring models and APIs.
The relationship play: add path strength as a feature in the account scoring model and measure the lift. Accounts with a strong path should score higher than accounts with the same fit and intent but no path, and the model should be able to say so. Then expose it: a relationship lookup that any other workflow can call, over an API or an MCP server that Claude or ChatGPT can query directly.
The CS and account management builder
Automates renewals, expansion and health scoring.
The relationship play: two of them. First, watch champions. When a happy user changes jobs, that's a new account with a warm path already in it, the core of champion tracking. Second, ask at the right moment. A customer who just hit a milestone or gave a strong review is the best connector you'll get all year, and a workflow can catch that moment and draft the ask for the CSM.
Where to start if you're the GTM engineer
Don't start with the model. Start with one workflow and one rule.
- Pick the workflow that already fires the most outbound, usually the signal-triggered sequence.
- Add one check before it sends: is there a path into this person above your strength threshold, from a connector who hasn't been asked in the last 30 days?
- If yes, send the connector a drafted ask they can forward in ten seconds. If no, the sequence runs as before.
- Log every ask and every outcome in the same table.
After a month you'll have the only number that matters for this column: how warm asks converted against cold sends on the same signals.
Where Boomerang fits
We built Boomerang so this column exists without a six-month data project. Rudy, the agent inside it, maps paths across your team, customers, investors, board and partners, scores them, drafts the ask in the connector's voice, and tracks it to a meeting. Rudy never sends anything on a connector's behalf. Caps, cooldowns and opt-outs are config, and the same data is available through the API and the MCP server, so it plugs into the workflows you already run.
The GTM engineer playbook goes deeper on the scoring, routing and connector-budget rules.
Frequently asked questions
What is relationship data in GTM engineering?
It's data about who in your company's network already knows a target buyer: the connector, how they know them, how strong the relationship is, when they were last asked for help and what happened. Unlike firmographic or intent data, it can't be bought, because it comes from your own team, customers, investors and partners.
Why don't enrichment tools provide relationship data?
Because the relationships belong to your company, not to the vendor. An enrichment provider can tell you a buyer's title and tech stack. It can't tell you that your board member sat on a board with them, since that information only exists in your own network.
How do GTM engineers use warm intro data in workflows?
The most common pattern is a check before a cold sequence fires: if a strong path exists, the signal is routed to the connector as a drafted intro request instead. Other uses include path strength as a feature in account scoring, routing accounts by relationship rather than territory, and multithreading open deals.
Does adding relationship data mean asking connectors for more intros?
It should mean asking fewer people better. The column needs a last-ask date, caps and opt-outs so workflows can't overuse the same connector. Without those rules, automation burns relationships faster than any rep could.
.png)
