This chapter establishes the scope of the talk and the perspective from which the speaker is talking. It then gives a working definition of forward-deployed engineering (FDE) and previews the structure of the full talk.
This talk is not aimed only at software engineers. It is also useful for startups and early-stage teams, technical product or go-to-market leaders, and organizations considering whether to adopt FDE. People who build products, sell them, or think about applying them to customer operations can therefore read it from their own perspective.
講演者の背景
The Speaker's Background
Kevin Baiは、Anthropicの応用AIチームでtechnical staffとして働いていると自己紹介します。また、以前はRipplingで最初のforward-deployed機能を作り、Palantirでも働いていたと説明します。つまり、FDEを顧客に近いソフトウェア開発の実務として経験してきた人です。
Kevin Bai introduces himself as a member of Anthropic's applied AI team, where he works as technical staff. He also says that he previously built Rippling's first forward-deployed function and worked at Palantir. In other words, he has experienced FDE as practical, customer-near software development.
The important point here is to separate background from evidence. Experience at Rippling and Palantir shows why the speaker has relevant experience to explain this topic. However, those company names alone do not prove that FDE is effective. In the talk, he uses this experience as a starting point to explain the role, its business rationale, and how to think about applying it to other companies.
In this talk, FDE is a customer-facing software-engineering role and function. An FDE understands a customer's business and operational problems, then uses a shared technical foundation—a platform—to build a software solution for that customer. The job is not only to explain how to use the product. It also involves building an application or workflow suited to the customer's situation.
FDE is not the same as an ordinary software engineer. An ordinary engineer mainly builds the product itself for a broad set of users. An FDE, by contrast, works directly with the customer, understands the customer's specific problem, and builds a solution on top of the product or platform.
FDE is also not exactly the same as a consultant. A consultant may focus on advice or business-process design. An FDE needs that understanding of the customer's work as well as the ability to implement software. The role is different from a simple implementation role too. An implementation specialist helps with configuration or rollout, whereas an FDE builds a customer solution on a technically deep platform. In an actual organization, these roles may still overlap in some ways.
例：同じ製品でも支援の形が違う場合
Example: Different Forms of Support for the Same Product
For example, suppose a development tool can be configured and used directly by developers. The engineers at the company that buys it may be able to handle adoption and extension themselves. In that case, support from the product team or developer-focused support may be enough, and an FDE may not be necessary.
By contrast, a business leader who is not deeply technical may buy a platform that connects several kinds of company data and builds applications for the company's work. The buyer may understand the value but may not have the time or expertise to implement it personally. FDE fills the gap between that understanding and implementation.
This is an example for understanding the talk as a whole. More important than whether the role is called FDE is identifying who will perform the technical work the customer needs.
この講演で使う中心概念
Core Concepts Used in This Talk
講演を読むときは、次の概念をつなげてください。
As you read the talk, connect the following concepts.
Platform: A shared technical foundation that can be reused to create solutions for multiple customers.
Outcome: A result in the customer's business, such as higher sales or improved operations, rather than data simply being organized.
Enterprise buyer: The decision-maker in a large organization who purchases the product. This person is not necessarily the same as the user or the engineer who implements it.
Shared primitives: Reusable basic building blocks for assembling solutions. They prevent the team from building everything from zero each time.
Go-to-market (GTM): The way a product is delivered to and sold to particular customers, and connected to customer outcomes.
In the speaker's explanation, FDE is not only about placing people close to customers. The central idea is to use a platform and shared building blocks to create customer-specific solutions, then deliver business outcomes through those solutions. For that reason, FDE concerns staffing, but it also concerns product design and go-to-market.
講演全体の道筋
The Roadmap for the Talk
Kevinは、この講演をFDEの歴史と実践的な入門として紹介します。話は次の順番で進みます。
Kevin presents the talk as a history and practical introduction to FDE. It proceeds in the following order.
We first examine the meaning of the role: what kind of work does an FDE do?
We then examine Palantir's model, including the Foundry platform and how it delivers customer outcomes.
Next, we consider why Palantir needed this GTM and what combinations of product and buyer make FDE necessary.
We consider whether the model can apply to other organizations, asking not only whether they want FDE but whether they truly need it and have a platform to support it.
We examine the meaning of the AI era. As AI increases the amount of customizable software, customers may find it harder to understand and implement that software on their own. The speaker presents this as his own hypothesis.
Finally, he answers audience questions about the granularity of shared primitives, collaboration among multiple FDEs, and the boundary between customer-specific features and the shared platform.
Therefore, in later chapters, do not think of FDE simply as a job that writes code at the customer's site. We first examine the relationship between a product's technical complexity and the buyer's technical ability. Next, we look at how to combine service that delivers customer outcomes with a reusable platform. Finally, we decide whether that combination is actually necessary for a company.
In the automatic transcript, FDE sometimes sounds like FTE. The spellings of Rippling and Palantir also vary. This lesson uses FDE, Rippling, and Palantir in line with the talk's title and context. Different renderings do not necessarily refer to different roles or companies.
The main point of this chapter is not to memorize FDE as a fashionable job title. Understand it as a model in which a customer-facing software engineer uses a technical foundation to achieve a customer's outcome. The next chapter looks closely at Foundry, which supports this model, and at the path from data to an operational business outcome.