How RevOps enables GTM engineering & product partnership

I'm Lauren Hughes, and I run revenue effectiveness at Justworks. For us, that means revenue operations, strategy, and enablement all sitting under one roof.

I've been leading revenue operations teams for over 20 years, back before any of this was even a recognized career path, and I can honestly say I've never been more excited about where rev ops is heading.

We're changing the game. We're inventing new jobs in real time. The tech at our fingertips is genuinely revolutionary, and there's more opportunity than ever to make our customer-facing teams more consultative and less administrative. So when I get to talk about go-to-market engineering, one of my favorite topics, I get pretty fired up.

Let's walk through what I've learned so far: how to hire for the role, what these folks actually do (and don't do), how they fit within a broader revenue strategy and operations org, how to contract with your cross-functional partners, and why governance matters more than ever.

The state of the go-to-market engineer hiring market

This role is genuinely new. It's still being defined, almost in real time. Unless you can convince someone from Clay to leave, you're probably not going to find anyone who's been doing this job for more than a year.

When I started hiring my first go-to-market engineer around June or July of last year, there were roughly 1,400 job postings for the role on LinkedIn. By January of this year, that number had more than doubled to 3,000. Demand is accelerating fast, and yet nobody is going to school to become a go-to-market engineer. So the obvious question is: where is this talent actually coming from?

That was the puzzle I had to solve when I joined Justworks about nine months ago.

Why I knew we needed this role

When I walked in the door, we had a lot going on. Between marketing, revenue, customer success, and support, we had about 70 pieces of go-to-market tech. And almost none of it was being administered.

These tools were collecting incredibly valuable data, and for the most part, the approach had been set it and forget it. Someone would get convinced by a vendor, set up the tool, and then move on to the next fire.

The integrations were another challenge. Most of these tools were sitting standalone. Vendors had sold us on the idea that their point solution could talk to other point solutions, but we hadn't actually done the integration work.

So we needed someone to own the administration, build the workflows, connect the systems, and extract value from what we'd already bought.

On top of that, vendors were calling me every day, telling me I was falling behind on AI. I figured if I hired a go-to-market engineer, I could check that box too.

How I actually hired the first one

Since nobody has really been doing this job for very long, I worked with an external recruiter, Captivate Talent, and a woman named Brie Doyle who's been recruiting for rev ops teams for years. When she asked me what I actually wanted, I had to think about it for a minute.

My existing rev ops team was excellent at what they did. What I needed was someone who would do something different. Someone thinking outside the traditional rev ops and enablement playbook. I told her to go look at MIT graduates if she had to. I just wanted people who thought differently.

Today I have four go-to-market engineers. Two I promoted internally and two I hired externally. One of the internal moves was a team member who'd been doing a lot of automation work with retention signals on the customer success and support side.

Another was one of our best SDRs who was already doing a lot of our Clay work, so moving her into this role felt natural. The two external hires were rockstars Brie helped us find.

Since they joined, the landscape has shifted dramatically. A year ago, you had some basic automation tools, people testing things in ChatGPT, and a handful of AI tools coming out. Now we have Claude and co-working agents. What were we even doing two months ago?

At Justworks, we're all in on signal-based selling. We have a complicated sales motion and a huge amount of data flowing in from our website and our customer interactions. I need go-to-market engineers to tell me how to capture that data, where it should sit, how to get at it, and how to make sense of it so we can actually make decisions.

What these integrations look like in practice

Almost every company I talk to has disconnected systems. We certainly did. We use Customer.io for marketing automation, Salesforce as our CRM, and on the customer success and support side, we have Zendesk, Talkdesk, and Forethought.

Layer Gong on top of that, and you have a lot of tools collecting extremely valuable data that nobody was properly integrating.

Without integration, you leave two things on the table. You lose automated workflows that would make your customer-facing teams more productive, and you lose the insights hidden inside the data you're already collecting every single day. That second one was what really kept me up at night.

Where go-to-market engineering fits in revenue strategy

When I started at Justworks, I actually found our revenue strategy was pretty sound. We're a 10-year-old business, we had a decent lead funnel, opportunities moved through the funnel more or less the way you'd expect, and our support and success teams kept customers happy. The house wasn't on fire.

But nobody was looking at what we didn't already know. Nobody was thinking through the art of the possible. That's where things got interesting for me.

What a go-to-market engineer is not

Let me get clear on what this role isn't, because I see a lot of confusion out there.

Go-to-market engineers are not in the product. They're not coding. They're not Salesforce administrators.

I got a call last week from a head of FP&A at another company who told me he wanted to hire a go-to-market engineer. When I asked why, he said he felt his Salesforce wasn't set up right. I had to gently tell him that a Salesforce administrator and a go-to-market engineer are different jobs. A Salesforce admin can absolutely aspire to become a go-to-market engineer. Some of ours will probably make that transition someday, and they'll be great at it. But the two roles are not the same thing, and confusing them sets you up to fail.

Go-to-market engineers also aren't doing the traditional rev ops work. They're not optimizing the customer journey. They're not establishing lead scoring (though they might collect data that helps inform it). They're not designing compensation plans, running comp, or doing the forecasting. They might help design the forecasting model, but the actual forecasting sits elsewhere.

What a go-to-market engineer actually does

At Justworks, they build automations and integrate tools. Full stop.

A few months ago, I discovered we were spending an enormous amount of money on Gong, which I love, and yet 50% of our calls weren't being recorded. Gong wasn't properly integrated with Salesforce, the data wasn't flowing into Snowflake correctly, and our product team was actually using Gong data to make product roadmap decisions. So my go-to-market engineers went all in on integration, making sure the tools were stood up properly, the data was captured and organized correctly, and everyone who needed access could get it.

I like the ZoomInfo definition of the role: a position that combines technical skills with commercial acumen to automate and optimize lead generation, sales intelligence, and customer acquisition. As companies race to scale revenue operations efficiently, go-to-market engineers bridge the gap between engineering and go-to-market strategy.

One thing worth adding: at Justworks, we don't limit them to lead gen, sales intelligence, and customer acquisition. We use them across the entire funnel. We have go-to-market engineers focused on customer success, support, retention, and partnerships.

What rev ops looks like when you have go-to-market engineers

In my perfect world, the rev ops team stops firefighting. The automations put out the fires for us.

We used to have a ticket dashboard where we manually answered a huge volume of requests. I told the team: 30 days. We're pulling the plug. No more ticket intake through this dashboard. The go-to-market engineers are helping us build ticket automation to replace it.

Same story with compensation. I have a fantastic guy who runs incentive design and comp, and I'm promoting him into a revenue planning and strategy role. We were sitting together in a fiscal year planning meeting recently, and I was watching Slack notifications pile up on his screen. The entire 150-person sales floor was pinging him with one-off questions about their comp. My anxiety was through the roof just watching it.

So we said: hard no. We're done with this. The team built a comp bot in 30 days. It's a Slack integration. The go-to-market engineers scanned his Slacks, his emails, and our ticket board. Now he's not firefighting anymore. He's focused on revenue planning during our busiest planning period of the year.

That's the dream. No tickets. No manual reporting. No firefighting. No troubleshooting integrations. Revenue operations and strategy can actually do revenue operations and strategy, which means focusing on planning, monetization, return on effort, all the things RevOps leaders aspire to do but rarely have time for because manual work gets in the way.

The contracting conversation I did not see coming

This one is near and dear to my heart because I spent a lot of time on it.

I was on vacation with my family, two months into the job, sitting at the Four Seasons in Orlando, drinking margaritas, when our chief product officer Slacked me asking if I had five minutes. Fantastic timing.

He told me the go-to-market engineering job I'd just posted was giving his teams a lot of anxiety. Our chief product officer has data analytics, product, tech, and engineering under him. So we ended up in a long series of meetings, memos, and documents working out the contract between my team and his.

When the job posting first went up, there was genuine panic. Is rev ops hiring an engineering team? Are they going to be in our product? Are they going to code? I spent a lot of time educating the product and engineering teams about what's happening across the industry, explaining that there's data and signals everywhere, and that we need people who can stand up these tools and systems the right way so we can capitalize on the opportunity.

Here's where we landed:

My team would never do anything inside our product. If we want to integrate directly with the product, the product and engineering teams help us do it. We partner with Cassidy for a lot of our automations, and those sit outside the product. We agreed to keep it that way.
We would not do any real coding. We're doing a little bit on the data side, but nothing inside the Justworks product itself.
We would not mess with the data warehouse. We'd partner with the data team on how to organize data, take their advice on structure, and hold hands on governance and definitions.
We'd follow the rules. Mostly. Sometimes I get my wrist slapped.

The contracting exercise was really important for Justworks because I came in with 20-plus years of rev ops playbook ideas and a head full of things I was seeing across the industry. I had to do a lot of internal coaching on what all of that meant and how it could work for us if we implemented it well.

What finally clicked for them was when I pointed out that we had 70 pieces of ancillary tech across marketing, sales, customer success, support, and partnerships, and none of it was integrated. I own the budget and the P&L for those tools. Let me administer them properly. I'm happy to call the team something else, but I won't get top talent unless I call the role go-to-market engineering. That was the compromise.

Governance, or why you can't say yes to everything

We were victims of point solutions at Justworks. We said yes to everything. We let every vendor walk in and tell us what our problems were, and we nodded along and bought the thing.

We're done with that. We're standing up real governance, and we're starting to say no. We recently did a pilot with a parallel dialer, and I pumped the brakes. The vendor was telling us we needed it. We really didn't. Let's do better with what we already have and reevaluate later.

When you think about governance, the main principle is to avoid being reactive. Think about what your business actually needs, and then go find the right solution. Don't be a victim of solutions that get sold to you.

My team probably gets frustrated with me because I'm scrolling LinkedIn constantly, going, "Look at this, look at what that company did." I follow Varun from Clay, and every five minutes, I'm sending something over. So part of my job is to help the team prioritize, ground everyone in the problems we're actually trying to solve, and put real structure around intake.

We've moved to structured intake through Asana. All our projects live there, and they're linked together. Across revenue planning, go-to-market operations, partner ops, comp design, rev tech, and monetization, I can look at the roadmap and see who's working on what. That structure has been essential. Without it, the speed at which go-to-market engineering moves would have created chaos across the rest of the team.

Is your organization ready?

Before you post a go-to-market engineering job, ask yourself a few questions.

Are you ready to move faster? My team is developing and deploying in roughly two-week sprints. We iterate as we go. We don't wait for a finished product. We roll things out at 80% and test.

Are you ready for the contracting conversations? Justworks has around 1,500 to 2,000 employees and a well-established tech organization, which meant those conversations were critical for me. Smaller companies may not have that challenge, but if you do, plan for it.

Is your organization ready for embedded AI? Your data might not be ready. You might actually need a go-to-market engineer to get your data ready, which is exactly what mine are doing.

A few questions I get all the time

How do you handle overlap with marketing?

Honestly, I haven't fully sorted this one yet. Marketing operations doesn't report to me. I'm focused on sales, customer success, support, and partnerships. The head of demand gen and I have a good relationship, but further down in the teams, we're running in circles around each other.

We haven't collided much yet because marketing is focused way upstream on acquiring leads, and we're focused downstream, but as we move up the funnel (we're backfilling a sales development director role right now), we'll start to overlap. I know it'll be a problem in about six months.

What was the investment, and how did you justify it?

I originally thought I needed three go-to-market engineers. When we found two rockstars through the recruiting process, I closed an open Salesforce admin role and hired them both. We use contractors for the Salesforce admin work now.

My overall team is about 40, with roughly 25 on the rev ops side. We support about 560 customer-facing team members across sales, partnerships, success, and support. I didn't have to make a big case to the CFO. The harder work was with the product and engineering leaders. I walked into a bloated sales enablement team, reduced its size significantly, replaced a lot of that work with AI, and used the savings to fund rev ops headcount that had been understaffed.

How do priorities shift over time, and what happens when you move into maintenance mode?

The maintenance question keeps me up at night. If one go-to-market engineer builds something complex and then leaves, and the others don't know how to maintain it, we're in trouble. So we're being aggressive about documentation and governance. That's something the industry still needs to figure out.

In terms of a steady state, the projects don't end. We recently built a rep lookalike model using all the data attributes of our best reps. Now we're layering in conversational intelligence, looking at when they activate cross-functional teams to close deals, analyzing their Slack activity, and product interactions.

We want to train the rest of the sales floor to perform like our top reps. In a fast-growing organization, you will always find the next thing.

Final thoughts

Go-to-market engineering is still being invented. We're hiring talent that didn't exist two years ago to do work that didn't exist two years ago. And yet the opportunity is enormous.

If you've got disconnected systems, data you're not using, and a rev ops team buried under manual work, this role can genuinely change what your organization is capable of.

Just make sure you scope it properly, contract with your partners early, put real governance around it, and hire people who think differently. The rest gets easier from there.