A Year in the Life of a Forward Deployed Engineer
Onboarding for a Forward Deployed Engineer combines meetings with senior engineers, reading the team's playbook documents, and observing live customer calls.
A Newcomer's First Two Weeks
A new Forward Deployed Engineer joins a team that already has its own way of working, its own documents, and its own customers. Onboarding is the process that brings a newcomer up to speed on all three. Rather than dropping someone straight into customer work, the process places the new engineer alongside experienced colleagues, gives them written material to study, and lets them watch real customer interactions before they are expected to contribute.
This article follows one engineer through her first weeks of onboarding in January, covering weeks one and two. Her experience is the source example we will trace. As you read, keep one question in mind, the one the source itself raises: after a period of onboarding, what has a new engineer really learned, and how can you tell the difference between knowing how something works and knowing why it exists?
Three Strands of Early Activity
The engineer's early activity had three strands. Each one exposed her to the team in a different way. Before looking at them one by one, notice how they fit together: each strand supplies a different kind of input, and the onboarding process needs all three.
The diagram shows the order in which the source lists the strands, and it shows the three of them as parts of one onboarding process rather than as separate tasks. The subsections below take each strand in turn.
Reading the Week-Two Note
At the end of week two, the engineer wrote a note to herself. Its substance was that she could not yet say what the customer engagements were about, but she could describe how they were carried out. Read that sentence slowly, because it makes two different claims at once.
Testing the Week-Two Claim
The engineer's note says she can describe how engagements are carried out but cannot yet say what they are about. Is that claim precise, and what kind of understanding does each half describe?
- 1Identify the first half
Being able to describe how engagements are carried out means she can account for the shape of the work: the steps, the meetings, and the sequence in which things happen. That is knowledge of process.
- 2Identify the second half
Not being able to say what engagements are about means she has not yet grasped their purpose, which is the reason they exist and the outcome they serve for the customer. That is knowledge of purpose, and she does not have it yet.
- 3Check whether the claim is precise
The source describes the claim as precise. It separates two things that are easy to blur together. A vague note would say she understood the engagements or did not. This note says exactly which half she has and which half she is missing.
The note reports process understanding and an explicit gap in purpose understanding. The claim is precise because it names which kind of understanding is present and which is absent.
Shape Versus Purpose
Understanding the shape of an engagement means knowing how it is run: its steps, its meetings, and its handoffs. Understanding its purpose means knowing why it exists, the outcome it is meant to serve. The source treats these as distinct, and the engineer's note depends on that distinction.
The left column shows what knowing the shape of an engagement gives you: you can answer questions about how the work proceeds. The right column shows what knowing its purpose gives you: you can answer questions about why the work is done and what it achieves for the customer. A newcomer can have the first without the second, and the week-two note is an example of exactly that.
Why Shape Arrives Before Purpose
The source notes that the two kinds of understanding can develop at different speeds. Sitting in on calls and reading process documents can teach you the shape quickly, because both expose you to how things are done. Watching a call shows you the sequence of events. Reading a playbook shows you the procedure. Both are direct views of the process.
Purpose is harder to read off the surface. It depends on the customer's situation, and a single call or a single document rarely reveals that situation fully. You can watch a call without ever seeing the full context that made the customer ask for it. This is why early progress often reaches shape before purpose.
Judging a Note Line by Line
Suppose a different new engineer writes three statements at the end of their third week. Each statement is generated for this example. Your task is to decide, for each one, whether it shows process knowledge (shape) or purpose knowledge.
- Statement A: Each engagement starts with a discovery meeting, then moves to a handoff between two teams.
- Statement B: The customer's reason for each engagement is a deployment problem that a standard product does not fully solve.
- Statement C: The senior engineer ends the walkthrough by reviewing the customer's notes before the next call.
Classifying the Three Statements
Which of statements A, B, and C show process knowledge, and which show purpose knowledge?
- 1Test statement A
Discovery meetings and handoffs are steps and transitions in how the work runs. Statement A describes shape, so it is process knowledge.
- 2Test statement B
Statement B names the reason the customer engages, which is the outcome the work serves. It describes the customer situation behind the work, so it is purpose knowledge.
- 3Test statement C
Reviewing notes before the next call describes a step in the sequence of activity. It is process knowledge, even though it sits in a sentence about a walkthrough.
Statements A and C show process knowledge. Statement B shows purpose knowledge. The note as a whole contains more shape than purpose, which fits the pattern described earlier.
Sorting Statements from a New Note
A new engineer writes this statement after two weeks: Each call begins with a short account review, and the team's playbook says to document the outcome in the shared tracker. Do you think this statement shows process knowledge, purpose knowledge, or both? Explain your reasoning by pointing to the specific words that support your choice.
Hints
- Ask whether the statement describes steps in the work or the reason the work exists.
- The phrase about documenting the outcome is about recording, so consider whether it describes a step or the purpose the step serves.
- A statement can contain more than one kind of knowledge. Decide which part belongs to which kind.
Write one honest sentence describing what you currently understand about a process you are learning, and one sentence naming what you still do not understand about why it exists. Keep the two sentences separate so that each kind of understanding is named precisely.
Hints
- Describe the steps or meetings first, then name the reason behind them as a separate gap.
- The source's note works because it names the missing half clearly rather than saying the whole topic is unclear.
Mistakes When Judging Onboarding Progress
Common mistake Treating knowing the process as knowing the purpose
What it looks likeA new engineer describes every step of a call accurately and assumes they understand the engagement.
Why it failsKnowing how an engagement is run tells you its shape. It does not tell you why the customer needs it, which is the purpose.
Do this insteadAsk separately whether you can explain the steps and whether you can explain the reason for them.
Common mistake Assuming vague self-assessment is good enough
What it looks likeA note that says I understand the engagements well, without saying which part.
Why it failsA general claim hides which kind of understanding is present and which is missing, so it gives no direction for the next stage.
Do this insteadName the kind of understanding you have, as the week-two note does, so the next step of learning can target the gap.
Common mistake Expecting purpose to appear from watching calls alone
What it looks likeA newcomer sits through several silent call observations and expects the reason for the work to become clear automatically.
Why it failsThe source notes that purpose depends on the customer's situation, which a single call rarely reveals fully. Observation mainly exposes shape.
Do this insteadUse the walkthroughs and written material to ask about the customer situation directly, rather than waiting for it to surface.
Common mistake Reading a playbook without annotating it, which makes it hard to tell later which parts were understood.
Summary of the Onboarding Picture
Onboarding brings a new Forward Deployed Engineer up to speed through three strands: walkthroughs with senior engineers, reading the playbook documents, and observing live customer calls. Each one exposes the newcomer to how the team works. The early progress these strands produce tends to be understanding of shape, the way engagements are run, more than understanding of purpose, the reason they exist.
At a glance
- Onboarding for a Forward Deployed Engineer combines meetings with senior engineers, reading the team's playbook documents, and observing live customer calls.
- Understanding how an engagement is run (its shape) is distinct from understanding what it is for (its purpose).
- Early onboarding progress usually reaches shape before purpose, because purpose depends on the customer's situation, which a single call or document rarely reveals fully.
- A precise self-assessment names which kind of understanding you have and which you are missing, which directs the next stage of learning.