How forward deployed engineers work

The engagement lifecycle

Every engagement moves through four phases:

Intake. A colleague or customer raises a need with the information outlined in how to get an FDE involved. That's enough for us to scope it.
Scope. We then classify the engagement type, estimate effort, and quote if the shape calls for it. The output is a short brief the customer can confirm before we commit. Details below.
Execute. We do the hands-on work: instrumentation, data modeling, migrations, integrations, dashboards, and reference implementations. We capture the durable artifacts as we go.
Wrap-up. We confirm the deliverable was shipped and approved, then hand the relationship back to sales and CS. We write down anything worth keeping for the next customer, along with any learnings to take back to product.

Scoping engagements

Before delivery starts, every engagement needs a measurable outcome, a rough timeline, and a shared definition of "done." We write this down as a short brief and send it to the customer to confirm before committing. Scope small: it's cheaper to expand a tight scope than to unwind a loose one.

While scoping, we always ask: Is the described problem indicating a deeper pattern? Understanding the real problem space and our ability to identify structure problems that may cause long-term problems matters more than anything else in making an engagement succeed.

What it costs

Pricing depends on shape, effort, and commercial context, so exact numbers live in the FDE calculator and the commercial reference, not here. The philosophy:

Discovery and scoping time before an engagement is free and time-boxed.
Pricing is quoted per milestone deliverable, not per hour. A deliverable that doubles in scope is a new quote, not an informal extension.

Never invent an exact number on the spot. If a customer asks, say you'll get them a quote within a day and route it through the account owner.

Customers can also apply their prepaid credits toward an FDE engagement on a discretionary basis, provided there is justifiable account-level upside. This needs approval from Simon (Ben B as backup).

Principles

These are the defaults we bring to every engagement to deliver delightful customer outcomes.

The unit of value is a measurable customer outcome. Not a doc, a recommendation, or a merged PR. We measure an engagement by what changed for the customer, and we agree on how we'll measure that before we start.
Solve the customer's actual problem, not the one that's easiest to ticket. The strongest move is often to correct a customer's mental model rather than build exactly what they asked for. Before digging in, ask what decision actually depends on the answer, and what "good enough" looks like for it.
Start with the MVP. Say what the minimum answer is before you start. A short list today usually beats a long analysis next week. Building more than the question asked for isn't thoroughness; it's waste. Push back on every "should we also...".
Reach for PostHog's own primitives first. Prefer PostHog AI and the platform's built-in capabilities over bespoke engineering. The simplest path the product already supports is usually right, and it's the one the customer can maintain after we leave.
Capture what's reusable. Where something we build for one customer would help others, turn it into an example, template, or product improvement. Make your work visible so we can retrospectively find improvements based on the visible work and its results.
Lead with substance. In customer communication, lead with what you found and what you'd do, never with the fact that an artifact exists. "The writeup is ready" reads as corporate filler. Say what's in it.
Stay close to product engineering. We're the fastest feedback loop between real customer usage and the roadmap, so use it.

Judgment over volume

As AI handles more of the production, an FDE's value is less in how much they can produce and more in the judgment they bring to it. When generation is cheap, the scarce skills are the ones a model can't supply for you:

Prioritizing well. Knowing which of ten reasonable things to do first, and which not to do at all.
Deriving the true problem. Reading ambiguous or over-specified requirements and finding the real question underneath.
Choosing the simplest thing that works. The simple approach where it serves, the robust one only where it prevents real regressions.
Make the work compound. Decide what to do now, defer, or delegate, but structure the work so that what you do now also reduces uncertainty, produces evidence, or advances a larger engagement milestone.

We hire and grow for this, and we give people room to exercise it rather than a script to follow.

Improvement loop

Doing the work and improving how we work are the same activity. Every engagement teaches us something: a recurring question, a pattern that held, a place the process drifted. We capture those, gate the ones that hold, and graduate them to the right level of generality: a customer question becomes a topical reference, a cross-customer pattern becomes a lesson or a playbook entry, a hard-won rule becomes a standard.

The result is a team knowledge base that gains weight over time, so the floor is higher on every new engagement.

Compounding work

We earn the right to compound by getting it right for one customer first.

That means we focus hard on a single customer's problem and deliver real, measurable value for them as quickly as possible. Only once it has worked in the real world do we think about scaling it out to N customers. We don't try to make a solution general or scalable across the customer base until later, because generalizing too early usually means solving nobody's problem well.

In practice:

Deliver value now. Keep asking what needs to happen next to move the customer's goal forward.
Make the work visible. Record what you do, learn, fix, and uncover so others can find and use it.
Learn by doing the work. Use real customer work to expose the actual problems instead of trying to model them all upfront.
Solve for this customer first. Generalize when the work gives us evidence that something should scale.
Bring back what we learn. The solution can stay customer-specific; the useful findings should not.

Sprints

The FDE team works in fortnightly Sprints that run from Monday to the Friday of the following week. Stand-ups are on Mondays and Wednesdays at 2.30pm UK / 9.30am ET.

On the closing Friday of a Sprint, a GitHub Action automatically closes the current Sprint's issue and creates a new issue for the next Sprint. FDE team members are expected to populate it before Sprint kick-off, which takes place at the Monday stand-up.

Working as a team

We're still new as a team and figuring things out as we go. To ensure everybody is pulling in the right direction and not duplicating work, we:

Make work visible once it may affect the team, customers, or shared systems. We follow the PostHog convention of preferring pull requests over issues and Slack discussions. Save RFCs for when you want to invite discussion, and keep them rare.
Build on existing work. Before starting a new solution, check for relevant work already in progress and either reuse it, improve it, or explicitly explain why a separate approach is needed.
Use peer feedback to shape the approach. Raise alternatives early so we can consider and agree on the best path forward.
Create maintainable team assets. Avoid building tools or workflows that only one person can operate.
Track customer outcomes, not just work outputs.

In general, at PostHog we bias for sharing imperfect work early, so that peers can help shape the direction of that work, rather than waiting for something to be perfectly ready before making it visible to the team.