Do we really need GTM engineers?

GTM engineer was a role that hardly existed a few years ago. Today, it has become a leading buzzword in the sales world. There are two reasons, one a bit dodgy and one well worth considering.

1️⃣ The slightly uninspiring reason is the success of Clay. Not that Clay is uninspiring, it’s an excellent product that brings a lot of value. However, it’s also a hugely complex product that requires experts to get real value from it, and hence the idea of a GTM engineer to drive your Clay usage has wound its way into modern day sales conversations.

2️⃣ The much more interesting reason is the extraordinary capabilities that AI can deliver in GTM (as well as everything else). I can’t open my email without seeing how yet another product can provide a new AI driven service. I am taking a lot of demos and speaking to a lot of users and am impressed by the capabilities.

However, to really make good use of these technologies, a revenue organisation needs to think about how they fit together.

👉 Make sure that each tool feeds into its neighbours

👉 Maintains consistent data across the environment

👉 Adds value without getting in the way

This requires thoughtful evaluation of solutions, careful integration and automation that really matches the business needs. Hence the GTM engineer.

For many years we have been talking about RevOps, and RevOps has always had two separate branches:

💡 deliver insights that allow the business to grow

🧑‍💻 manage the tech that underlies the revenue organisation.

The GTM engineer very much leans into the second of these, but with the recognition that the tech is increasingly able to deliver insights with less and less manual support.

Any revenue organisation that wants to grow effectively over the coming years must harness AI and technology way more than they have in the past, and they will need smart GTM engineers to make that a reality.

I’d love to hear your thoughts. Comment here or reply.