13.1 — The FDE Engagement Lifecycle

1. What is it?

This chapter maps the complete arc of a real FDE engagement — from the first customer conversation through production deployment and beyond — showing how every part of this handbook (discovery, architecture, building, securing, deploying, measuring) fits together as one continuous process, rather than a sequence of disconnected skills.

2. Why does it exist?

Every part of this handbook so far has taught one piece of the FDE skill set in relative isolation — Part 12's discovery, Part 11's architecture, Part 3-9's engineering, Part 14's deployment, Part 15's ROI measurement. This chapter exists because a real engagement is not a series of separate projects handed off between different specialists — it's one continuous relationship an individual FDE (or small team) typically owns end-to-end, and understanding the full lifecycle is what lets you make good decisions at each stage with the later stages already in mind (e.g., designing for Part 14's deployment realities from the very first architecture decision, not as an afterthought).

3. What problem does it solve?

It solves "what actually happens, in what order, across a real FDE engagement, and what should I be thinking about at each stage that isn't obvious from studying any single stage in isolation" — the connective tissue between every other part of this handbook.

4. How does it work internally? — The full lifecycle

1. First contact / Discoveryunderstand the actual problem, map the real business process, assess honest feasibility (Part 12)

2. Solution architecturedesign a technically sound architecture matching discovered requirements, communicate for buy-in (Part 11, 12.3)

3. Rapid prototypingvalidate the riskiest assumptions cheaply, before full production investment (Part 13.2)

4. Production engineeringthe real system: foundations, AI engineering, framework, hardening, reliability, security (Parts 1-9)

5. Deploymentget the system running in the customer's actual environment (Part 14)

6. Production monitoring & supportongoing observability, incident response, debugging (Part 8)

7. Iteration based on feedbackreal usage reveals gaps discovery didn't anticipate — feed back into requirements (Part 12)

8. Measuring business impactprove the system delivered the value discovery identified (Part 15)

Why this is a loop, not a line

Step 8 (measuring business impact) explicitly feeds back into future discovery — both for expanding the current engagement (a successful pilot often becomes the basis for a larger rollout, requiring fresh discovery for the expanded scope) and for informing how you approach the next customer's discovery conversation, now armed with real, evidenced patterns from this engagement. An FDE's judgment compounds across engagements precisely because each one, done well, feeds concrete lessons into the next — this is part of why the role rewards depth and pattern-recognition built up over multiple full-lifecycle engagements, not just isolated technical skill.

Where most engagements actually break down

In practice, the most common lifecycle failure points are: skipping or rushing step 1 (Part 12's entire argument), jumping from step 2 directly to step 4 without step 3's cheap validation (Part 13.2's entire argument, next chapter), and neglecting steps 6-8 once the "exciting" building work is done — treating deployment as the finish line rather than the midpoint of a lifecycle that isn't complete until business impact is actually measured and proven.

First-week technical onboarding — joining an unfamiliar customer environment

Part 12's discovery process covers business discovery — the problem, the process, the stakeholders' stated needs. Between step 1 and step 2 of this lifecycle, in essentially every real engagement, there's a distinct, less-discussed layer of work: getting technically oriented inside a customer's existing environment you don't yet understand, often in the engagement's literal first week, before architecture decisions can be made responsibly. Four concrete things happen here:

1. REQUESTING SYSTEM/DATA ACCESS
   - Identify exactly which systems you need read access to (source
     data systems, existing internal tools, sample production-like
     data) and request access through the customer's own provisioning
     process on day one, not once you're blocked waiting on it —
     enterprise access requests routinely take days to weeks to
     actually clear (background checks, VPN provisioning, account
     creation), so this is a lifecycle-timeline item (Part 13.1's
     "plan for negotiation time" discipline, applied here to access
     rather than network policy).
   - Ask explicitly what a REALISTIC sample of production-like data
     looks like and how to get it — a customer's first offer is often
     either too small or unrepresentatively clean (Part 13.2's "real,
     not synthetic" discipline starts with this first-week request).

2. MAPPING AN UNFAMILIAR EXISTING STACK
   - Don't assume the customer's stack matches what discovery
     conversations implied — verify directly: what's actually running
     where, which systems are the true source of record versus a
     downstream copy, which integrations are documented versus tribal
     knowledge only a specific engineer remembers.
   - A fast, cheap first-week technique: ask for (or build) a simple
     data-flow sketch with someone from the customer's technical team,
     verified against what you can directly observe (API responses,
     database schemas, logs) rather than relying solely on a verbal
     description that may be stale or incomplete.

3. IDENTIFYING REAL DECISION-MAKERS VS. STATED STAKEHOLDERS
   - The person introduced as "the project lead" is not always the
     person whose actual approval determines whether the project
     proceeds, gets budget, or survives a later objection — this is
     often a genuinely different person (a budget-holding VP who
     rarely attends working sessions, a security reviewer who can
     unilaterally block launch per Part 12's hard-objection bank).
   - A concrete first-week practice: ask directly, "besides the people
     in this room, who else needs to be comfortable with this before
     it can go live?" — surfacing this early prevents building toward
     an approval that was never actually going to be sufficient.

4. WORKING WITHIN THE CUSTOMER'S EXISTING (POSSIBLY POOR) TOOLING/PROCESS
   - A customer's ticketing system, change-management process, or
     internal documentation practice may be genuinely worse than what
     you're used to — the first-week job is adapting to it as it
     actually is, not silently working around it or pushing to replace
     it before you've earned the credibility (and understanding of
     why it exists) to propose that change well.
   - Proportional patience here matters: flag a genuinely blocking
     process gap early and specifically (not a vague complaint), but
     don't treat every unfamiliar or imperfect customer practice as
     something to fix in week one — Part 12.2's process-mapping
     discipline (understand before redesigning) applies to the
     customer's own internal tooling just as much as to their
     business process.

Skipping this layer of onboarding and jumping straight into architecture based on assumptions about the customer's environment is a common, avoidable source of exactly the kind of late-discovered surprise Part 14.1 warns about for deployment specifically — the pattern generalizes to the whole first week, not just the eventual deployment environment.

Technical discovery — the question bank Part 12.1's business discovery doesn't cover

Part 12.1's five-question framework surfaces the business problem. A parallel, distinct set of questions is needed to surface the technical reality you're about to build against — asked during this same first-week onboarding window, ideally with whoever on the customer's technical team actually operates these systems day to day:

Q1: "What does your current data schema actually look like for the
    systems this will touch — can I get direct read access to review
    it myself, not just a description?"
    → surfaces DATA STRUCTURE REALITY before any pipeline or extraction
    design is chosen (Part 10.2's real, common messy-data pattern) —
    a verbal description of a schema is frequently incomplete or stale.

Q2: "What authentication/SSO system do your internal users and
    systems already use, and does anything we build need to integrate
    with it rather than introducing a separate login?"
    → surfaces INTEGRATION REQUIREMENTS (Part 9.4/10's access-control
    chapters) early — retrofitting SSO integration after building a
    separate auth system is expensive rework discovered too late.

Q3: "What does your CI/CD process look like today — do you have
    automated testing and deployment, or is this largely manual?"
    → surfaces CI/CD MATURITY, directly shaping how much process
    scaffolding (Part 7.2) the engagement itself needs to bring versus
    plug into what already exists.

Q4: "What's the actual process to get a representative sample of real
    data for testing/prototyping — who approves it, and how long does
    that typically take?"
    → surfaces the SAMPLE-DATA ACCESS PROCESS explicitly, directly
    feeding Part 13.2's rapid-prototyping timeline — a slow or
    unclear data-access process discovered late can silently consume
    a prototype's entire allotted timeline before any actual testing begins.

Q5: "When something goes wrong in production today, what's your
    actual incident-response process — who gets paged, and what's
    the escalation path?"
    → surfaces the customer's EXISTING INCIDENT-RESPONSE PROCESS this
    system will need to plug into (Part 14's post-deployment operating
    model directly depends on knowing this, not inventing a parallel
    process the customer's ops team doesn't recognize).

Just as Part 12.1's business-discovery answers shape what gets built, these technical-discovery answers shape how it gets built and integrated — and, like Part 12.1's questions, they're best asked directly and early rather than inferred or assumed from a general impression of "a reasonably modern enterprise."

5. Simple mental model

The FDE engagement lifecycle is like a doctor's full relationship with a patient, not just the surgery: diagnosis (discovery), treatment planning (architecture), a minimally invasive test procedure before committing to major surgery (prototyping), the actual surgery (production engineering), recovery monitoring (deployment and production support), and a follow-up appointment to confirm the treatment actually worked (measuring impact) — a surgeon who does excellent surgery but skips diagnosis or never checks whether the patient actually recovered well has only done part of the job, however technically skilled the surgery itself was.

6. Real-world example

An FDE team's engagement with a mid-size insurance company followed this full lifecycle: discovery (Part 12) revealed the underwriting-review scenario used throughout this handbook's Part 11.2/12.2 examples; a two-week prototype (Part 13.2) validated that structured extraction accuracy met the required bar before any production commitment; the full production system (Parts 1-9) took roughly three months to build and harden; deployment (Part 14) required adapting to the customer's specific on-prem compliance requirements discovered only during that stage (a real, common lifecycle lesson: some requirements genuinely only surface once you're actually in the deployment environment, however thorough earlier discovery was); six months of production monitoring and two significant iteration cycles based on real underwriter feedback followed; and a formal impact review at the nine-month mark (Part 15) documented a measurable reduction in average review time, which directly became the basis for the customer's decision to expand the system to a second business line — closing the loop back to a fresh discovery conversation for that expanded scope.

7. Architecture diagram

See section 4's lifecycle diagram — this chapter's architecture is the full engagement process, not a technical system.

8. Production considerations

• Design early architecture decisions (step 2) with later lifecycle stages already in mind — Part 14's deployment realities and Part 15's measurement requirements shouldn't be an afterthought discovered only when those stages arrive; a system designed without observability (Part 8.4) from the start makes step 8's impact measurement much harder to do credibly later.
• Treat first-week technical onboarding as its own deliberate step, not something that happens automatically alongside discovery — request system/data access on day one given how long enterprise provisioning routinely takes, and run the technical-discovery question bank (section 4) explicitly rather than assuming the stack matches what business discovery implied.
• Never skip step 3 (prototyping) to save time — Part 13.2's entire argument is that this step exists specifically to catch expensive mistakes cheaply, before step 4's much larger investment.
• Treat steps 6-8 as integral to the engagement, not optional follow-up — an engagement that stops at deployment (step 5) has not actually completed the job this handbook has been building toward: proving real business impact.
• Feed step 7's iteration learnings back into explicit requirement updates (Part 12), not just quick, undocumented patches — this is what keeps the system's design intentionally aligned with reality rather than accumulating undocumented drift.

9. Common mistakes

• Rushing or skipping discovery (step 1) to get to "the real work" faster — the most common, most costly lifecycle mistake, per Part 12's entire argument.
• Assuming the customer's technical stack and stated stakeholders match reality instead of verifying directly during first-week onboarding (section 4) — building toward an approval or an integration point that was never actually going to hold.
• Requesting system/data access only once already blocked by its absence, instead of on day one, absorbing avoidable delay into the engagement timeline.
• Jumping from architecture directly to full production building, skipping the cheap validation prototyping provides (step 3, next chapter's entire subject).
• Treating deployment as the engagement's finish line, neglecting ongoing production support and impact measurement (steps 6-8) that a genuinely complete engagement requires.
• Not designing early architecture with later-stage needs (observability for measurement, deployment-environment flexibility) already considered.

10. Security considerations

Security work (Part 9) isn't a discrete lifecycle stage — it's integral throughout: discovery surfaces sensitivity/compliance requirements (Part 12.1), architecture bakes in security-by-design (Part 9's chapters, Part 11's system designs), and production monitoring includes ongoing security observability (Part 8.4/9) — a lifecycle view makes clear that security is a continuous thread, not a single checkpoint.

11. Performance considerations

Performance expectations set during discovery (Part 12.1's non-functional requirements) should be validated during prototyping (step 3) and continuously monitored during production (step 6) — a lifecycle view connects these as one continuous thread of the same requirement, not three unrelated activities.

12. Cost considerations

Cost estimated during architecture (step 2, Part 7.10) should be validated during prototyping and continuously tracked during production, feeding directly into the business-impact measurement (step 8, Part 15) that justifies the engagement's continued investment or expansion.

13. When to use it

Every real FDE engagement, as the mental map connecting every other skill this handbook has taught — this lifecycle view is what makes the individual skills (discovery, architecture, engineering, deployment, measurement) cohere into an actual professional practice rather than a disconnected skill list.

14. When NOT to over-apply it

A very small, low-stakes internal request might reasonably compress several lifecycle stages into an informal, fast process — but even here, the underlying logic (understand before building, validate before committing, measure whether it worked) scales down rather than disappears entirely.

15. Alternatives and trade-offs

The "alternative" to following this full lifecycle deliberately is an ad hoc engagement that jumps between stages unpredictably or skips some entirely — section 9's common mistakes are exactly what results, at real, avoidable cost to the engagement's success.

16. Practical Python/code example

An engagement-lifecycle tracker, making the lifecycle stages an explicit, trackable artifact rather than an implicit, easily-skipped process:

from dataclasses import dataclass, field
from datetime import datetime
from enum import Enum


class LifecycleStage(str, Enum):
    DISCOVERY = "discovery"
    ARCHITECTURE = "architecture"
    PROTOTYPING = "prototyping"
    PRODUCTION_ENGINEERING = "production_engineering"
    DEPLOYMENT = "deployment"
    PRODUCTION_SUPPORT = "production_support"
    ITERATION = "iteration"
    IMPACT_MEASUREMENT = "impact_measurement"


@dataclass
class EngagementRecord:
    """Tracks a real engagement's progress through the full lifecycle,
    making stage-skipping visible rather than implicit."""
    customer_name: str
    current_stage: LifecycleStage
    stage_history: list[tuple[LifecycleStage, datetime]] = field(default_factory=list)

    def advance_to(self, stage: LifecycleStage) -> None:
        """Advances to a new stage, recording the transition."""
        self.stage_history.append((stage, datetime.now()))
        self.current_stage = stage

    def skipped_stages(self) -> list[LifecycleStage]:
        """Flags any stage skipped entirely, surfacing this as a visible risk."""
        completed = {stage for stage, _ in self.stage_history}
        return [s for s in LifecycleStage if s not in completed and s.value < self.current_stage.value]

17. Production-quality example

An engagement-retrospective template, directly implementing step 8's "feed learnings back" recommendation as a structured practice:

# Engagement Retrospective: [Customer Name]

## Discovery accuracy
[What did discovery correctly anticipate? What did it miss, only
 discovered later — and at what stage?]

## Prototyping value
[What did the prototype catch before full production investment?
 What would have been costly to discover later instead?]

## Deployment surprises
[What environment-specific requirements only surfaced during deployment,
 despite thorough earlier discovery?]

## Impact vs. original success metric
[Compare actual measured impact (Part 15) against the success metric
 established during discovery (Part 12.1, Q5) — did it match?]

## Lessons for future engagements
[What pattern from this engagement should inform how you approach
 discovery/architecture/prototyping for the NEXT customer?]

18. Short exercise

Using the lifecycle stages from section 4, identify which stage each of the following real-world statements most likely belongs to, and explain your reasoning: (a) "we found out during rollout that their firewall blocks the port our health check uses," (b) "the two-week test showed 60% extraction accuracy, well below what we need," (c) "the customer wants to expand this to their EU office now."

19. Interview questions

• Walk through the full FDE engagement lifecycle and explain why it's better understood as a loop than a linear sequence.
• What's the most common point in the lifecycle where real engagements break down, and why?
• Why should architecture decisions made early in an engagement already account for later stages like deployment and impact measurement?
• What should happen in your first week at a new customer, before any architecture decisions are made, and why does requesting system access on day one matter?
• How do you identify the real decision-makers on a customer engagement when the people in the room aren't necessarily the ones whose approval actually matters?

20. FDE/customer scenario

CUSTOMER (six months after a successful pilot): "This has worked great for our underwriting team — can we do the same thing for our claims team?"

This is precisely the lifecycle loop closing (section 4) — rather than assuming the underwriting solution transfers directly, the FDE-correct response returns to step 1: a fresh discovery conversation for the claims team's specific process (Part 12.1/12.2), informed by real patterns and lessons from the underwriting engagement, but not assuming they transfer unchanged without verification.

A first-week variant — CUSTOMER'S PROJECT LEAD (day two of a new engagement): "Don't worry about access requests for now, just start with the sample files I sent over." The FDE-correct response pushes back gently but immediately: submitting the formal access request today, in parallel with reviewing the sample files, because enterprise provisioning routinely takes days to weeks (section 4's first-week onboarding playbook) — starting it late, once actually blocked without real system access, converts an avoidable parallel-track delay into a serial one that eats directly into the engagement timeline.

---

Key takeaways

• A real FDE engagement is a continuous, eight-stage lifecycle (discovery through impact measurement) that loops back into future discovery, not a linear sequence that ends at deployment.
• First-week technical onboarding (access requests, mapping the real stack, identifying actual decision-makers, adapting to existing tooling) is distinct from Part 12's business discovery and needs its own deliberate attention, not an assumption that it happens automatically.
• A technical-discovery question bank (data schemas, auth/SSO, CI/CD maturity, sample-data access, incident response) parallels Part 12.1's business-discovery bank and should be run explicitly during onboarding.
• Early architecture decisions should account for later lifecycle stages (deployment realities, impact measurement needs) from the start, not as afterthoughts.
• The most common, costly lifecycle failures are rushing discovery and skipping prototyping — both covered in depth by this handbook's own preceding and following chapters.

Things you should be able to explain

• The full eight-stage lifecycle and why it's a loop rather than a line.
• Why deployment is the midpoint, not the finish line, of a complete engagement.
• The difference between Part 12.1's business-discovery questions and this chapter's technical-discovery questions, and why an engagement needs both.

Things you should be able to build

• An engagement-lifecycle tracker and a structured retrospective template feeding learnings into future engagements.
• A first-week onboarding checklist and a technical-discovery question bank for a new customer environment.

Common mistakes

• Rushing or skipping discovery.
• Requesting system/data access late instead of on day one of the engagement.
• Assuming the stated project lead is the actual decision-maker without verifying who else must sign off.
• Skipping prototyping and jumping straight to full production building.
• Treating deployment as the engagement's completion rather than its midpoint.

Recommended next chapter

02-rapid-prototyping-and-demos.md