The Word Without the Discipline

A title can travel across an industry years before the discipline beneath it exists.

Sometime around the start of this year I was scrolling job listings, the way you do when you are trying to read where an industry thinks it is going rather than where it has been. The same title kept appearing, the same two words over and over, go-to-market engineer. It was on a posting at a model lab, on one at a developer-tools company that had not existed five years earlier, and on one at a fintech that paid its engineers like engineers and had decided to pay this role the same way. The salary bands were serious, some of them clearing two hundred and fifty thousand dollars, and new listings kept appearing month after month, where a couple of years before there had been almost none.

I want to be precise about what struck me, because it was not the growth. New titles appear all the time, and most of them are old work with a fresh coat of language. What struck me was that I could not have told you, from any two of those listings, what the people writing them believed the job actually was. One described a person who builds automated outbound systems. One described a person who owns the revenue tech stack. One described, more or less, a very technical sales development representative who could write SQL. They had agreed on the word. They had not agreed on the work.

That gap is the subject of this essay. There is now a widely used term, go-to-market engineering, that names something real enough that companies will pay a premium for it, and underneath that term there is no discipline. There is no shared body of knowledge that a person could learn and carry from one company to the next, no agreement on what the object of the work even is, and no theory of how the thing fails. We have the word, and we do not have the field. I think that is worth taking seriously, because the order in which those two things arrived tells you something about how the field, if it becomes one, is likely to be misunderstood.

You can see the cost of the confusion already, if you look for it. Picture a team that does everything the title now rewards. They stand up an automated outbound system, it works, and because the labor that used to cap such things is gone, the obvious move is to turn it up, so a system that reached a few hundred people a week begins reaching tens of thousands. For a quarter the dashboards climb. Then the replies sour, the domain reputation slips, and the company finds it has spent something it never thought to measure, the willingness of an entire market to hear from it again. Nothing in the tooling broke. The thinking broke, and there was no discipline in place to supply the thinking, which is the whole problem in miniature.

Where the word came from

The term has a fairly clean origin. It was coined around 2023 by Clay, a company that sells software for building automated go-to-market workflows, the kind of tool that wires together data sources, enrichment services, and outreach sequences into something a small team can run. The coinage was good business and, in its own terms, fair. Clay had built a product that let one technical operator do what used to take a department, and that operator needed a name. Calling them a marketer undersold the technical work. Calling them an engineer, in the software sense, overclaimed it. Go-to-market engineer split the difference and stuck.

From there the spread followed a recognizable path. A handful of fast-growing companies adopted the title early, the sort of places where the marketing team is three people and two of them can code. The compensation data started to appear, then the job boards, then the bootcamps promising to turn a sales operations analyst into a go-to-market engineer in a matter of weeks. The company that coined the term raised a great deal of money, reaching a multibillion-dollar valuation, and positioned go-to-market engineering as an industry-wide career path, going so far as to launch a program to train people into it. By the start of this year the title had its own salary benchmarks and its own small economy of courses and newsletters and consultants. The word had arrived everywhere at once, which is usually a sign that it filled a real vacancy in the language.

None of that is a criticism. A vendor coining a term for the workflow its product enables is ordinary, and often the term is useful. The problem is not that Clay named the role. The problem is what happened to the meaning afterward, which is that it never grew past the workflow it was named for.

What the word came to mean

Read enough of the current writing on go-to-market engineering and you find a striking consistency. Almost every definition resolves to the same thing. A go-to-market engineer is a person who automates outbound. They connect a data source to an enrichment tool to a sequencing tool, they add a model somewhere in the middle to write the first line of the email, and they make the whole apparatus run without a human touching each step. The more sophisticated descriptions add orchestration across more tools and more channels, and yet the core stays the same, because the work is the assembly and operation of automated systems for finding and contacting potential customers.

This is real work, and some people are very good at it, and it produces results that the old manual process could not. I am not interested in diminishing it. I am interested in the fact that we have started calling it engineering, and that almost nobody has stopped to ask whether the name fits, or what we would be committing to if it did.

We have taken the word engineering and used it to mean automation. That is the quiet substitution worth naming plainly. We have decided that a person who operates a sophisticated stack of tools is doing engineering, in the same sense that a structural engineer or a control engineer or a software engineer is doing engineering. And those are not the same thing. The difference between them is the difference between using a tool and possessing a discipline, and once you see that difference clearly, most of the current discourse about go-to-market engineering looks like a conversation about the tools that has forgotten the discipline was ever the point.

