I'm currently building the GTM Engineering team at Tractian - Manufacturing AI copilot, Forbes 50 AI company, $200M+ raised from GC and Sapphire. I was a board member / investor of the company before joining full time. Unbelievable team and a product that is second to none in the market.

Before this, I was a Partner at N47, $2B VC early stage fund, investing in GTM tech + vertical AI. I cut my teeth at Tumblr, Merrill Lynch earlier in my career. I went to Berkeley, grew up in Hong Kong, and live in the SF Bay Area.

My daily fuel is Osmanthus Oolong tea and Nitric Oxide. The canto dinner spot with the best price/performance ratio right now is Porridge and Things in Millbrae.

GTM Eng Handbook

where's the leverage point in your GTM engine right now?

Chapters

1. 01

   Everyone wants GTM multi agent systems

   don't over think it. Start with an all purpose GTM AI Agent

2. 02

   The Frequent Rub on GTM Engineering Folks

   "Aren't you guys just data and systems/process nerds?"

3. 03

   Vibes Based Rollouts + Enablement

   coming soon

Everyone wants GTM multi agent systems

Every company wants their AEs, CSMs, and other non-technical ops users to use AI agents to "increase productivity." There's a common temptation to jump straight to purpose-built agents for every use case - a coaching agent, a BI agent, a forecasting agent, all at once. But if your organization is starting from ground zero, I highly recommend starting with an all-purpose GTM agent focused on a basic principle: information retrieval. How can a rep get the information they need in a single query instead of 10+ clicks across multiple applications?

At this point there's a very real build vs. buy decision. I respect Glean, but they're extremely expensive if you want full org coverage, and it'll take a while to set up. At Tractian, we made the build decision with no regrets.

That's the bet behind Jimmy Neutron, our internal GTM agent. Instead of shipping six specialized bots, we built one general purpose brain in Slack, wired via an MCP tool executor into Gong, CRM, our internal industry knowledge base, and the enablement drive.

Getting that first agent adopted comes down to three things we hold ourselves to: it has to be fast, fluid, and familiar. Miss any one of those and you don't get strong adoption, and you've wasted all those precious GTM Eng hours. Here's how each of the three F's mapped to our build decisions:

• Fast. Deals evolve constantly, so a RAG setup querying stale embeddings would have meant slow, second-guessed answers. We went tool-based instead. The model calls a live function against Gong or HubSpot in real time rather than searching a static index.
• Fluid. One agent, a dozen different asks: pre call briefs, live deal recaps, closed lost mining, pipeline hygiene, new hire coaching, churn risk flags. Reps shouldn't have to remember which bot handles which question; it should just be the one they always go to.
• Familiar. We put it in Slack, not a new UI. Reps already live there all day. Meet people in the tool they already open by habit.

The part that actually took a lot of discipline wasn't adding capability - it was writing down what Jimmy explicitly won't do yet: no write back to HubSpot, no CSV exports, no cold email copywriting, no lead scraping, no legal redlining, no scheduling. Not because it's technically impossible, but because a general-purpose agent's job is to prove out one thing: fast, fluid, familiar access to context before it's allowed to sprawl.

That restraint is what makes the roadmap work. Phase 1 ships the one general agent to every AE, CSM, and RSD. Only in Phase 2, once usage shows exactly where the leverage actually is, do we branch into purpose-built agents, each inheriting the ever-improving data layer the general agent already validated in the field.

The lesson generalizes past Tractian: ship the fast, fluid, familiar agent first, and let real usage tell you which of its jobs deserves to become its own specialized build.

The Frequent Rub on GTM Engineering Folks

"Aren't you guys just data and systems/process nerds?"

Thanks, bud.

It's a most common assumption made about GTM Engineering teams. And those people are not entirely wrong, because we do live very deep in the data and the systems. But treating that as the whole job is where the stereotype comes from, and it's something I've found myself actively working to disprove with my team.

I see a lot of great content about AI agents and automation in GTM right now. I see a lot less about the core principles that actually make a GTM Engineering team succeed. For me, that means staying focused on ground truth, what's actually happening with customers and on the frontline, instead of leaning on qualitative assumptions or data assumptions alone. Both fail the same way if only done independently: quant without ground truth, and gut without evidence. There's a great quote from Leo Vieira, Tractian's COO: "If the terrain doesn't match the data, trust the terrain."

How I operate and my expectations of the team:

• Stay close to the frontline. Customers, Sales, CS, Gong, product analytics. The frontline shows up in a lot of forms, and we try to touch all of them, not just the ones that live in a dashboard.
• Collaborate + communicate with our team leaders globally. Systems built in isolation from the people running the regions don't get adopted or survive. They have important insights that can usually be incorporated into system builds and rollouts. You don't want to miss out on those.
• Leverage industry best practices. Very rarely are we inventing GTM playbooks from scratch. There is a strong case to understand what is working well at other high growth companies and adapt it to how Tractian actually sells. There are certain extremely strategic and high leverage projects where we spend a lot of time pushing the boundaries on what is possible (I'm not revealing what those are on a public website like this). You don't need that to be the case for every single GTM eng project.

The frontline principle is the one that does the most work against the stereotype, because it's the easiest one to fake with a Slack message and the hardest one to fake in person. In the last few months alone, more than half of my team put on hard hats and steel-toe boots to step onto our customers' factory floors. They do it to translate real-world context into better systems, processes, and experiences for the company.

Spending time with customers does something a query can't. It's a powerful reminder of the mission we're actually on. It's a lot harder to call someone "just a data and systems person" when they were standing on the same factory floor as the customer three weeks ago, watching the exact problem the dashboard is trying to describe.

canto dinner club

a running list of the best plates at credible spots.