A logistics company hires an engineer to automate its weekly reporting. The statement of work is confident: crawl the four databases, generate the twelve reports, email them on Friday. A sensible plan. Any competent team could build it.
The engineer, forward-deployed in the Palantir tradition of sitting inside the operation rather than receiving tickets from it, spends the first two weeks not building. She walks one report end to end, the way water finds a path. Somewhere in the middle of that walk, three facts surface. The numbers the reports labor to compute are already being computed, continuously, in an event stream nobody reads. The scheduler everyone curses as rigid is configurable, and has been for years. And the person who receives the flagship report pastes it into a spreadsheet every Monday anyway, because what she actually needs is one column of it.
The plan is retired. What replaces it is half the size: subscribe to the stream, expose the one column, let the scheduler that already exists trigger it. The reports get better, not worse, because they now derive from truth instead of reconstructing it. Nobody briefed creativity. Nobody ran an ideation workshop. The new design fell out of comprehension, the way a key falls out of a lock when it finally turns.
The potential was never in the tools
Organizations talk about potential as if it were a fixed quantity sitting inside the system, waiting for tools. What a system can actually do is a function of what its parts actually are, and the honest version of that sentence is harsher: the potential of a system is a function of the operator's model of its components.
That deserves a name. Component fluency is knowing what the parts of a system really do, as opposed to what their documentation promises and what the folklore remembers. The gap between the documented system and the built system is where the possibilities live. The event stream nobody reads, the configurable scheduler everyone endures, the consumer who wanted one column: each was invisible on the feature list and obvious under the fingers.
This is why the arriving plan is so reliably wrong, and why its wrongness is not an insult to whoever wrote it. The statement of work was written against the documented system. The buildable opportunities live in the actual one. The outsider's plan is not badly reasoned. It is reasoned about a system that does not exist.
And it is why the first deliverable of deployed engineering is not code. It is comprehension. Not a kickoff, not a discovery phase in the ceremonial sense, but the specific act of meeting the components until the plan written afterward is a different artifact from the plan written before. In the forward deployed engineer role, this appears as one dry bullet, map systems and exceptions. This piece is the argument underneath that bullet: the map is not preparation for the value. The map is where the value comes from.
Why does knowing the components change the approach?
Because creativity in engineering is recombination, and recombination is bounded by the primitives you actually hold.
An idea that requires a scheduler that can trigger on event arrival does not exist for a team that believes the scheduler only runs at midnight. Not because the team lacks imagination, but because the idea has no material to form from. Possibilities are not added by effort or brainstorming. They are revealed by knowing what the pieces are, the same way new moves on a chessboard are revealed by knowing what the pieces can do. Understanding does not expand the option set. It reveals an option set that was there the whole time, masked by the documented version of the system.
This gives a clean test for the two kinds of creativity on display in any organization. The outsider's kind is template-shaped: patterns imported from other contexts, best practices carried in from previous jobs, plausible and unmoored. The insider's kind is combinatorial: arrangements of parts whose real affordances are known. The first kind sounds impressive in workshops and dies in integration. The second kind is quiet, looks obvious in retrospect, and is the only kind that ships into the system it was designed for.
Some people reach component fluency through how they already think. Node Graphs Are How Visual People Already Program describes minds that hold systems as connected parts natively; for them, meeting a component is one glance. For everyone else, fluency is built the manual way, by tracing real work through real machinery. Either way, the endpoint is the same: a mental model of the system as it was built, not as it was described. Building Technology the New Way Requires Exploring Code, Systems, and Configuration makes the adjacent claim, that modern building is mostly exploration and arrangement. This is the creativity clause of that argument: the exploration is not a cost before the design. It is the design's source material.
The moment the approach changes
The signature event of this whole pattern is worth isolating, because it is measurable and because teams that never experience it are teams that never learn their system.
The moment is the plan retirement. Somewhere in the walk-through, the plan you arrived with stops being the best available approach, and the moment you notice that, the learning has paid for itself. Not the moment you finish the map. Not the moment the workshop ends. The moment the original goal statement looks like it was written by someone who had not yet met the system, which is exactly what it was.
The practical instrument is the two-plan exercise, and its simplicity is the point:
- Before touching anything, write the plan and the goal statement. Date it.
- Walk one real unit of the work end to end, through every component it touches.
- Write the plan and the goal statement again. Date it.
- The delta between the two documents is the potential, made visible. If there is no delta, either the system is fully understood already or the walk was not honest.
Teams treat the second plan as an admission that the first was wasted work. It is the opposite. The first plan is the instrument that measures what the learning bought. And the delta is usually not incremental. It is structural: different components, different flow, sometimes a different goal, as when the real deliverable turned out to be one column rather than twelve reports.
There is an uncomfortable corollary for the agent era, and it deserves plain words. Generation is now cheap, which means any plan can be implemented almost instantly, which means the wrong plan has never been cheaper to execute. The bottleneck has moved again, from can we build it to do we know what the pieces are. An agent will happily crawl four databases and email twelve reports, fluently, on schedule, forever. The scarcity migrated upstream to the comprehension that retires that plan. It is the same migration What the Spec Doesn't Decide, the Model Will describes at the spec level, and it lands here at the component level: what you have not met, you cannot design with, and now something will build your uninformed design anyway.
What this is not
Not an argument for studying forever. Component fluency has a time-boxed shape: trace one real unit of work through the machinery, read the code that runs nightly, sit with the person who receives the output. Weeks, not quarters. The paralysis version of learning, where understanding becomes a permanent precondition that never completes, is this argument's parasite, and the two-plan exercise is its cure: learning ends when the second plan is written.
Not a claim that only forward-deployed engineers do this. The FDE just does it on a clock, in someone else's system, with the retirement of the plan as the expected outcome. Any engineer can meet their own system the same way, and most never do, because the system they believe in has never collided with the system they run.
And not a case against planning. The plan you arrive with is load-bearing: it is the baseline that makes the delta visible, and it gives the walk a direction. The claim is about sequence and honesty. Plan, walk, re-plan. Build only the second one.
The move
- Pick the next initiative. Write its goal statement and plan today, before anyone explores anything.
- Walk one unit of the real work end to end: one report, one order, one invoice, through every component, including the humans and their shadow spreadsheets.
- Write the component inventory: what each part actually does, connects to, and is truly capable of, versus what its documentation says. Never Hand-Maintain What the System Can Derive is the maintenance discipline for this inventory once it exists.
- Rewrite the goal statement from comprehension. Compare. The gap is the potential, and it is now a document instead of a feeling.
- If agents will implement it, hand them the second plan. Fluency plus generation is the real advantage. Generation without fluency is just a faster way to build the wrong thing.
Take-home
- Before the next plan gets built, walk one real unit of the work through the actual machinery. The plan that survives the walk is the first one worth building.
- Keep the pre-walk plan. The distance between it and the post-walk plan is the measure of what understanding changed.
- Treat comprehension as the first deliverable, not the overhead. In deployed engineering, the learning is the work that changes the work.
Related reading:
- The Forward Deployed Engineer: Mastering AI Deployment in the Real World
- The FDE Sits Where the Org Chart Has a Hole
- Building Technology the New Way Requires Exploring Code, Systems, and Configuration
- Node Graphs Are How Visual People Already Program
- What the Spec Doesn't Decide, the Model Will
- They Told You to Code. You Need Taste in Code.
- Curiosity as a Competitive Advantage for Product Builders
If your plans keep arriving sensible and leaving wrong, the gap is not planning skill. It is the distance between the documented system and the built one. If you want help installing the walk-through and the two-plan discipline before your next build, book a discovery call.
FAQ
What is component fluency?
Component fluency is knowing what the parts of a system actually do, as opposed to what their documentation promises and what organizational folklore remembers. The gap between the documented system and the built system is where the real possibilities live: unread event streams, configurable schedulers, consumers who need one column instead of twelve reports.
Why does understanding the system change the approach?
Because creativity in engineering is recombination, and recombination is bounded by the primitives you hold. An idea that requires a scheduler that triggers on event arrival cannot form in a team that believes it only runs at midnight. Understanding does not expand the option set; it reveals one that was masked by the documented version of the system.
What is the two-plan exercise?
Write the goal statement and plan before exploring, then walk one real unit of work end to end through every component, then write both documents again. The delta between the two versions is the potential made visible. No delta means either the system was already understood or the walk was not honest.
How does this apply when AI agents do the building?
Generation being cheap means any plan can be implemented almost instantly, including the wrong one, which makes comprehension the scarce input. An agent will fluently crawl four databases and email twelve reports forever. The value moved upstream to the understanding that retires that plan, so hand the agent the post-walk version, never the arriving one.
Isn't this just an argument for endless analysis?
No. The walk has a time-boxed shape: trace one unit of real work, read the nightly code, sit with the output's consumer. Weeks, not quarters. Learning ends when the second plan is written, and the pre-walk plan is not wasted; it is the baseline that measures what the comprehension bought.