How Forward Deployed Engineering is done Kepler

What should forward deployed engineers do when the product they are supposed to deploy does not yet exist? In Ganesh’s account of Palantir around 2013, that was the starting problem. Forward deployed engineering later became a go-to-market strategy, but the work that led to Foundry began as a way to discover and build the product itself.

Ganesh came to that work through horizontally scalable storage systems and deployments to Iraq and Afghanistan, including Bagram. The question was how to make software work for people operating in critical environments. He created Project Frontline, a rotation program that moved software engineers into forward deployed work. Ganesh reports that about 350 engineers passed through the program, including people who later worked at OpenAI, Anthropic, and xAI. He subsequently built a similar program at Citadel, where the objective was to build data and software products that helped portfolio managers generate alpha.

A post he presents from Shyam Sankar frames FDE as a product strategy rather than a role. The practical distinction is the evaluation criterion: an FDE should identify opportunities and generalize customer solutions into product capabilities, not merely qualify an account by its market capitalization or contract size. That is the approach Ganesh is applying at Kepler with founding engineer Susanna.

Palantir’s internal Phoenix project was intended to store transaction information as the company moved into big data. The team designed it in isolation, without understanding the financial customers whose data it would ingest. For a large financial institution, the design used time-bucketed keyspaces to make retention and roll-off easy: old data could be removed by retiring its bucket. The design worked under its assumed conditions. Real data broke those assumptions.

A blank date defaulted to the Unix epoch, January 1, 1970. The retention logic then attempted to create a window for every ten-minute interval between that date and 2013. A missing value had become an instruction to allocate decades of storage structures. Ganesh recalls 2.3 million keyspaces, a five-megabyte cost per Cassandra file handle, and a startup requirement of 14 terabytes of RAM. Those figures are his incident recollection, not a general Cassandra sizing rule; the stated count and per-handle cost alone multiply to 11.5 decimal terabytes, leaving the rest of the reported total unexplained.

There was no other team to call to make the deployment work. The failure exposed more than a missing piece of customer research: the engineers had designed the system without sharing responsibility for building it inside the customer’s environment. Embedded ownership changes what a product team learns and what it must fix. The four field lessons that follow develop that distinction.

At a shipping and dispatch company, the VP of operations supplied a 47-page requirements document for a custom dashboard with 14 metrics and drill-down alerts. Development was estimated at three months. The team spent four months scoping the engagement before an engineer happened to visit the site while near family and asked: “What's the first thing you do with this information Monday morning?”

The operational sequence was much smaller than the requested BI system: check whether trucks were late, then call dispatch to arrange a response. A Slack alert could provide the signal that triggered that work. Ganesh reports that the team solved the dispatch problem end to end in four hours. The intervention changed the scope by identifying what the information was for.

Before building, establish three things:

1. The goal: What is the customer trying to accomplish?
2. The next action: What happens after the customer receives the answer or solution?
3. The current method: How does the customer solve the problem today?

A dashboard is one possible implementation. The operational goal determines whether it is necessary.

This is the XY problem in field engineering: the customer describes a proposed solution, and the engineer must recover the underlying problem. Ganesh’s working heuristic is to build, ship, and close the loop when the actual fix takes less than a day. A bounded fix does not need to become an expanded product vision or a new round of product-management coordination.

Defining the problem also gives the team ownership of the solution and a basis for deciding what should come next. This explains the value of FDEs in early sales: small, successful fixes win trust and access to deeper problems. Their usefulness does not depend on being unusually sociable engineers. Ganesh traces Foundry’s ability to generalize across verticals to tens of thousands of hours of this field work—solving specific problems, then extracting capabilities that belong in a shared product.

Another customer received about a terabyte of data each day in an S3 bucket, putting pressure on the delivery pipelines. The engineering team proposed replacing large CSV deliveries with Apache Parquet to reduce pipeline, compute, and data costs. One data quality engineer opposed the migration for about a year. Repeated explanations of the technical benefits did not resolve her objection.

An on-site visit made the missing requirement visible. She downloaded CSV files from S3 to her Windows computer, double-clicked them, and spot-checked the data. In her existing workflow, Parquet had no equivalent reader she could simply open. Changing the format would remove an essential inspection step. The team built a Parquet viewer that night.

Ganesh says the migration was approved within the next two days and recalls, tentatively, that pipeline execution fell from 17 hours to about two. He also reports lower data costs without quantifying them. The enabling change was a viewer that preserved the user’s ability to inspect data; the pipeline optimization could proceed once that workflow survived the migration.

Watching the work produces a different kind of evidence from asking whether someone likes a proposed feature. Look for:

• Repetition: The same task performed repeatedly within an hour, day, or week.
• Manual transfers: Copying and pasting between tools.
• Exasperation: A user describing a step as something they reluctantly have to do.
• Context switching: Moving between tools or tabs to finish one job.
• Waiting: Pulling out a phone mid-task, which can signal slow or annoying software.

These are prompts to investigate the workflow, not automatic proof of a particular solution.

A useful opening question is: “What's the most annoying part of your morning?” Solving a small, repeated irritation changes the user’s next working day and earns access to the pain that should shape the product. Maria’s inspection workflow became visible because the team was inside the customer’s building. Ganesh describes the on-site badge and contractor email address as permits to discover how work actually happens. His insistence on physical presence comes from deployments ranging from Iraq and Afghanistan to offices in Palo Alto and San Francisco: scheduled surveys and remote conference rooms do not expose everything that a resident sees.

Inside a logistics organization, different teams used different names for the same entity:

