GTM engineering, explained badly

For the last three months, I’ve been doing GTM engineering. A little change from engineering engineering, where you spend the day explaining why something does not work. In GTM engineering, you spend the day explaining why something that works has not generated pipeline.

Several people have asked me what that means. Fair question. I have had three months to prepare an answer, and I now own enough vocabulary to avoid giving one.

So let’s fix that. By the end of this article, you will be able to sit in a GTM meeting, nod at the correct intervals, and say “interesting signal” without visibly reaching for help.

Small disclaimer: this is the deliberately bad explanation. The campaign observation is real; the conversations, travel plans, and increasingly expensive conclusions below are comic dramatizations. A useful explanation will follow in another article. Today, usefulness is outside the scope.

GTM stands for go-to-market. Engineering means we have connected enough things together that unplugging one of them requires a meeting.

Put them together and you get someone who helps the right message reach the right person at the right time, using data, software, and an unreasonable number of tabs.

There. That was dangerously close to an explanation. Let’s make it a tad more complex.

The right person belongs to the right account. The account fits the ICP. The ICP has intent. The intent becomes a signal. The signal enters a workflow. The workflow creates a task. The task goes to a person, who asks where this account came from.

Excellent question. We have a dashboard for that.

ICP means ideal customer profile. You describe the sort of company that might benefit from what you sell. Size, industry, problems, all that sensible stuff.

Our imaginary company sells software that makes meetings shorter. The ideal customer is therefore a company with meetings. This narrows the market to the market.

Too broad. We add filters. More than fifty employees. Growing team. Recently hired someone whose title contains “operations.” Has publicly expressed an interest in efficiency, preferably during a forty-minute webinar.

Now we have a highly specific list of companies that resemble the list we started with, but the spreadsheet is wider. This is segmentation. Please respect the process.

Next, we enrich the data. Enrichment means taking a row that knows very little about someone and helping it become considerably more confident.

We find a company website, a job title, perhaps a company size. One source says sixty employees. Another says two hundred. The website says “a small team with a big mission.” So somewhere between sixty and a mission.

We resolve this by assigning a confidence score. A confidence score is a number that allows uncertainty to wear a tie.

Then we deduplicate. This is where David Smith, Dave Smith, and D. Smith become one person, unless they are three people, in which case we have achieved efficiency at the expense of David.

No worries. We can fix it downstream. Downstream is a wonderful place. Every department has one, and nobody appears to work there.

A signal is an event that might suggest a relevant moment to contact a company. They hired someone. They opened an office. A real event, with context, can be useful.

In our increasingly fictional workflow, a prospect likes a post about saving time. This tells us they may want to save time. Or they like the person who wrote it. Or their thumb slipped while they were saving time.

We give the event fourteen points.

Why fourteen? Ten felt arbitrary.

At fifty points, the account becomes hot. At seventy, very hot. At ninety, someone says “we should probably reach out.” We have built a thermometer for a conversation that has not happened.

Now we personalize the outreach. People dislike receiving a message that could have been sent to anyone, so we build a system that can send everyone a message that could only have been sent to them.

“Hi David, noticed you’re the Head of Operations at a company. As a Head of Operations at a company, you probably care about operations.”

Uncanny. How did we know?

We improve the prompt. We add context. We remove “hope this finds you well.” We put it back because the new opening sounds like a detective confronting a suspect.

Eventually we produce an email so natural that three engineers and a language model agree a human might have written it. The human replies, “Not interested.”

A reply! Mark that as engagement.

Here is the actual observation that sent my brain off on a small holiday: in a LinkedIn campaign, our women BDRs were getting roughly twice the connection acceptance rate of our men BDRs. BDR means business development representative. The people doing the reaching out. We were almost educational again. Sorry.

That result alone does not tell us why. Profiles, audiences, messages, timing—there are plenty of things to investigate before announcing that we have discovered a law of human behavior.

