Start Here
The practitioner's operating manual for FDE-Data-Engineering deployments. How to use this playbook, the operating mental model that makes the templates make sense, and the defaults worth questioning per deployment.
What this playbook is
This is the bench of templates and procedures an FDE-DE actually runs. Not theory; not interview prep. The artifacts on this bench:
- A 90-day deployment plan, week by week.
- Discovery questions by persona — data team, sponsor, IT, end-users.
- A working-agreement template (one page, signed by the senior stakeholder).
- Cadence templates — Monday sync agenda, Friday status doc.
- Scoping and kill-decision worksheets.
- Six pre-written runbooks for common failure modes.
- Escalation playbook across three lanes.
- Handoff checklist.
- Catalog of the dozen most common deployment failures, with prevention.
The templates are designed to be copied directly into Notion, Google Docs, your team's wiki, or your terminal. Format intentionally bland; you'll style it your way once it's in the customer-facing place.
Who it's for
- New FDE-DEs in their first 90 days. Use the 90-day plan and discovery templates to anchor your first deployment.
- FDE-DEs taking on a new customer. Pull the working-agreement template, customize it, ship it in week two.
- Senior FDEs writing runbooks for the customer's data team. The runbook templates are the starting point — adapt to the specific deployment.
- FDE managers training new hires. The "common deployment failures" catalog (chapter 09) is the prevention reading.
The operating mental model
The templates make more sense if you carry three framings.
1. The deployment has four phases, and the first 14 days set the rest
Discovery (1–14), first slice (15–30), scale to SLA (31–60), handoff (61–90+). Most deployment failures originate in the discovery phase — you scoped against the wrong stakeholder, missed the customer's data reality, or skipped the working agreement. Spending half of week two on the working agreement seems slow; it isn't.
2. The customer's data team is your peer, not your user
Embed accordingly. They'll inherit the deployment after handoff; their judgments about your code, your runbooks, your data model matter from day one. Talk to them like you would talk to an internal teammate — direct, evidence-based, no condescension.
3. Friday status doc is the single most important artifact
Five sections, one screen, ships every Friday morning. Customers who don't read it carefully aren't engaged enough to make the deployment succeed — that's a leading indicator of trouble. Skipping it for a week is how deployments quietly drift.
How to use the playbook
Two ways:
- Read end-to-end once, then keep it as a reference. New FDE-DEs should do this. ~2 hours total.
- Pull individual chapters as you need them on a deployment. Chapter index in the hub is the table of contents.
Every chapter ends with a copy-paste template or worksheet. Format is Markdown-ish so it travels into Notion, Google Docs, or a wiki cleanly.
Defaults to question (per deployment)
The templates have sensible defaults. Some of them won't fit your specific deployment. Worth questioning when you customize:
- Friday status frequency. Weekly is the default; some deployments warrant biweekly. Daily-status is almost always a smell of an unhealthy deployment, not a healthy intense one.
- Working-agreement length. One page is the default. Highly regulated customers may want longer. Don't expand for performance; expand because the customer needs the specificity.
- Discovery duration. Two weeks is the default. Smaller deployments (one document class, one team) might shorten to one. Larger ones (multi-business-unit) sometimes need three. Don't compress to look fast; you'll pay it back later.
- Runbook ownership. Default is FDE writes; customer's data team owns after handoff. If the customer team has strong opinions about their format, adopt those — it's their on-call queue.
- Escalation thresholds. What warrants paging the platform team vs the AE vs leadership varies per customer. The defaults here are starting points.