Automation is not engineering

Consider what a person actually has when they have a stack of go-to-market tools and the skill to wire them together. They have capability. They can make demand-generating actions happen at a scale and speed that would have been impossible by hand. This is genuine and valuable, and it is also, in a specific sense, shallow. It is the capability to execute, and execution is downstream of the harder thing, which is knowing what to build, why it will work, how it will behave under load, and how it will fail.

That harder thing is what engineering actually is, and it is worth being careful here because most people, including most people who use the word every day, carry an inaccurate picture of it. The common picture is that engineering is applied science. The scientist discovers the laws, the picture goes, and the engineer looks them up and applies them to a practical problem. On this view engineering is a kind of lookup operation, science with a deadline and a budget, and the engineer is a technician who translates known theory into working artifacts.

The historian Walter Vincenti spent a career showing that this picture is wrong, and that the error matters. In his study of how aeronautical engineers actually came to know what they know, Vincenti argued that engineering is a distinct form of knowledge, generated by engineers, that is not reducible to applied science. The aircraft designers he studied were not looking up answers in physics. They were building a body of structural knowledge that physics did not contain and could not supply. How much margin to leave between the expected load and the rated load. What tolerances a control surface needed before a pilot would call the aircraft flyable. Which failure modes a wing could be allowed to have and which it could not. None of that comes from the equations of fluid dynamics. It comes from a separate, accumulated, hard-won understanding of how to make things that work reliably under conditions you cannot fully predict, and it is its own way of knowing, with its own methods and its own standards of proof.

That is the sense of engineering I want to hold the field to. An engineering discipline is not the possession of tools. It is a body of design knowledge: an understanding of the object you are building, the constraints it must survive, the conditions it is rated for, the tolerances inside which it performs, and the ways it breaks when you push past them. The tools change every few years. The knowledge accumulates across decades and outlives any particular tool. A structural engineer who learned a new modeling package would still be a structural engineer. A go-to-market engineer who learned a new outbound stack is, on the current definition, simply someone who knows a different set of tools, because the current definition contains no body of knowledge for the tool to sit on top of.

This is the test, and it is unforgiving. If you took away the specific tools, what would remain? For the software engineer, a great deal remains: the understanding of complexity, of failure, of how systems behave at scale, of the tradeoffs that no language or framework can dissolve. For the structural engineer, almost everything remains, because the steel and the loads do not care what software drew them. For the go-to-market engineer as currently defined, what remains is real but unformalized, a set of instincts about message, segment, and timing that no one has yet written down in a way another person could learn. Tacit skill of that kind is not nothing. It is precisely the state every discipline begins in, the intuition of a few gifted operators that has not yet been turned into knowledge anyone can carry. Take away the stack and you are left with that intuition, valuable and not yet teachable, which is to say you are left more or less where bridge-building stood before anyone could calculate a load.

The seduction of the tool

It is worth asking why the tooling definition won so easily, because the answer is not laziness, and understanding it tells you something about the moment we are in.

The tooling is seductive because it is visible. A person who can stand up an impressive automated system in an afternoon produces something you can see and admire and measure. The dashboards populate, the sequences fire, the meetings appear on the calendar, and everyone in the room feels capable, which is a different thing from the system being sound. The knowledge that engineering actually consists of is, by contrast, almost entirely invisible. The judgment that a system is being run too close to its limits, the recognition of a failure mode before it arrives, the decision to leave margin that a less experienced operator would call waste, none of these produce anything you can point at in a demo. They show up only later, as the absence of disasters that would otherwise have happened, and an absence is a hard thing to take credit for. We reward what we can see, and what we can see is the tool.

This has always been somewhat true, and it has become acutely true in the last few years, because the tools have started to confer the appearance of expertise on almost anyone. When a person can produce, in an hour, an artifact that used to require a department and a decade of accumulated skill, the visible signal of competence detaches from the underlying knowledge that used to guarantee it. The output looks the same whether or not the person making it understands why it works. In that environment the operator who has read the manual and the operator who has internalized a discipline are indistinguishable on the surface, and they stay indistinguishable right up until the moment the system meets a condition the manual did not cover, at which point the difference between them becomes the only thing that matters. A field that defines itself by the visible operation of tools is a field that has, without quite meaning to, decided not to be able to tell those two operators apart.

