The Forward Deployed Engineer, Chapter 9: The Outer Loop — Scaling Field Intelligence

This is Part 9 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we ran the inner loop. This one begins the moment production goes live — the outer loop, where the engagement turns into field intelligence and the function’s real economics emerge.

The outer loop begins on the first production day, and the work shifts in a way that catches a lot of FDE teams off guard. The inner loop was about getting the deployment to ship. The outer loop is about something different: making sure each successful customer engagement produces platform learnings for the next customer, for the product roadmap, and for the operating model itself. This is the loop that decides whether the FDE function is a leverage point on the platform or a high-end consultancy in software clothing. Most of the difference between great FDE functions and merely-good ones is what they do in the outer loop, not what they do in the inner one.

The dominant metaphor in mature FDE practice is gravel roads and paved superhighways. The gravel road is what gets a single customer moving — bespoke, hand-built, customer-specific, and necessary because there was no superhighway yet. The paved superhighway is what the platform offers to every customer once a pattern has generalized. The work of the outer loop is the deliberate, rolling conversion of one into the other — deciding which gravel roads deserve paving and which should stay as they are because they serve only one customer’s idiosyncrasy. There are two ways to fail at this conversion. Paving too early produces brittle abstractions that no second customer actually needs. Paving too late produces a portfolio of one-off deployments that no second customer can benefit from. Mature functions live in the middle.

The Productization Decision and the Feedback Loop

The productization decision — which gravel roads to pave — is made on a rolling basis, typically every quarter, sometimes more often in fast-moving labs. The criteria are precise: which customer-specific work has natural pull from at least one other customer in the pipeline; which is irreducibly bespoke and should remain so; and which sits in the middle as a templated pattern that future engagements can configure rather than rebuild. Getting these wrong is the most common way a platform company quietly becomes a services company without anyone making the explicit decision to do so. The signal that the wrong call is being made repeatedly is a platform repo whose customer-specific code is growing faster than its general code, which is one of the metrics I track most carefully in advisory engagements.

Less visible than the productization decision — and arguably more important — is the feedback path from the field back to platform engineering. Field engagement produces enormous amounts of information about what customers actually need, what they say they need but don’t actually use, and what they don’t yet know to ask for. Capturing this information operationally requires the discipline I call the platform commit: the structured handoff of a field learning into a roadmap item with a real owner and a real review cadence. Without the platform commit, learnings die in deployment-review meetings and nothing compounds. With it, the platform improves on every customer engagement, and the leverage the FDE function is supposed to produce actually arrives.

Measuring the Leverage

The economic case for the FDE function rests on the outer loop producing measurable leverage. The chapter walks the small set of metrics that matter: time-to-second-customer per pattern (how long until a paved superhighway carries its second user); platform commit rate (the share of field learnings that become roadmap items within a quarter); and the unit economics of the second deployment of any given pattern, which should be a fraction of the first. The two-team handshake between FDE and platform engineering is the operational ritual that mature functions build to keep these metrics honest — usually a weekly meeting with a defined agenda, sometimes a daily standup, always with shared accountability for the platform commit pipeline. The handshake is where the flywheel either spins or stalls. The chapter closes on the characteristic ways the outer loop fails — over-paving, under-paving, captured FDE teams, and the platform team that won’t accept commits because they didn’t originate inside it — and the operational moves that prevent each. Tomorrow: governance, which decides whether any of this can run in regulated environments at all.