Anyone who has built a GTM system knows the how and the what matter. How the workflow runs, which tools talk to each other, what we're selling and to whom. I spend most of my days in exactly that part of the job, and I like it. But the longer I do this work, the more I think the how and the what only hold up when someone has answered the why first.
Take outbound. You can send a thousand emails with a flawless setup and still not know the most useful thing, which is why someone replied or why they didn't. A reply has a reason behind it, and so does silence. If I can't say what that reason was, I'm just adjusting numbers and hoping.
Automation works the same way. I once spent two weeks building and automating a lead routing workflow, and the recruiters kept assigning leads by hand. The workflow worked fine. What I hadn't asked was why they assigned leads by hand in the first place, and that answer would have told me what the system needed to do before I built any of it. Now, before I automate anything, I ask why it needs to be automated at all, and sometimes the honest answer is that it doesn't.
Then there's the ICP. It's easy to treat the ideal customer profile as a set of filters, an industry, a company size, a job title. But a filter is only the end of a longer line of reasoning, and the reasoning is the part that matters. Why is this the customer we want? What do they lose without us, and what makes them the kind of person who notices? When I can answer that, the list almost builds itself. When I can't, I'm filtering for the sake of filtering.
Underneath all of those sits the biggest why, which belongs to the founder. Why does this company exist, and what is it trying to become? Every campaign, workflow and segment should trace back to that. When it doesn't, you get a lot of activity that looks like progress and doesn't add up to much.
This is why I think GTM is a system, and not a pile of tools and technicalities. Tools change every year. The reasons people buy, ignore, reply or resist change much more slowly, and those reasons are what hold the system together.
It's also why I think a great GTM engineer is both an engineer and a salesperson. The engineer builds the thing, and the salesperson keeps asking why anyone would care. I happen to be both, mostly by accident.. I studied automation engineering first, so building and debugging systems comes naturally to me. Then I studied cyberpsychology and gender, which taught me to listen for the reasons people don't say out loud. I've worked as a social media marketer, where I learned how people respond to words, and as an operations integrator, where I learned how much of a business lives in the gaps between its tools.
So when someone asks me what a good GTM engineer needs to know, I tell them the tools are the easy part. The hard part is being curious enough to keep asking why until the system makes sense.