Watch modeSubscribed

Latent Space · 4 min · Oct 22, 2026

Modal uses forward-deployed engineers to turn customer work into product

  • Shawn Wang (swyx)Host · Co-founder, AI Engineer

    Wrote “The Rise of the AI Engineer” and founded Smol AI, maker of AI News.

  • Alessio FanelliHost · Founder, Kernel Labs

    Partner at Decibel, backing technical founders who build developer tools.

About this segment

Modal grew its forward-deployed team from four to about 24 in a year. They tune customer workloads and surface recurring needs that can become self-serve features.

From “Why AI Compute Comes in Rectangles — Erik Bernhardsson, Modal”, Oct 22, 2026. Watch the full episode

“I think we started this year having like four FDs. Now I think we have like 24 or something like that.”
Erik Bernhardssonat 58:19 · Latent Space58:19

Takeaways

  1. FDEs help tune inference, resolve issues and migrate workloads.
  2. Their highest-value role is exposing product gaps.
  3. The long-term aim is to turn bespoke help into product features.

In this episode

Full episode
  1. 18:04GPU price drops can be riskier than continued scarcity3:39
  2. 43:35Fast sandbox snapshots could make parallel work practical3:39
  3. 52:58Good developer experience also helps coding agents4:46
  4. 13:37Modal built a procurement team as GPU supply tightened3:41
  5. 28:28Neoclouds scale by pre-selling capacity to finance GPUs3:57
  6. 58:05Modal uses forward-deployed engineers to turn customer work into product4:17

  7. 39:14Small training is underserved, while fine-tuning is optional2:36Up next
  8. 1:21:24Inference providers can shift capacity as model demand moves3:29

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

  1. 58:18

    And we see a lot of companies that need a little bit of help. And so we started investing in FDEs a couple years ago, but it's really been this year. We've kind of scaled it up a lot. I think we started this year having like four FDs. Now I think we have like 24 or something like that. So we've grown a lot. And they do, you know, it's more, it's not exactly the Palantir model, but they do a lot of like heavy, you know, sort of customer engagement.

  2. 58:43

    Like they work with a lot of customers on performance tuning, especially with LMs. We see that there's so much benefit from like, you know, sitting down with customers and training draft models and tweaking, you know, parameters and DLM and SGLang. They often, you know, fix bugs or not fixed bugs, but like, you know, when customers run into issues, like they often work with customers trying to figure out like, how do we work around that?

  3. 59:07

    Or another thing we've used FDs a lot for is like just kind of proactively, you know, if we see certain customers, you know, over provisioning with modal, like customers requesting too much CPU or too much memory, for instance, like that's kind of expensive. And like, we try to catch those things and we try to sit down with those customers like, yo, like you're spending a lot of money on modal right now.

  4. 59:26

    We can actually help you save money. And then of course, like with sort of active deals. We help them migrate code from other platforms, things like that. I think we never have the intention of becoming a service-heavy business. I think that the goal for FDs is A, is to be part of the sales process and closing deals. B, is to serve customers and do some customer support. But I actually think the most important thing is C, is bridging gaps in the product.

  5. 1:00:00

    that we later want to turn into like real features. So I think to a large extent, you know, anything an FTE does, you know, my question is always like long-term, how do we turn this into products so that we don't need an FTE for this? Yeah. Do you guys hire PMs? Product managers? Yeah. No. Would you say these FTEs are kind of like pseudo-ish PMs? It's a little bit of a different function. Like I think certainly on the more like, you know, customer facing side they are, But there's like, you know, on the more like inward, you know, internal side, like this is a sort of separate part of like product management, which is more like, what are the next building blocks Modo should invest in? And like, you know, and then there's like something in between, like, you know, looking at like maybe 10, 20 different customers, they're all asking for like slightly different things, but maybe what are the patterns? Like, how do we turn this into product?

  6. 1:00:47

    We do have people doing product with us and it's sort of evolved. We've had people basically become product managers after previously being either DevRel or engineers and just showing strong aptitude on doing, thinking very strategically about what we have to build. So I'm actually not anti-product management. I do think that a lot of companies in the past hired product managers too eagerly. And I think there's a risk that you kind of, I can sort of see it in a lot of products, like certain products, like you can tell, like, there's just like eager product managers that just thought of like kind of like widgety things and just ship them.

  7. 1:01:28

    I think doing product management at an infra company really well is very, very hard because I think it takes like a very deep level of strategic thinking, thinking about like, what are the foundational building blocks? Where do we want to be in one to two years? Because the truth is building infrastructure is very hard. and how do we make sure we don't end up with like 35 features that are like kind of similar looking but all do like a little bit slightly different things.

  8. 1:01:53

    That sort of level of thinking is something that, you know, is very rare to find. And for that reason, we haven't aggressively tried to build up a product management team yet. Yeah, that makes sense. How would you say your teams have been evolving maybe like since Genialite? Because I would assume, yeah, I mean, you obviously worked at like Spotify. You had like a certain team structure.