Team Timelines

Five-week plans for the three data teams, one per project. Each timeline names what every trainee owns in each week, and makes the tool boundaries do the work that anti-silo rules usually fail to do.

By the end of this chapter, you should be able to name your five-week ownership plan, the week-3 handover ritual, and what to cut first if you fall behind.

Treat these as starting plans, not contracts. Adjust the detail, keep the shape.

How the three teams differ

Team	DEs	Project	Sources
Team A	2	B, Commute Reliability	Rijden de Treinen open data, OVapi
Team B	2	C, Contribution Tracker	GitHub REST API
Team C	3	A, Job Market Radar	Arbeitnow, Adzuna

<aside> ⚠️ Your team letter and your project letter are not the same thing. Team A builds project B. The project letters come from the six-project catalogue in Project Ideas; your team letter is which monorepo and Azure resources you own.

</aside>

All three build the same architecture. What differs is the project, and how many sources it needs.

The 2-DE teams take ingestion-heavy projects, where the difficulty is in the source rather than in the number of them. The 3-DE team takes two sources, because two sources is what a third person needs: one ingestion owner each, into one schema they design together.

Team C's second source is not decoration. Combining Arbeitnow and Adzuna into one mart is what gives the third seat work of its own. That second source starts after the first feed runs green in dev and prod, not in week 1.

The data team's order of work

Every team follows this sequence together before the tool split in week 4. Seat ownership in the tables below applies only after step 6.

Step	What all DEs do together	Chapter
1. Pick one source	Investigate candidates, compare access and fields, agree on one feed for the first chain	Project Ideas
2. Share a sample	Download real extraction output; document schema; hand file to backend and frontend	Cross-Track Collaboration
3. Local ingestion script	Pair on Python that fetches your source; verify on your laptop	Project Ideas
4. Dev pipeline green	`dev` landing, dbt in `dev_<name>`, publish to `analytics_dev` (Path A)	Running the Pipeline Locally
5. Prod pipeline green	Merge, scheduled run, rows in `analytics`	Promoting to Production
6. Expand and divide	Second source, enrichment, ingestion hardening; split ingestion vs platform vs orchestration	This chapter

<aside> 💡 Week 1 still includes the starter pipeline baseline on Arbeitnow (steps 4–5 on the template feed) before you swap in your chosen source at step 3.

</aside>

gantt
    title All teams: five-week data workflow
    dateFormat YYYY-MM-DD
    axisFormat Week %W

    section Week 1
    Compare sources and pick one       :w1a, 2026-01-06, 7d
    Sample and schema to backend       :w1b, 2026-01-08, 5d
    Starter pipeline baseline          :w1c, 2026-01-06, 7d

    section Week 2
    Local Python ingestion             :w2a, 2026-01-13, 7d
    Dev pipeline on chosen source      :w2b, 2026-01-15, 5d

    section Week 3
    Prod pipeline on first source      :w3a, 2026-01-20, 5d
    Platform setup                     :w3b, 2026-01-22, 4d
    Tool handover                      :milestone, 2026-01-26, 0d

    section Week 4
    Expand scope and divide by tool    :w4a, 2026-01-27, 7d

    section Week 5
    Freeze docs tests rehearsal        :w5a, 2026-02-03, 7d

<aside> 💡 Weeks map to calendar weeks of your project, not to HYF curriculum week numbers. Week 1 here is the first week your team builds.

</aside>

You own tools from week 4, and you switch once

The usual way a team of two splits work is by layer: one person takes the pipeline, the other takes the models. Five weeks later neither can explain the other half. Rules asking people to share knowledge do not fix this, because nothing breaks when you ignore them.

Weeks 1 to 3 are together: one source, one chain, one prod run. That is the thin slice (the smallest path that proves data flows end to end). The split is by tool, and it starts in week 4, after your first source is green in production.

	Weeks 1 to 3	From week 4	Which forces you to understand
DE1	Together: source choice, sample, local script, dev and prod pipeline	Ingestion (and orchestration in 2-DE teams)	DE2's platform, because your DAG runs on it
DE2	Together: same first chain	The platform (week 3 setup) then models and marts	DE1's ingestion, because models read what landed

