30-60-90 day plan for data engineers
On this page
A data engineer arrives knowing SQL, a programming language, an orchestration tool and probably a cloud warehouse. What they do not know is this company's data: which source systems are reliable, which tables people actually use, what breaks at month-end and who notices first when a dashboard goes stale. Most early mistakes come from changing a pipeline without knowing who depends on it. A 30-60-90 day plan for data engineers should have the new hire trace the data before changing it, then ship one tested pipeline, then own a data domain with its freshness, quality and cost.
This plan is for the data engineering manager or analytics lead hiring a data engineer to build and run pipelines, models and the warehouse that analysts and data scientists rely on. The general structure is in the 30-60-90 day plan template for new hires. If the role is still open, the data engineer phone screen questions cover modeling, pipeline design and troubleshooting before the offer.
Access and context to set up first
| Item | Owner | Needed before |
|---|---|---|
| Repository, orchestration and warehouse access at the least privilege the work needs | Platform lead | Running any pipeline |
| A development environment that mirrors production | Platform lead | The first code change |
| Data classification and access policy | Security or privacy team | Touching personal, health, payment or employee data |
| On-call runbook and the last few incident reviews | Data engineering manager | Shadowing on-call |
| A list of the most used tables and dashboards, with their owners | Analytics lead | Changing anything those depend on |
Privacy and security obligations depend on what data flows through the pipelines and on the company's contracts, so the plan should point to the company's own policy rather than to a general rule. If the team handles regulated data, ask the privacy or compliance owner to brief the new engineer in week one.
The 30-60-90 day plan
30-60-90 day plan — [Name], Data Engineer, [team]
Reports to: [data engineering manager] Start: [date]
Stack: [warehouse], [orchestration], [transformation tool]
Main consumers: [analytics, data science, finance, product]
Buddy: [senior data engineer]
DAYS 1-30 — Trace the data before changing it
Goals:
- Access working; run one production pipeline in development
- Trace two critical tables from source to dashboard and
write down every transformation and owner
- Read the last incident reviews and shadow one on-call week
- Fix one or two small bugs through code review
(example: a failing test or a late-arriving data issue)
Deliverables by day 30:
- Lineage notes for the two traced tables
- First changes merged with review comments logged by type
Check-in: day 30, with manager
DAYS 31-60 — Ship a tested pipeline
Goals:
- Build or migrate one pipeline end to end (example: ingest a
new source system, or move a legacy job to the current stack)
- Add data quality tests and alerts on what consumers rely on
- Agree a freshness expectation with the main consumer
- Join on-call as secondary responder
Deliverables by day 60:
- Pipeline in production with tests, documentation and an owner
- Consumer sign-off on freshness and definitions
Check-in: day 60
DAYS 61-90 — Own a domain
Goals:
- Own a data domain (example: billing or product events) with
its pipelines, tests and documentation
- Review the cost of the jobs in that domain
- Close one recurring failure cause found in the incident history
Deliverables by day 90:
- Domain status: freshness, failures, open issues and cost
- One recurring failure cause fixed and measured
Check-in: day 90 — full reviewWhat to measure
Lines of code and number of pipelines built say little. Measure reliability, quality and cost on what the engineer owns, and compare against the team's own baseline. The standards below are examples only.
| Measure | Why it matters | Example standard (example only) |
|---|---|---|
| Freshness misses on owned tables | Late data breaks reports people use to decide | Fewer misses than the domain's baseline |
| Failed runs and time to recover | Shows how robust and observable pipelines are | Every failure has a logged cause |
| Issues caught by tests vs reported by users | Users should not be the monitoring system | A rising share caught by tests |
| Compute cost of owned jobs | Warehouse spend grows quietly | Reviewed monthly; large changes explained |
| Documentation coverage | Undocumented tables get misused | Every owned table has a description and owner |
A filled example
Data engineer: Tomás Rivera (invented), three years as an analytics engineer, joining a subscription software company's data platform team.
Day 30: Traced the revenue table and the product events table to their dashboards and found two undocumented filters that explained a long-running mismatch between finance and product numbers. Fixed a test that had been failing silently.
Day 60: Migrated the billing ingestion job from a legacy scheduler to the team's current orchestration tool, with tests on row counts, duplicates and key fields. Agreed a morning freshness expectation with finance.
Day 90: Owns the billing domain. Fixed a recurring failure caused by a source system timezone change, and freshness misses fell against the domain's baseline. Reported the domain's monthly compute cost for the first time.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Lineage traced; small fixes merged; on-call shadowed | Large refactors proposed before the data is understood |
| Day 60 | A tested pipeline in production with a consumer agreement | Pipeline shipped without tests or without telling consumers |
| Day 90 | A domain owned with freshness, failures and cost reported | Repeated failures with no cause; users still finding the problems |
Talk to the consumers
A data engineer's work is judged by people who never see the code: analysts, finance, product managers and data scientists. In the first month, ask the new engineer to meet the main consumers of the tables they will own and ask three questions: what do you use, when do you need it by, and what has gone wrong before. The answers turn into freshness expectations, test priorities and documentation. The data analyst plan and the data scientist plan show what those consumers are trying to do in their own first months.
The day-30 lineage note
The most useful first deliverable is a short written trace of two critical tables. It does not need a diagramming tool. For each table, the note should list the source systems and how data arrives from them, every transformation step with the job that runs it, the tests that exist and the ones that are missing, the people and dashboards that read the table, and anything that surprised the engineer. Review it with the buddy and the main consumer. Gaps found here, such as a filter no one documented or a job with no owner, become the first candidates for the day-60 and day-90 work, and the note itself becomes documentation the next hire can use.
What the team owes the new engineer
- A development environment that works and mirrors production closely enough to test changes.
- Honest documentation of known problems, including the jobs everyone avoids.
- Timely code review from someone who knows the domain.
- A clear on-call ramp, from shadow to secondary to primary, with dates.
Common mistakes
| Mistake | Result | Fix |
|---|---|---|
| Changing a table without checking who uses it | Broken dashboards and lost trust | Trace lineage and tell consumers first |
| Shipping pipelines without tests | Users find the problems | Tests on what consumers rely on, before release |
| Broad production access on day one | Avoidable security and data risk | Least privilege, expanded as needed |
| Ignoring cost | Warehouse spend grows unnoticed | Monthly cost review for owned jobs |
Adapting the plan
- Streaming and real-time systems: replace freshness in hours with latency and lag measures, and give more time to on-call shadowing.
- Platform-focused roles: swap the domain for infrastructure ownership and coordinate with the DevOps engineer plan on deployment and reliability practice.
- Small teams with one data engineer: cut the domain to the few most used tables and add a written inventory of every pipeline, since no one else will have one.
If you are still sourcing, the boolean search strings for data engineers and the data engineer job description template help define and find the right profile.
Questions people ask
What should a new data engineer do in the first week?
Get development access with the least privilege the work needs, run one production pipeline in a development environment, and trace one important table from its source system to the dashboard that uses it. Read the incident history and the on-call runbook, and fix one small, real bug through code review.
When should a new data engineer join on-call?
Usually as a secondary responder in the second month, after shadowing at least one full rotation and fixing a few failed runs with a senior engineer. Primary on-call can follow once they own a domain and have handled incidents in it.
How do you measure a data engineer's first 90 days?
By freshness and failure rates on the pipelines they own, the share of data problems caught by tests rather than reported by users, time to recover from failed runs, and the cost of the jobs they own. Compare against the team's own baseline for those pipelines, not an industry figure.
What legal or privacy rules does a data engineer need to know?
That depends on the data. Pipelines that carry personal, health, payment or employee data can fall under privacy and security laws and contracts. A new data engineer should get the company's data classification and access policy from the security or privacy team in the first week and follow it, rather than deciding what is sensitive on their own.