Palantir made the Forward Deployed Engineer one of the most sought-after roles in tech. But most of what breaks inside a growing business is not code, and the person who fixes it does not need to be an engineer. Phil Lakin, who built the NoCodeOps community before Zapier acquired it, joins Ysi to work out where the two roles diverge and how to hire for the one nobody has a job title for yet.

Key takeaways

Transcript

Lightly edited for clarity. Speakers: Ysi Gonzalez (Vantelira) and Phil Lakin (Zapier).

Two paths to the same role

Ysi: Most people meet a new tool and ask one question: what can this do? The best operators ask how the work actually happens right now, and what can be improved. Map before you build. Process before tools. And the work of carrying that into a business, any business, is what this show is about.

Welcome to The Forward Deployed Operator. I'm here today with Philip Lakin, though I'm going to call him Phil, because that's how we are with each other. He's the Director of AI Transformation at Zapier and one of the clearest voices I've found on what happens when the people closest to the problem finally have the tools to solve it.

I wanted him here because we arrived at the same category from opposite sides of the table. He came from no-code, from Airtable and Zapier and the systems quietly holding teams together. I came from industrial engineering and supply chain, leading projects while depending on a developer to actually build the thing. Two paths, same destination. Phil, welcome.

Phil: Good to be here. What's wild is hearing you talk about this, because you're taking words right out of my mouth. It's what I say to Zapier's biggest enterprise clients: when you empower the people closest to the problem to solve things, magical things happen.

And here's what's interesting. Back in the no-code days, most of this was already possible. Nobody cared. Now AI is popular, everyone wants an AI strategy, everyone wants their company AI-enabled, especially after that memo from the CEO of Shopify. Suddenly it's the cool thing to do. Ysi, we were in the basement listening to an indie band, and now they're on the radio and everyone wants tickets.

Why no-code operators existed before anyone named them

Ysi: So let me ask you something I've been meaning to ask publicly. What were you seeing that needed a name? And what is not a Forward Deployed Operator?

Phil: Back in the no-code days, I co-founded a community with my friend Brett. It eventually turned into software, then Zapier acquired it. The community is still active, called NoCodeOps.

The concept was that no-code had really taken off in our tech bubble, mostly with founders and agencies and indie businesses, but nobody was talking about it in the operational realm. Meanwhile, software tools were getting so good, not just no-code but vertical B2B SaaS generally, that every department started getting its own no-coder whether they knew it or not. You know those roles today as people ops, sales ops, revenue ops, marketing ops. Departments saying: we don't want to wait for a centralized IT function to build everything, we want someone in here, closest to the problem, vertical to us.

But the community kept attracting people who didn't fit any of those neat vertical boxes. They wanted to go horizontal. Some wanted to go pre-sales and be a solutions architect, and that already had a name. After the sale, it didn't.

There were actually two gaps. One was post-sale engagement: I'm going to come in, learn your business, and keep helping you build on the software we just sold you. There's a CSM, there are still solutions architects, but there wasn't a name for that continuous role. The other was the internal person building and hacking with low-code tools across the whole org. We called those people no-code operators. Hence NoCodeOps.

And as much as I love no-code, it never caught the mainstream. People didn't care.

How Palantir's Forward Deployed Engineer became the Forward Deployed Operator

Phil: Palantir is one of the companies that made this role really popular. The idea of a Forward Deployed Engineer had been around a while: instead of engineers sitting internally building features based on customer needs, tied closely to sales but working with product, Palantir asked what if we forward deploy them into the customer and embed them there. They'd run a workshop, get the information out, and build alongside the client.

Essentially a no-code operator partnering with a business person to make things happen on the Palantir platform. But highly technical.

So I was helping a friend hire for something like this, and it wasn't quite a Forward Deployed Engineer. He said, "What about Forward Deployed Operator?" This is Jonathan, who leads innovation at Howard Hughes. He's brilliant. And I said, that's the term, that's it, you nailed it.