Naturally, in the completely irresponsible meeting taking place inside this article, we investigate none of them.

“What if,” I ask, with the calm authority of a man about to misuse a spreadsheet, “next year’s offsite was in Thailand?”

Silence. Someone stops sharing their screen. David and Sean would like to know what this has to do with team building.

Everything, gentlemen. We are becoming data-driven.

The imaginary offsite now has a costume party, a slide deck, and no return ticket to common sense. Thailand supplies the sunshine. We supply the questionable business reasoning.

In the imaginary offsite presentation, David and Sean reappear as glamorous lady alter egos, armed with wigs, excellent outfits, and the same unresolved CRM permissions. They are visibly delighted to have negotiated the costume budget before anyone checked the hypothesis.

David asks whether the new persona gets a higher base salary. Sean asks whether false eyelashes count as sales enablement. Finance asks whether this could have been a webinar.

The women on the team point out that perhaps we could test the targeting and messages first.

Very sensible. Unfortunately, the slide already says “International Growth Strategy,” and the diagram contains an airplane. You cannot put an airplane back in a box once leadership has seen it.

Nobody changes anything except outfits. The experiment still has no control group. The wigs have better methodology than the deck.

Then somebody asks the worst possible question: “Did the extra accepted connections become useful conversations?”

I beg your pardon. We were celebrating.

A connection is not a meeting. A meeting is not a customer. A customer is not automatically a happy customer. Somewhere along this chain, somebody must actually want what we sell. This introduces a troubling dependency on the product.

Our fictional dashboard solves the problem by showing the first number in very large green type and placing the other numbers under a collapsed section called “Advanced.”

David and Sean are still in the presentation. Their costumes have become a fixed cost. We are now emotionally invested in the hypothesis, which is the most expensive kind of investment because it does not appear in the budget.

A webhook is one system telling another system that something happened. Imagine a doorbell, except the doorbell rings another doorbell, which updates a spreadsheet, which sends a message saying the first doorbell could not be reached.

This is my comfortable territory. Finally, a normal engineering problem: retries, missing fields, rate limits, and a timestamp that has arrived from tomorrow.

We build a workflow. A new signal enriches a contact, scores an account, assigns an owner, and creates a task. A human checks the result before anything embarrassing leaves the building. Even in this article, we can afford that step.

The workflow saves six minutes. Maintaining it takes an afternoon. But next week it might save six minutes several thousand times, which is either leverage or the beginning of a support rotation.

We document it with a diagram. The diagram is too wide for the screen. We have achieved architecture.

Imagine somebody eventually buys our meeting software. Great. Why did they buy it?

Sales says the call. Marketing says the campaign. The product team says the product. The customer says a colleague recommended it, which is inconvenient because the colleague is not connected to our attribution model.

First-touch attribution gives credit to the first interaction. Last-touch attribution gives credit to the last one. Our imaginary all-touch attribution gives credit to everyone, producing four customers from one invoice. Remarkable efficiency.

The GTM engineer connects the systems so we can examine what happened. Then the systems disagree, and the GTM engineer becomes a diplomat with API keys.

I used to debug software. Now I debug the sentence “this lead should have been mine.” Career growth takes many forms.

Let’s recap. We find the right companies, learn enough to approach them sensibly, notice useful moments, build the plumbing, and measure whether any of it helps.

That sounds almost manageable. Please ignore it.

What we actually do is operationalize an intent-led, signal-enriched, multi-touch revenue motion across the entire customer lifecycle, with a human in the loop and Sean in a very good wig.

Did you get it?

No? Perfect. You are ready for the kickoff.

Your first task is to explain GTM engineering to someone else. If they understand, add another arrow. If they ask about revenue, tell them the dashboard is refreshing. If they ask about Thailand, that initiative is currently downstream.

I’ll write the useful version next: what we actually build, what we measure, and where the engineering helps. For now, I’ve been doing this for three months, and I can confidently say one thing.

We should probably test the message before booking the flight.