Building Tomorrow's
Outbound GTM
Systems Today.

I did not plan a career in go-to-market. Steve Jobs said it best: “you can only connect the dots looking backwards.” Mine only line up in reverse.

I started in engineering, back in high school, and it never really left me. It taught me to see any problem as a system with a constraint somewhere, and to go find that constraint instead of just working harder around it.

I switched to finance for my bachelor’s, then went into corporate sales. Sales taught me the lesson everything else is built on. I was good at closing. I kept running out of accounts to close. The bottleneck was never the conversation, it was the pipeline feeding it. I did not have a closing problem. I had a pipeline problem.

That is when outbound got interesting. The 2015 to 2020 playbook was falling apart. Buy a list, blast it, hope. It made noise, not meetings. Something better was forming, and it eventually got a name: GTM engineering. Instead of adding reps and volume, you engineer the motion itself. Signals, data, sequencing, routing, built as one system. Outbound, inbound, and RevOps treated as infrastructure, not activity.

And there was that word again. Engineering. The thing I started with turned out to be the thing the whole field was moving toward.

It finally made sense because of the parts of my background that never seemed to belong together. Finance taught me how a business actually makes money. Sales taught me what a buyer ignores. My postgrad in operational research and risk taught me to model messy problems and build systems that survive uncertainty. Business, tech, and sales, held together by an engineer’s habit of finding the constraint. That is exactly where go-to-market systems get built.

So I started atomGTM to build those systems for other teams, and to solve the problem I had lived: pipeline is an engineering problem, not a headcount problem.

One rule has not changed since. I build the system. You own it.