Because there's a real gap. Look at what exists today. All the vertical roles, sales ops, marketing ops, people ops. GTM ops and GTM engineering spanning a few functions. Pre-sales solutions architecture. What you don't have is something that goes horizontal across many departments internally but isn't quite engineering level, and honestly doesn't need to be. That's the part.

I also think there will be two versions of the Forward Deployed Operator, internal and external. The external one is more post-sales, helping people build on your software platform.

And then, of course, I searched the term to see if anyone else was talking about it. You were the only one.

Ysi: I was on a family vacation, on a cruise, when your message came through on LinkedIn. And I thought: somebody finally saw me. Because up to that point it was, yes, we know you're obsessed with your work, move along.

What you said about departments forming their own internal roles rings completely true. I was leading projects like that inside supply chain for years, and I was under the radar, because in a large organization you're not supposed to build anything without IT approval. Sometimes I'd just do it and confess afterward.

Phil: We've all played in the shadows.

Ysi: And it happens across every industry, not just software. Even nonprofits need solutions built fast, and they can't hire an entire IT department, because the funding isn't there. A Forward Deployed Operator can come in, look at the process, work out what genuinely needs automating, prioritize what matters, automate some of it and completely reinvent the rest.

Phil: Exactly. Then build the prototype, then get the funding for the real thing.

Why AI got easy and most people still didn't come

Phil: Here's the funniest thing about this world. When AI first started getting easy, those of us from no-code thought: hold on, this is about to be easy for everybody. Everyone will want to do it. There was a learning curve for Zapier, small but real. So we assumed that once the learning curve dropped to just typing what you want, the whole world would flood into our industry.

And what happened? Crickets, in terms of the overall knowledge worker population. There are new people, and don't get me wrong, it's happening, just nowhere near as many as you'd expect. That's mind-blowing to people like you and me. Do you have a theory?

Ysi: I do, but I'm curious about yours first.

Phil: Mine is that there's a figure-it-out gene. Some people have it and some don't. If you don't have it, you don't have it. There's also a neurodivergence lens here. Someone like me with ADHD looks at this and thinks it's a dream come true.

And people who were already in this world think it's the best thing since sliced bread, while everyone else still doesn't know any of it was ever possible. The number of large companies that come to me saying "we need agents" when what they're describing is a deterministic automation workflow they could have built ten years ago.

So maybe it's a lack of awareness about what's actually possible and how easy it actually is. And not enough people willing to be hands-on, teach one to one, and engineer the aha moment. What about you?

Ysi: That's exactly where I was going. Some people have the gene. But I also think people are afraid to be hands-on, and there may not be enough people around to hold their hand and say: this is all you do.

Since I launched the company, the question I get most is which AI training I recommend. And I say: try it. Just start typing. I started reading Co-Intelligence, and the first line is perfect. You are three sleepless nights away from understanding AI.

Phil: I could not agree more. That's all it is. But people feel like they still need permission, or they don't know AI does anything beyond chat.

We're doing an event series in Atlanta, I'll soft launch it here. Zapier has a goal of training a million people on AI, and it can be virtual, online, free. I want to do it in person and represent my city. So I'm putting flyers up around Old Fourth Ward where I am, and I'll be at a spot down the street that fits maybe forty people. Come for free, whatever level you're at, and I'll train you on AI. We film all of it. The goal is to grow it until I've had enough people through that I could fill a stadium and do twenty thousand at once.

The Compass story: letting people pick the tool

Ysi: I want to hear the Compass story again, because I enjoy a duct-tape prototype that goes the right way.

Phil: Before Compass I was somewhere I discovered no-code, onboarding, and my love for all of it. Very duct-tapey. That's where I found Zapier. Then there were layoffs, and they cut the whole US department because we'd merged with another company and they went with the other on-the-ground staff.

When I was looking for a new job I had no idea how to package myself. I glue things together. I like processes. I don't really code but I'm interested in all of it. I know something about onboarding. What do you even call that? At the time I called it onboarding specialist, which was decent.

A platform called Underdog put my resume in front of Compass, and Compass hired me to lead onboarding for all their agents across the US. They had disparate processes and wanted them unified.