This is the deeper cost of letting the word mean the tool. It is not only that the discipline goes unbuilt. It is that the absence of a discipline removes the standard against which real expertise could be recognized. When there is no body of knowledge a person is supposed to have, there is no way to distinguish the operator who merely runs the system from the one who understands it, and the profession loses its ability to know who its actual experts are. Every mature engineering field has, at its center, a shared answer to the question of what a competent practitioner knows, and that answer is what lets the field certify, teach, trust, and improve. Go-to-market engineering, defined as the operation of tools, has no such answer, and so it has no way to grow the thing that would make it worth the name.

Why the order matters

I said at the start that the order in which the word and the work arrived tells you something. Here is what I think it tells you.

In most engineering disciplines the discipline came first and the title came later, often much later. People built bridges, badly and then less badly, for a very long time before there was a body of structural knowledge worth the name, and the title of structural engineer is younger than the practice it describes by centuries. The knowledge accumulated through failure, through bridges that fell and were studied, through the slow construction of an understanding that could be taught. The title, when it finally arrived, was a label for a discipline that already existed. It pointed at something.

Go-to-market engineering arrived in the opposite order. The title came first, manufactured by a vendor and adopted by a market that was ready for it, and the discipline it was supposed to name does not yet exist. The word is pointing at an empty space. This is not a scandal. It is a fairly common thing to happen in a young and fast-moving area, and it is recoverable. But it has a predictable consequence, which is that the word gets filled in by whatever is nearest, and what was nearest was the tooling. The term went looking for a meaning and the tools were standing right there, so the tools became the meaning. That is why almost every definition you can find resolves to automation. No one decided that automation was the whole of the discipline. It happened because no one had built anything else for the word to mean, and a word with a vacancy will always be filled by whatever is closest to hand.

The risk in that situation is that the word hardens. If go-to-market engineering settles permanently into meaning the operation of outbound tools, then the much larger thing it could have named never gets built, and a real opportunity to turn a craft into a discipline is lost to a definition that was never more than a product category. I think that would be a waste, and the size of the waste is proportional to how important the underlying work has become.

What the underlying work has become

It is worth saying plainly why this is worth the effort, because the stakes are easy to miss if you think of go-to-market as marketing with a larger budget.

The work of bringing a product to a market and getting it to take hold has quietly become one of the most consequential and least understood activities in business. A great deal of capital and a great deal of talent now flow into it, and the outcomes are enormously variable in a way that suggests we do not understand the underlying mechanics. Two companies with comparable products and comparable funding will see one of them compound and the other stall, and the explanations offered afterward are almost always narratives, told in hindsight, that would have predicted nothing in advance. We accept this variance as the nature of the thing. I suspect a fair amount of it is the signature of a pre-disciplinary field, the same variance you would have seen in bridge-building before anyone could calculate a load, where outcomes depended on the intuition of a few gifted builders and no one could say reliably why one structure stood and another came down.

What changes the urgency now is that the execution constraint is lifting. For most of its history go-to-market was rate-limited by human labor. You could only send so many emails, run so many campaigns, have so many conversations, and the cost of each one capped how much of any strategy you could actually run. That cap is coming off. The tools the current definition is so focused on, the automation and the models, are removing the labor constraint that used to bound the whole activity. And when you remove the constraint that used to limit how much of a system you could build, the quality of the system’s design starts to matter far more than it did, because a badly designed process that used to fail slowly, throttled by the labor it took to run, can now fail quickly and at scale. The cheaper execution becomes, the more the engineering matters, and the more expensive it becomes to have a word for engineering that means nothing more than execution.

Return to that team for a moment, because the mechanism is the point. The system did not fail in the way software fails, with an error and a stack trace. It succeeded at exactly what it was told to do, and in doing so it drew down a resource, the goodwill of a market, that no one had modeled as a resource, because no one was thinking about the system as a thing with a load it could exceed. The market was finite, the message had been tuned for volume rather than for the relationship, and the people on the receiving end compared notes, so the company’s name picked up a faint negative charge it did not have before. An engineer would have asked, before turning the system up, what it was actually consuming and how much of it there was. The operator of tools had no reason to ask, because the tools reported only what they could see, and what they could see was going up.

That is the shape of the problem that the lifting of the labor constraint creates everywhere at once. The failures of go-to-market are increasingly failures of design that became visible only at scale, and design is precisely the knowledge that the tooling definition of the role does not contain.

