Hello, this is Ryuta Hamamoto from TIMEWELL.
This is the seventh article in our FDE practice series. The first six covered the skills of asking, watching, being there, turning fragments into structure, filming and counting, and handing the dictionary to a machine. This time I want to show how those are arranged inside a single week.
We say that working in the FDE style lets us implement faster than anyone. Honestly, that phrasing leaves room for misunderstanding. It does not mean our engineers' hands are fast. It means the loop of asking, building, reading the reaction, and returning the learning to the product fits inside one week. This article walks through that week from Monday to Friday, explains how it differs from the phases of contract development, and states plainly what does not reach production in a week. If you first want to check how far your own team can turn this loop, take the AI literacy check.
The premise: speed is not fast hands but a short loop
First, what the speed actually is.
The person who spent eight years as an FDE at Palantir writes that when a small team of engineers in their twenties showed up at a customer's site and built real software people could use within a week or two, the customer noticed, because the system integrators they were used to worked on year-long waterfall timescales.1 The FDE organization AWS launched in June 2026 sets out to compress deployment from months to days.2 The deployment company OpenAI launched in May describes its typical engagement as a diagnostic of where value lies, a small number of priority workflows chosen with leadership and operating teams, and design, build, and rollout inside the organization.3 What they share is the order: do not wait for requirements to settle; put something that runs in place early, and learn after it is in place.
Our speed has one more reason: we are a small company. In a large FDE organization, the person who asks on site, the person who builds, and the person who returns learning to the product are different people. At ours they are the same person. The exception found on site on Friday is built by that person the following Monday, and that Friday the same person decides whether it becomes a standard product feature. What would be relayed in meetings between different people is resolved inside one head.
And then there are coding agents. Until recently, only a skilled engineer could ship code on day one. Now, given the nouns and verbs, a provisional screen appears in a few hours. There is a trap here, though. As I wrote in the article on abstraction and concretization, there is research showing that when coding speed rises, value rises by less. Writing fast and writing the right thing are different. The FDE week is designed to shorten the loop so that the right thing gets found, not to write faster.
Monday: ask the three layers, find the data owner, put down the first version in the evening
Monday morning is for asking. Executives, division heads, and the shop floor, each separately, because in one room only the executive's voice survives. Ask executives what they want to change in the industry, division heads this year's numbers, and the shop floor which screen they opened yesterday afternoon. The week's goal is to find the single point that satisfies all three. What OpenAI calls the small number of priority workflows, we call that point.
Before the morning ends, settle one more thing: who owns the data. "Which system does that number come from?" "Who administers it?" As the former Palantir FDE wrote, eight-to-twelve-week pilots can be consumed entirely by negotiating data access.1 We settle the anonymization procedure at the first meeting, run the security review in parallel, and work on anonymized data while it is pending. If the owner is identified Monday morning, anonymized real data is in hand by the afternoon.
The afternoon is for watching. Sit diagonally behind the person and shadow the day's flow. Do not interrupt. Record the walking and the waiting. This is where the five-column record begins.
In the evening, put down the first version. On top of our product's standard components, place the nouns and verbs heard in the morning, mirror the screen flow seen in the afternoon, and run it on the anonymized real data. A coding agent writes it, a person reads it, and it goes in front of the person on site. The details of how it is built are in the live mock article. After putting it down, ask one thing: "What is different?" The differences that come out are Tuesday's build.
The first version contains no writes. Read-only and suggestions. Anything that writes back to production systems does not go in until four things are settled: permissions, prior simulation, human involvement on significant decisions, and an auditable record. That condition comes before speed.
Looking for AI training and consulting?
Learn about WARP training programs and consulting services in our materials.
Tuesday to Thursday: collect exceptions by observation, one version a day
Tuesday to Thursday are for building while watching. Mornings are contextual inquiry: sit at the workstation, watch the work, and ask "why did you just do that?" The exception notebook fills up. "When it's urgent the assistant manager stamps it." "This form is only used at month-end." "This check stops when the section manager is off." Afternoons put the morning's exceptions into the version.
Versions are built spec-driven. Write one line from the exception notebook as a short specification, have the coding agent implement it, read it, and put it in front of the person. The reason for writing the spec first is to be able to trace afterward what the agent was asked to build; the way we write them is in the article on spec-driven development. One version a day. Even when there is room for two, we make one, because one reaction a day is all the person can give.
Thursday afternoon, take a provisional measurement. Have the person do the same task with the working artifact and count the time and the screen switches. If filming consent is in place, count from video. A difference such as "approval waiting went from 47 minutes to 12" is material for Friday's decision. The provisional measurement is an outcome for the person and, at the same time, our basis for judging whether the pattern is worth returning to the product.
One thing our engineers are careful about during these three days: do not overbuild. With ten items in the exception notebook, you want to build all ten. But seven of the ten are branches unique to this company that happen once a month. What gets built by Thursday is only the exceptions that happen every day. The rest wait for Friday, when they are sorted into patterns and branches.
Friday: make groups, update the dictionary, return patterns to the product
Friday is for stepping away from the site and thinking. In the morning, the fragments from Monday to Thursday, transcripts, five-column records, the exception notebook, Thursday's counts, become cards in the KJ way, then groups, then names. The procedure is in the KJ method article.
In the afternoon, extract the five things from the group names and update the dictionary: nouns, verbs, relationships, states, exceptions. The definition of "approve" changes this week to "the assistant manager judges and the section manager stamps," and the version number goes up by one. As the ontology article explains, the dictionary is written on the premise that the agent reads it the following Monday.
Then sort the group names into patterns and branches. "Approval is two-stage" is a pattern seen at other companies; making the number of stages and the decision-makers configurable goes into the product backlog. "Tanaka in accounting holds that paper" is a branch: recorded, kept out of the product. We can answer one of the pressure tests a16z laid out in January 2026, whether you can say no to customization,4 because this Friday exists.
At the end of Friday, write two things. For the person on site, one paragraph: "Next week we'll build an on-screen approval route for urgent cases, because the current paper route assumes the assistant manager's judgment." For ourselves, the judgment: "the separate route for urgent cases is a pattern; who holds the paper is a branch." Writing those two ends the week.
Stacking weeks: in 45 to 90 days, we are no longer needed
Every week repeats this, but the content shifts as weeks stack. a16z's January 2026 essay describes the real FDE model as time-boxed deployment and gives 90-day sprints to production as an example.4 AWS puts the customer's ability to run things themselves at the end of the engagement, meaning working systems plus documentation plus trained in-house staff, at the center of its design.2 We too set the period on site at the start: roughly 45 to 90 days.
Weeks one and two are the loop above, with read-only access and suggestions in place. Weeks three and four introduce writes gradually: settle the four conditions, write back a single process first, and watch it in production for a week. Around week four, the person on site starts editing the dictionary. "The approver for the urgent category changed" is fixed by them, not by us. In weeks six to eight, we create days when our engineer is not on site. If the loop turns on those days, we are ready to leave.
Three conditions for leaving. The person can update the dictionary themselves. The effect of the working artifact is visible to the person in the metrics of their own work. And the patterns have returned to the product so that the next customer does not require the same learning. The person who led Palantir's commercial business called the FDE a CEO with zero authority and demanded accountability for outcomes.5 For us, the outcome is that we are no longer needed.
How it differs from contract-development phases
Here is the week's structure set against contract-development phases.
| Aspect | Contract development | An FDE's week |
|---|---|---|
| Order of phases | Requirements, design, implementation, testing, acceptance, in series | Ask, build, read the reaction, return, in parallel every week |
| Day-one deliverable | Meeting minutes and a draft of requirements | A first version running on anonymized real data |
| Handling changes | A change in requirements means extra cost and a new quote | Changes go into Tuesday's version; Friday sorts them into pattern or branch |
| How outcomes are measured | Acceptance (does it work as specified?) | Metrics of the work (did 47 minutes become 12?) |
| Where learning goes | The customer's asset | Patterns to the product, branches to the customer's extensions |
| How it ends | Acceptance and withdrawal | The person edits the dictionary and we are no longer needed |
The biggest difference is that phases are not run in series. Contract development writes no code until requirements are fixed, then designs, implements, tests, and accepts. If the requirements are right, that order wastes nothing. FDEs abandon the series because requirements are never right at the start. The person cannot write the assistant-manager exception into a blank specification. They can only say it once they see something running. So asking and building sit in the same week and reading the reaction happens every day.
The other difference is how outcomes are measured. Contract development measures by acceptance: if it works as specified, it is done. FDEs measure by the metrics of the work: even if it works as specified, if the person's approval wait has not shrunk, it is not done. That is why Thursday has a provisional measurement and the next week films again. This difference changes what "fast" means. Contract speed is days to acceptance; FDE speed is days until the person's day changes.
What we do and where it stops: what does not reach production in a week
Let me be honest. Some things do not reach production in a week.
Write integrations with core systems do not. Because we settle permissions, prior simulation, human involvement, and an auditable record and then introduce writes one process at a time, they land in the third week or later. Connections that require security review depend on the review's duration. We run the review in parallel and work on anonymized data while it is pending, but we cannot make the review itself faster. Processes that appear only at month-end or in the busy season cannot be seen until that time comes, so we ask about them as events, build provisionally, and fix when the time arrives.
The conditions for speed, too. The person's time and access to data. On a site where the person keeps saying "later, I'm busy," the loop does not turn. On a site where the data owner cannot be identified on Monday, there is nothing to build on Tuesday. We agree on these two as conditions of the engagement at the first meeting. Where they cannot be agreed, we do not promise the week-long loop.
Finally, the danger of the phrase "code on day one." What appears on day one is an incomplete first version, a questioning device for drawing out the answer to "what is different?" If it is received as a finished product, disappointment arrives on day two. So when we put down the first version we always say, "this is here so you can tell us what's wrong with it." The value of the speed is not day-one polish but how fast the artifact approaches the right thing by Friday.
Summary
The basis for saying we implement fastest is that the loop of asking, building, reading the reaction, and returning the learning to the product fits in one week. Monday: ask the three layers, find the data owner, put down a first version on anonymized real data in the evening. Tuesday to Thursday: collect exceptions by contextual inquiry, build one spec-driven version a day, take a provisional measurement on Thursday. Friday: make groups with the KJ method, update the dictionary, return patterns to the product, record branches.
Stacking weeks over 45 to 90 days, the person on site comes to update the dictionary themselves and we are no longer needed. The difference from contract development is that phases are not run in series, outcomes are measured by the metrics of the work rather than by acceptance, and learning returns to the product. Some things do not reach production in a week, and the conditions for speed are the person's time and access to data.
If you want to turn this loop with your own engineering team, or are looking for a partner to bring it into your own workplace, take a look at the WARP program or talk to us. The next article reads why the FDE role expanded so sharply from 2025 to 2026, in the numbers of job postings, investment, and acquisitions.
Footnotes
-
Reflections on Palantir (Nabeel S. Qureshi, October 15, 2024). The account of shipping something usable within a week or two, the contrast with incumbent integrators, and the anecdote of pilots consumed by data-access negotiation are from this essay ↩ ↩2
-
AWS invests $1 billion to embed AI forward deployed engineers with customers (Amazon, June 30, 2026). Compression from months to days and customer self-sufficiency at the end are from this announcement ↩ ↩2
-
OpenAI launches the OpenAI Deployment Company (OpenAI, May 11, 2026). The typical engagement structure is from this announcement ↩
-
The Palantirization of everything (Marc Andrusko, a16z, January 16, 2026). Time-boxed deployment, 90-day sprints, and the pressure tests are from this essay ↩ ↩2