My job was to do a listening tour and have everyone yell at me about how janky the process was. Then three months of vendor research, letting vendors teach me about the whole onboarding space. I found a tool called Enboarder, and its standout feature at the time was that it could go text-message-first. A lot of real estate agents live in text. So I thought, if we can get out of their email and into text, we onboard them far better. The workflows felt like no-code, which I knew, and you could nuance them regionally while keeping one main flow.

So I found the thing. Nobody had done this much research. But I'd been to a change management workshop, and something from the listening tour crossed with it: people were exhausted by the national team in New York pushing things out without listening.

So I thought, what if instead of imposing this, we ran a demo period? One region trials one tool, another region trials another, and one region trials this new one. In public, with each other.

The VP of operations called me insane. He said, I'll just give you the budget, take the tool, this is great. And I said, yes, but I want their buy-in.

My tool won about ninety-five percent. Which was great, but if it hadn't, then I was wrong and they wouldn't have adopted it anyway. And we got the highest eNPS score our department ever had, because people felt part of the process, could give feedback, and were bought in.

Change management starts before the build

Ysi: That's the methodology I've used at Vantelira and for nearly twenty years before it. Once people are testing with you and giving feedback as you go, the change management is already happening alongside.

Phil: It's happening without your permission. It just happened.

Ysi: I recently finished a project and asked the client when he wanted me to come train the team on the custom tool we'd built. He said, we don't need you. They already know how to use it, we've been testing it with you the whole time.

Phil: Huge. And it starts before the build.

Ysi: Exactly. And that's part of the role people miss: enabling people, getting them to love the tools.

What the operator has to be full stack at

Phil: That's where forward deployed engineering and forward deployed operations part ways, in a good way. Engineers are genuinely good at listening, interpreting, working out how something should work, and moving fast, especially with how these tools work now. Some of them own enablement too.

But on the ops side you have no excuse. You have to be full stack. Listen, prioritize, build, bring people along so you're doing the right thing, get buy-in from the right stakeholders, and do the reporting at the end to show it was positive and what you learned. Nobody is going to do that for you. You have to be good at all of it.

That's why the cohort we're running isn't mainly about build skills. That's probably the smallest part, because everyone coming into the Forward Deployed Operator school already has building experience. It's all the other things, the packaging side and taking a project full cycle internally.

Why the role may fit better outside of tech

Ysi: How do you feel about this being industry agnostic? The role isn't only for tech.

Phil: I think the people who'll have the most fun with it are outside tech. The technical person on the team at a mining company, or a gas and electric utility, or in consumer goods.

Because in tech, everyone thinks they know everything. We're all know-it-alls. Outside our bubble, it still blows my mind when someone says: hold on, if someone submits this form, I get an email, and it can automatically write a custom reply from me? That's still astonishing to most of the population.

Ysi: I'm a testament to it. It's the most fun I've ever had.

Applying The Mom Test to internal stakeholders

Ysi: Before we use Zapier, automate a process or build anything, what do people need to fully understand about their own processes first?

Phil: It's hard for figure-it-out people, no-code people, forward deployed operator people, ADHD people like me, because we all start tool-first. We get excited about a capability and then go looking for a problem to attach to it. That's not good. I've fallen victim many times. I'll fall victim again. The only metric I hold myself to is how fast I catch myself, because I will never stop having shiny object syndrome.

But say you get past that. The first thing I do, and we'll do this in the cohort, is have everyone read The Mom Test, which to me is the bible on customer conversations. Then apply it to internal stakeholders.

The idea behind the name: give your mom an iPad with a cooking app you just built and ask if she'd use it. She'll say she loves it. Nobody wants to give you negative feedback, and your mom loves you. People behave exactly like that when you put a solution in front of them.

The real challenge is putting the solution completely away and understanding the problem deeply. Where is this going wrong? How have you tried to solve it so far? Does it even matter enough that you've tried? If you've never tried to solve it at all, should we be building here at all? Oh, that leads to this other thing you do, tell me about that. And on and on.

Is the problem worth solving?