Those differences became integration failures, data quality problems, and broken pipelines. Each team’s language made sense within its own environment; the difficulty appeared when information crossed between them.

Ganesh describes the ontology as a response to this human coordination problem, rather than the result of putting everything into Elasticsearch and imposing schemas. Nouns define entities; verbs define operations. Field engineers had to discover both and decide how the software would express them. In his recollection, this customer settled on “customers”; other organizations might canonicalize around IDs. Even an apparently established metric such as daily active users can mean high-quality activity to a product team and simply the number of people who logged in to InfoSec.

Product adoption also spreads vocabulary. Ganesh points to the uptake of terms such as skills and MCPs, including loose uses of MCP terminology for function calls with prompts. The engineering task is to identify which phrases are overloaded and where the meanings change. Trace integration paths—Snowflake to Databricks, Palantir to Tableau, or Anthropic to SAP—and locate the translation layers. Then establish the system boundaries and the systems of record that cannot simply be replaced.

The same discipline applies to an AI failure report. If a customer says an agent keeps failing, first establish what “agent” names in that system: a prompt, a sequence of steps, or some other unit of behavior. Defining the terms makes the problem concrete enough to model. Once those definitions are codified in the platform, users can reason about subsequent problems through the same vocabulary. That is the basis of Ganesh’s lock-in argument: the product becomes the language in which the organization describes its work.

The Foundry ontology made those definitions part of a reusable platform. In Ganesh’s historical account, that foundation enabled a later generation of go-to-market FDEs to integrate customer data and sell an existing product. The engineers building the foundation had first needed to discover the entities, operations, and boundaries through deployment work.

A customer needed data retention, so Ganesh wrote a quick Groovy script as a temporary fix. It solved the immediate issue without being designed for production. Ganesh says that 12 months later, the script had spread across multiple deployments inside a customer with almost 100,000 people. The association became so durable that it became his nickname at Palantir; guests even wore shirts bearing that nickname at his wedding.

The team had fixed a problem without deciding the end state or turning the solution into a product capability. It consequently supported the hack for years. This is the failure mode hidden inside a definition of FDE as simply making the customer successful: a customer can benefit while the product accumulates obligations and gains little reusable capability.

Ganesh assigns customer-success work to solutions architects and holds FDEs to an additional product-building obligation. Before shipping, make the support boundary explicit:

1. Future incidents: Is this likely to produce a 2:00 AM call six months from now?
2. Product trade-offs: Does immediate relief create maintenance costs that compound across the product?
3. Handoff: Who receives the system when the engineer leaves—the customer, another institution, or another FDE?
4. Failure ownership: Who responds when it breaks, and what mission-critical work depends on it?
5. Disposition: Should the fix enter the core offering, or should it be discarded?

A quick implementation still needs a decision about its lifetime and owner.

For a retention tool, one useful implementation boundary is to separate selecting expired records from deleting them. The following Groovy example makes a retention proposal visible without performing deletion. It uses a fixed cutoff and rejects missing dates rather than silently treating them as ancient data:

import java.time.Instant

List<Map> proposeRetention(List<Map> records, Instant cutoff) {
    records.collect { record ->
        if (!(record.createdAt instanceof Instant)) {
            throw new IllegalArgumentException(
                "Missing or invalid createdAt for ${record.id}"
            )
        }
        [
            id: record.id,
            createdAt: record.createdAt,
            proposedAction: record.createdAt.isBefore(cutoff)
                ? 'DELETE'
                : 'KEEP'
        ]
    }
}

def records = [
    [id: 'tx-1', createdAt: Instant.parse('2025-01-01T00:00:00Z')],
    [id: 'tx-2', createdAt: Instant.parse('2025-07-01T00:00:00Z')]
]
def cutoff = Instant.parse('2025-06-01T00:00:00Z')
def proposal = proposeRetention(records, cutoff)
proposal.each { println "${it.id}: ${it.proposedAction}" }

Here, tx-1 is proposed for deletion and tx-2 for preservation; neither record is deleted. The separation creates something an owner can inspect and hand off. It does not replace the decisions about authorization, execution, and failure handling that a deployed retention system needs.

The dangerous assumption is that usefulness will expire because the code was called temporary. Ganesh invokes decades-old COBOL running on IBM mainframes as a reminder of how long software can outlive its original intent. His planning rule is to ship as though the solution will run for 18 months. That horizon forces a distinction between a fix that earns customer goodwill and a capability that belongs in the core product.

Requirements intake, scheduled research, and recorded insights are not enough if none of them changes the product. The Frontline standard joined discovery to delivery: redefine the problem, get access to the customer’s workplace, and go wherever the work happens. Ganesh’s examples include Afghanistan, Iraq, Somalia, and a colleague working on an oil rig. Physical deployment was a means of reaching the operational reality the software had to support.

The engineer then shipped a fix before leaving, owned it within the product ecosystem, and translated the observed problem into reusable nouns and verbs. Ownership included taking the call when something broke and traveling when necessary. The evaluation question is what shipped into the product, not merely what the engineer learned. This closes the loop between field access and a stronger shared platform.

Ganesh grounds the value of that shared platform in the decisions it supports: Citadel portfolio managers trading hundreds of millions of dollars, Palantir’s warfighter environments, and commercial customer operations. At Kepler, he is applying FDE as an extension of product development to build products customers continue to use because they solve consequential problems.

The company’s stage matters. An established Palantir can deploy engineers around a product foundation built over many years. An early-stage company must first discover the product that will make those deployments effective. Treating FDE primarily as a go-to-market extension before that foundation exists risks scaling customer-specific work without building the reusable product underneath it.