Nothing here depends on good intentions. DE2 cannot write a staging model without reading what DE1's ingestion actually landed, because they have to query it. DE1 cannot schedule anything without the container, the registry and the secret store DE2 built. The dependency does the teaching.

<aside> 💡 Ownership does not move at the handover. DE1 still owns the ingestion after week 4 and still reviews changes to it. What moves is where each of you spends your time, and the new work sits on top of the old.

</aside>

Six rules go with it, and the timelines below build them in.

Rule	Where it happens
1. One source decided together	Week 1. Compare candidates before anyone writes container code
2. Sample to backend before dbt	Week 1–2. Real JSON and field list before staging models
3. Dev pipeline green, then prod	Weeks 2–3. Path A on your source, then scheduled `analytics`
4. Expand and divide only after prod	Week 4+. Second source, enrichment, tool handover
5. Cross-review every pull request	Every week. After the switch you review work built on top of your own
6. Any DE explains any part	Week 5 rehearsal, then the demo itself

Tool handover at the end of week 3

Book 30 minutes per person at the end of week 3 for the tool handover, and put it in the calendar in week 1. The handover happens after your first source runs green in prod, not before.

Show your teammate three things: how your tool runs, the one thing you know is weak about it, and a question you never had time to answer. Then write a short README section for it, naming yourself as the owner.

The person receiving it opens their first pull request of week 4 within two days, and you review it. If nobody has opened one after two days, the handover did not happen and week 4 is already at risk.

Nothing half-built crosses the handover

If a tool still has a failing test or an open TODO at the end of week 3, its owner finishes it in week 4 alongside the new work. Handing over unfinished work gives you two people who each half-understand it, which is worse than one who fully does.

That is why the timelines say "finish the ingestion this week" instead of leaving it open. Week 3 is a deadline, not a phase that drifts.

Week 1: compare sources, baseline the platform

Every timeline below starts the same way. Week 1 delivers a source comparison and one chosen feed, a source report for that feed, a sample file to backend, one architecture diagram, and a green starter pipeline on the template feed: preflight plus Path A from Running the Pipeline Locally, Mode 1 from Orchestrating with Airflow, and one unchanged prod trigger from Promoting to Production.

Almost every project that falls apart in week 4 does so because nobody agreed which source to build first, or because the platform was never proven before custom code landed.

All DEs together in week 1:

Compare the feeds your project might use (Team A: live API vs historical dump; Team B: validate the GitHub API; Team C: Arbeitnow vs Adzuna).
Agree on one source for the first end-to-end chain. Write the full source report for that source only.
Download a real extraction sample; document fields; share with backend and frontend.
Draw the architecture diagram and draft the mart contract.
Green the starter pipeline (Arbeitnow) so you know the platform works before you swap feeds.

Your source report is one page, committed to the repository, answering:

Can you get it at all? Key, registration, request limits, and what the terms permit. A source you may not legally use is far better found now.
How much is there, and how far back? Enough rows to be interesting, and enough history to show a trend.
How often does it change? A feed that never changes cannot justify a daily pipeline.
What is in one record? The fields you can use, the ones that are always empty, and the ones that are dirty.
Does it answer the product question? State it in one sentence. If you cannot, you have the wrong source, and this is the cheapest week to swap it.

The architecture diagram is one mermaid diagram in your README, agreed by every trainee on the team. Copy the ownership map at the top of Cross-Track Collaboration (three tracks, outbound sync). Relabel the boxes to your product: your sources, where raw data lands, where the marts live, outbound sync to analytics, and who owns each part. The later mart-shape diagram in that chapter is for table grain, not the README architecture picture.

<aside> 💡 Draw the diagram in week 1 and edit it whenever something changes. It is not a week 5 deliverable you recreate from memory. It is what you point at every time somebody asks where a number comes from, so by the demo it should have been revised several times.

</aside>

Prove your chosen source with a real request you made yourself. API documentation describes what the source is supposed to return, which is not always what it does return.

Week 1 details are in the Final Project Brief checklist. Weeks 2 and 3 walk the same source through local ingest, Path A, Astro, and prod before week 4 expansion.