Can RevOps learn from DevOps?

The phrase Go To Market (GTM) Engineer has been everywhere lately. I kept hearing it throughout last year, and I've probably only started taking it seriously following listening to Varun Anand (Co-Founder at Clay.com) speak about it at Web Summit. He wasn’t treating it like a trend, he was treating it like a clear direction change of where revenue teams are heading. The more I’ve thought about it, the more it reminds me of how people describe the rise of DevOps.

Back then, DevOps sounded like a niche idea. Then CI/CD arrived and suddenly teams were shipping faster, fixing things quicker and treating experiments as normal rather than risky. Automation took over the repetitive work. Small, frequent changes replaced slow, painful releases. Failure wasn’t a disaster. It was part of the process. The teams that leaned into that mindset pulled ahead. The ones that didn’t felt the gap grow very quickly.

RevOps feels like it’s hitting a tipping point. We often spend too much time digging for client info, jumping between tools, preparing calls with incomplete data and trying to prospect through systems that don’t talk to each other. Everyone wants more speed but the day to day reality slows them down. Tweaking a dashboard won’t fix any of that. So the rise of the GTM Engineer makes sense. Teams need people who can remove the friction instead of patching the same problems on repeat.

I keep coming back to the idea that we can learn a lot from what DevOps taught engineering. Smaller increments instead of giant quarterly projects. A culture of trying things, failing fast and improving as you go. Processes that evolve and tools built with the same mindset engineers use when designing systems that need to scale. It feels like the kind of trial and error culture RevOps has been missing.

This doesn’t feel like a passing trend. It feels like a shift. Some teams are already working this way and treating RevOps as something that should constantly improve. Others still rely on manual fixes and rigid processes that don’t match the pace around them. I keep wondering what RevOps could become if we adopted the same attitude DevOps brought to engineering, and what it would mean for the teams that choose not to.