The Production Phase of an FDE Engagement
The FDE is the institutional memory of the engagement, responsible for continuity across change.
A Two-Year-Old Engagement
Imagine an engagement that has been running for two years. The people on the customer side who first asked for the system have moved to other projects, and the vendor has since swapped the underlying model for a newer one. A new FDE is brought in to keep the system running. What does that person have to work with? This article follows the answer the source gives to that question, and what it asks the current FDE to do now, while the engagement is still active.
Keep this scenario in mind. Each time a new idea appears below, ask yourself whether it helps the new FDE who arrives after the original team and the original model are gone.
Tracking Two Forces Over Time
Walk through the scenario in order and track two things at each step: who or what changed, and what the engagement still depends on. The source names two forces that act on an engagement over time. The first is on the customer side, where the team that works with the system rotates. The second is on the vendor side, where the model the system is built on gets replaced.
Neither change is an exception or a failure. Both are treated as expected conditions of the production phase, so an engagement has to be built to survive them rather than to avoid them.
Where the Wrapper Sits
The diagram below shows the arrangement the source describes. The two changing forces sit on the outside and point at the wrapper, not at the knowledge inside anyone's head. The original FDE builds the wrapper, the customer team and the vendor model both change around it, and the replacement FDE receives the wrapper. The point of the picture is where the arrows end: the wrapper is the place where the engagement's continuity is held.
The FDE as Institutional Memory
The FDE is the institutional memory of the engagement, responsible for continuity across change.
Notice what that claim does and does not say. It does not say the FDE personally remembers every detail, and it does not say the customer's staff or the vendor's model keeps the knowledge. It places the continuity role with the FDE, and then it names the artifact through which that role is carried out. That artifact is the wrapper. The source says a well-designed and well-documented wrapper is what survives both the team rotation and the model replacement.
Two Kinds of Change to Survive
An engagement has to survive two different kinds of change. They come from different sides of the engagement and threaten different things. The table below compares them.
| Kind of change | Where it originates | What it affects | What it threatens |
|---|---|---|---|
| Customer team rotation | Customer side, where the team that works with the system changes | The people who understand the system and first asked for it | Knowledge of why the system was built the way it was |
| Vendor model replacement | Vendor side, where the model the system is built on is replaced | The underlying model the system depends on | Any part of the system that is tied directly to the old model |
The two changes the production phase must survive
Both changes are expected. The source treats each as a normal condition of the production phase, which means a plan that assumes the team and the model will stay the same is already fragile.
Replacing the Model Behind the Wrapper
Consider what a model replacement looks like when a wrapper is in place. The diagram below shows the state before and after. The customer system and the wrapper are the parts that the source expects to survive the change, while the vendor model is the part that is swapped.
Read the diagram by its two halves. The model is the piece that changes between the halves. The wrapper and the customer system are drawn the same way on both sides, which is the intent of a wrapper: the parts the customer depends on stay fixed while the vendor's component behind them is replaced. The source's claim is that the wrapper is the artifact that survives this change, so the continuity of the engagement rests on the wrapper rather than on the old model.
Writing for the Successor
The source gives one concrete instruction for the production phase: write the wrapper as if you are writing for the FDE who will replace you. The source adds that this successor is already on the way, which means the planning cannot be postponed until later.
The instruction changes the audience you imagine while you work. Instead of writing for the person who understands the engagement today, you write for a capable newcomer who has none of your context. That newcomer does not know which customer staff member asked for what, and does not know which model version the system was first built against.
Mistakes That Undermine Continuity
Common mistake Treating the FDE as the only place knowledge lives
What it looks likeKeeping the reasons for design choices only in the original FDE's memory
Why it failsThe source places continuity in the wrapper, which is the artifact that survives both the team rotation and the model replacement. Knowledge that exists only in a person's head does not survive a handover.
Do this insteadRecord the reasons for the wrapper's design in the wrapper's documentation so a successor can find them
Common mistake Writing the wrapper for the current team
What it looks likeDocumentation that names people or assumes the customer contact will always be available
Why it failsThe customer team rotates, so the people named in the documentation will not stay. The source expects this change.
Do this insteadDescribe roles and responsibilities rather than individuals, and write for a newcomer
Common mistake Assuming the model will stay the same
What it looks likeA wrapper that exposes details of the current model directly to the rest of the customer system
Why it failsThe vendor's model will be replaced. A design that leaks model details spreads the replacement work across the whole system.
Do this insteadKeep the customer system's dependency on the vendor model behind the wrapper, as the diagram shows
Common mistake Postponing the documentation until the engagement is ending
Checking Your Understanding
A wrapper was built for a customer system two years ago. The team that asked for it has rotated, and the vendor has replaced the model. A new FDE asks what they have to work with. Using the source's account of institutional memory, explain where the continuity of the engagement is held, and name one thing in the wrapper's documentation that the new FDE would need.
Hints
- Think about where the source says continuity lives: with the FDE, carried through the wrapper.
- Consider what a newcomer would need that the original team could have told them in person.
- The source says the wrapper survives both changes, so ask which parts of the system the newcomer would need to understand first.
Carrying the Engagement Forward
- 1The FDE is the institutional memory of the engagement, responsible for continuity across change.
- 2An engagement must survive two expected changes: customer team rotation and vendor model replacement.
- 3A well-designed and well-documented wrapper is the artifact that survives both changes, and the continuity of the engagement is held there.
- 4Write the wrapper as if you are writing for the FDE who will replace you, because that successor is coming.
Key Takeaways
- The FDE is the institutional memory of the engagement, responsible for continuity across change.
- The two changes an engagement must survive are customer team rotation and vendor model replacement.
- A well-designed and well-documented wrapper is the artifact that survives both changes.
- Writing the wrapper for a future successor changes what you build and how you document it.