Hello! 👋
It's Thursday, 3rd September 2026. Hello and welcome back to Bold Efforts!
There is a strange problem emerging inside companies.
They have access to increasingly powerful AI models. They have bought the software, run the pilots, and probably watched an impressive demo. Yet six months later, remarkably little about how the company actually works has changed.
The technology is not necessarily the problem. The problem is the gap between what technology can do and what an organization can actually make it do.
A relatively new role is emerging around that gap: the Forward Deployed Engineer.
The name makes it sound far more technical than the idea really is. A Forward Deployed Engineer, or FDE, goes inside a company, understands a real business problem, figures out how technology might solve it, builds the solution, and stays close enough to make sure people actually use it.
Think less about a software engineer sitting somewhere building features. Think more about someone responsible for making the technology work in the real world.
Palantir pioneered this model two decades ago. Today, companies across the AI industry are building similar teams. The interesting part, however, is not the job title itself. It is what the rise of FDEs tells us about where work, software, and companies might be going.
Software was supposed to remove the service
For much of the last twenty years, the dream of software was standardization. Build something once, sell it to thousands of companies, and let customers configure it themselves.
This was part of what made software such an extraordinary business. A consulting company might need more consultants every time it added customers. A software company could theoretically add thousands of customers without adding thousands of employees.
So software businesses tried very hard not to become service businesses. Customization was undesirable, implementation was something to streamline, and human involvement was something to minimize wherever possible.
AI is starting to complicate this idea.
Imagine giving the same powerful AI model to a hospital, a logistics company, a bank, and a hotel. The underlying technology might be identical, but the valuable thing it can do inside each organization will be completely different.
Someone therefore needs to understand how the organization actually works. Where does information come from? What does someone do with it? Which decisions require judgment? Which tasks are repetitive? Which systems need to talk to each other? What can be automated, and what should never be automated?
Most importantly, someone needs to understand what would actually make the work meaningfully better.
You cannot answer these questions from a product dashboard or a demo environment. You have to go into the mess of the real organization. That is what forward deployed teams do.
But this cannot become consulting
There is an obvious problem with this model. If every new customer requires engineers to build something completely different, you have not created a scalable software company. You have created a consulting company with better technology.
This is where the second half of the FDE model becomes important.
The job is not simply to solve one customer's problem. It is to learn from solving it.
An FDE might discover that five customers are trying to perform slightly different versions of the same workflow. Instead of continuing to build five custom solutions, the company can turn those lessons into a reusable product capability.
Something that started as a customer-specific solution gradually becomes part of the product itself.
This creates an interesting loop. Build alongside the customer, observe what actually works, turn repeated problems into product, deploy the improved product to the next customer, and repeat.
The service and the product are no longer opposites. The service becomes one of the ways the product learns.
That is a very different model from traditional consulting. In consulting, the knowledge often leaves with the team. In the forward deployed model, the objective is to make what was learned reusable.
The customer is therefore not just buying the product. In some ways, the customer is helping teach the company what the product should become.
The scarce skill might be application
Over the last few years, people have spent enormous amounts of time discussing the intelligence of AI models. Which model is smartest? Which benchmark did it beat? How large is the context window? Can it reason? Can it code?
Those questions matter, but there is another possibility worth considering.
As powerful models become widely available, access to intelligence itself may become less scarce. Knowing what to do with that intelligence becomes more valuable.
Imagine two companies with access to exactly the same AI. One uses it to summarize meetings. The other redesigns an entire operational process around it and cuts a task that previously took three days to thirty minutes.
The difference was not the model. The difference was understanding the problem well enough to redesign the work around the technology.
This is why domain knowledge may become more important, not less.
Understanding how an insurance claim gets processed, how an airport handles disruptions, how a recruiter evaluates candidates, or how a hotel manages revenue may become extraordinarily valuable when combined with the ability to reshape those processes using AI.
The interesting worker of the AI era might therefore not be the person who knows the most about AI. It might be the person who understands a valuable problem deeply enough to apply AI to it.
Jobs may become wider again
The Forward Deployed Engineer also breaks another convention of modern work.
Companies have spent decades dividing work into increasingly specialized functions. Strategy understands the problem. Product defines the requirements. Design creates the experience. Engineering builds the software. Implementation deploys it. Customer success makes sure people use it. Sales convinces the next customer to buy it.
Each handoff made sense as organizations became larger and more complicated. It also created an enormous amount of coordination.
The FDE model compresses many of these responsibilities.
One person, or a very small team, can sit with a customer, understand a problem, prototype something, build it, deploy it, watch people use it, improve it, and bring what they learned back into the product. They may even be involved before the sale, demonstrating that the technology can solve a valuable problem before the customer commits.
That is unusual because the people building the technology are suddenly much closer to the customer and much closer to revenue.
AI makes this compression even more powerful. Someone who previously needed an engineering team to test an idea might now build the first version themselves. Someone who could build but struggled with design can use AI to help. Someone unfamiliar with a technical system can understand it much faster.
The boundaries between roles start becoming less rigid.
The consequence might be fewer people passing work between each other and more people owning problems from beginning to end.
That sounds like a subtle organizational change. I think it could be a profound one.
From selling tools to owning outcomes
There is also a deeper business shift happening underneath all of this.
For years, software companies largely sold tools. Here is our CRM. Here is our analytics platform. Here is our recruiting software. Here is our productivity suite.
What happened after the customer bought the software was partly the customer's problem.
AI companies increasingly have the ability to go further.
Instead of selling recruiting software, help the company make the hire. Instead of selling customer service software, resolve the customer's questions. Instead of giving an analyst a tool, produce the analysis.
The closer a technology company moves toward the actual outcome, the harder it becomes to simply hand over software and walk away.
Someone has to understand the work before it can be automated. Someone has to deal with all the strange exceptions that never appeared in the product demo. Someone has to notice that the process everyone described in the meeting is not actually the process employees follow. Someone has to earn enough trust for people to change how they work.
That person starts looking a lot like a Forward Deployed Engineer.
This is why I suspect FDEs are not just another fashionable AI job. They are an early version of a much broader type of worker: someone who can move comfortably between technology and business, between thinking and building, and between identifying a problem and actually solving it.
The future might belong to people who can cross boundaries
We tend to imagine technological change as creating new specialists. Perhaps AI does the opposite.
When intelligence and technical capability become easier to access, the advantage may shift toward people who can combine things that previously lived in separate professions.
The valuable person understands the business, talks to the customer, uses the technology, builds something, changes the workflow, measures whether it worked, turns what they learned into something reusable, and then does it again.
Today, we happen to call some of these people Forward Deployed Engineers. Tomorrow, we might just call them good operators. Thank you for reading.
Best,
Kartik
I write Bold Efforts every week to think clearly about where work and life are actually headed. If you want these essays in your inbox, you can subscribe here.