Phil: Then there's the other side: is it worth solving? Those aren't the same question. There can be a deep problem set that one person or a small group has, but it doesn't affect anything else that matters much. So should we spend our time there? You have to develop taste and judgment on both sides.

Ysi: So you'd agree that a Forward Deployed Operator is defined by what they do first, not by the tools they know or the code they can write.

Phil: What do they do first when presented with a problem or a potential solution? Building is easy. The skill is talking to people, looking at things, and saying: there's a pattern here, let's pull on that. That's where the magic lives. Deploying the solution is easy now and will get easier. This is the harder part.

The SAP story: fixing the system before walking the floor

Ysi: I have a story about a day I went shiny-object first.

We were dealing with on-time delivery for customer orders, and everyone was digging into why we weren't delivering on time. Someone found a solution, and it was in the system. We were on SAP. They handed me the IT ticket: here's what needs fixing, here's how order dates should be promised automatically when the customer enters the order.

I said fine, let's implement it. We did. The KPIs came out and nothing changed. Customers kept complaining.

So I stopped and asked what I'd done wrong. And the answer was that I had never gone to the warehouse and walked the floor. I started talking to customer service and the warehouse people, and I realized they had a process: orders were fulfilled same day if they arrived before noon. If an order came in during the afternoon, it could not be promised same day. But the system still thought it could.

We went back and adjusted it so that when a customer ordered after noon, the system told them it would go out the next day. That was it. The customer knew in advance, and they were happy.

Gemba walks, and the step people skip

Phil: We used to do this at Compass too, going out in the field with agents. At the ride-share company I was at before, people would get their TLC license in New York and drive the car themselves. Getting on the factory floor. Being as close as possible.

If you don't talk to those people, you're dead from day one. But here's the tricky part: it doesn't mean they have the solution. Some think they do, some actually might, but that doesn't make it so. If you'd talked to a hundred people before the iPhone came out, none of them would have produced the iPhone.

Still, talking to people is the thing people skip most.

Ysi: There's a term for it in Lean Six Sigma and lean manufacturing: a Gemba walk. Literally going and walking the process with the people who do it. And we can do that digitally now too.

Three questions to ask before your first ops hire

Ysi: I want to make this a tradition, where each guest leaves a question for the next one. Some context: the next guest is a founder deep in operational reality, scaling a product-based business, a CPG brand. They're at the moment of hiring their first ops person or technical hire. What should they be asking themselves to make sure they hire the right person?

Phil: They should have some sense of their biggest bottleneck or constraint. Because of the theory of constraints, if you fix anything before or after it, you just make things worse. They should answer that for themselves first.

Then, when they're talking to candidates, they should ask three things about AI.

One: show me something you built outside of work. If you're not doing anything on this front outside work, you're probably not a fit.

Two: tell me what you do with AI beyond chat, and describe it deeply.

Three: walk me through a process you didn't just add an automation to, but completely reinvented with this stuff.

If they can answer all three, you're in great territory.

Ysi: Thank you so much, Phil. We could go for hours.

Phil: And we will, in the future.

Closing

Ysi: That was Phil Lakin. Two people who came from opposite sides of the same table and landed in the same place. He built his from digitizing paper-based operations in the field. I built mine untangling manual ones on the supply chain side. Same mess, different industry. And we both learned that the tool only works after you've mapped what is actually happening. That's the whole idea behind this show.

Before he left, Phil did something we'll do every episode: he left a question for the next guest. He actually left three, all about deciding who to bring onto the team. And I know exactly who's going to answer them.

Next time you'll hear from someone who has lived the back-end operations of building and scaling a consumer brand. Co-packers, 3PLs, the order that didn't ship, the spreadsheet holding it all together. Not the highlight reel, the real operation.

If you're building a brand and the whole thing still runs through your phone, if you can feel the mess but can't quite point at it, you'll recognize your operation in these conversations. I believe this category is going to be everywhere in a couple of years, and consumer brands are not going to be left out.

Follow along, and see you next time on The Forward Deployed Operator.

Related