So the situation is this: the work has become central and high-stakes, the constraint that used to make poor design survivable is disappearing, and the term we have reached for to dignify the work, go-to-market engineering, has been filled in with a definition that describes the tools and ignores the design. The word is in the right place, and there is just nothing underneath it yet.

What it would take to mean it

If we wanted the word to be true, if we wanted go-to-market engineering to name a discipline in the sense that structural engineering or control engineering names one, what would have to exist that does not exist now?

It would need a clear account of the object it builds. Every engineering discipline is organized around an artifact. The structural engineer builds structures, the control engineer builds control systems, and each has a precise understanding of the thing itself, separate from any one instance of it. Go-to-market engineering has no agreed object. Ask what a go-to-market engineer builds and the honest answer today is a collection of campaigns, funnels, and automations, which is a list of parts, not an artifact. Naming the thing that is actually being engineered, the system that reliably creates and captures a market, is the first piece of foundation, because nothing else can stand without it.

It would need base quantities and units. A discipline measures things, and it measures them in terms that are coherent and that compose correctly. Go-to-market measures everything and defines almost nothing; the metrics in common use are a pile of ratios and counts that often cannot be combined without producing nonsense, because no one has done the unglamorous work of asking what the fundamental measurable quantity of the field even is. That work, dull as it sounds, is the kind of thing that separates a discipline from a practice.

Beyond the object and its units, the same demand keeps recurring in different forms. A discipline has to be able to say how its object behaves when you push it toward its limits, how to sense what it is doing and correct it while it runs, how and why it fails, which of the things it claims to know are knowable at all from the data it has, and what it owes the people it acts upon, because every practice that builds things the public depends on eventually acquires the power to do harm. Go-to-market can say almost none of this with any rigor today. The distance between what it would need to say and what it can say is a fair measure of how far it sits from being a discipline at all.

That is the shape of what is missing, and none of it lets anyone claim that go-to-market is already an engineering discipline, because it is not. What that list describes is the work that would make it one. Some of that work would have to be quantitative, because a discipline that cannot say anything precise about its objects is not yet a discipline, and a real claim is one that someone could prove false. A field advances by making claims sharp enough to break, and go-to-market has mostly made claims soft enough to survive anything, which is comfortable and which is also why it has not advanced very far.

The empty space

I keep returning to the image of the word pointing at an empty space, because I think it is the most accurate way to describe where we are. Go-to-market engineering is a real term, in real use, attached to real money and real work. And the discipline it names has not been built. The space behind the word is open.

That is an unusual position to be in, and it is more interesting than the version of the story where a discipline already exists and merely needs better tools. An open space is an invitation. The question of what go-to-market engineering is has not been settled by anyone, which means it is still possible to settle it well, to build something underneath the word that is worth the weight the word is already carrying. Whoever does that work, carefully and in good faith, gets to define what the field means, and a field’s first definitions tend to last a long time.

What I am fairly sure of is that the question is worth taking seriously now, while the word is still young. The alternative is to let a term that could have named a discipline harden into the name of a toolset, and to go on treating the enormous variance in go-to-market outcomes as weather, something that happens to you, rather than as the thing a discipline exists to reduce.

The place to begin, then, is with the question the title has been allowed to skip. Before you can engineer something, you have to be able to say what it is, plainly enough that two people working from the same description would build the same thing. Go-to-market engineering cannot do that yet. Whether it ever will depends on whether anyone is willing to do the slow and unglamorous work of saying what the thing actually is, while the word is still young enough to be filled with something true.

---

References

• Walter G. Vincenti, What Engineers Know and How They Know It: Analytical Studies from Aeronautical History (Johns Hopkins University Press, 1990).
• On the origin of “GTM engineering” (coined by Clay in 2023), its spread, and current market data: Clay, “GTM Engineering: What It Is and How to Hire” (clay.com/blog/gtm-engineering); “GTM engineer: the next big thing in startupland,” Sifted (2024); on Clay’s funding and the career program, “AI-Powered Sales Automation Startup Clay More Than Doubles Valuation to $3.1B,” Crunchbase News (2025), and Clay’s “Go-To-Market Engineering Career Program.”
• On compensation (median roughly $127K; base pay at and above $250,000 at firms including Vercel and OpenAI): “GTM Engineer Salary in 2026,” SyncGTM, and Vercel Careers, “GTM Engineer.”