Onboarding Data Engineers and Analysts: The First 30-60-90 Days

A new data engineer or analyst who spends their first month navigating undocumented systems, asking questions that nobody has time to answer, and guessing at conventions that are never written down is a hire that will take 6–12 months to reach meaningful contribution. The same person, given structured onboarding, documented environments, and deliberate immersion in the systems and context they need, can be independently productive in 6–8 weeks.

The difference is almost never talent. It is onboarding.

What Good Onboarding Achieves in Week One

The first week is not about contribution — it is about context. The goal: by the end of week one, the new hire understands the data infrastructure, has working access to every system they need, and has a mental model of where data comes from, how it flows, and how the team's work fits into the business.

**Access provisioning before day one**: GitHub repository access, data warehouse access, BI tool access, Slack access, and documentation wiki access should be provisioned before the hire's first day. Nothing signals disorganisation and disrespect for someone's time like spending their first morning waiting for IT to create accounts. Access provisioning should be automated — a standard new data team member access checklist that can be run in 30 minutes.

**The system map**: a documented overview of the data infrastructure — what sources exist, how they are ingested, what the transformation layer looks like, where certified data is accessible. This document should always exist in the team's documentation. If it does not, writing it is the onboarding engineer's first task (which benefits both the new hire and the team).

**The data model walkthrough**: a 90-minute session with a senior team member walking through the core data model — the fact and dimension tables, the key metrics, the business concepts and how they are modelled. A new hire who does not understand the data model will produce incorrect analysis for months without knowing it.

**The first pull request by end of week one**: a trivial change — a documentation addition, a test case addition, a minor calculation fix — submitted through the normal PR process. The goal is to verify that all tooling works end-to-end and that the new hire understands the PR workflow before they are working on anything consequential.

The 30-Day Milestone: Independent Problem Solving

By day 30, the new hire should be able to answer a basic analytical question independently. Not a complex one — a basic one. "How many orders were placed in Q1 this year, by region, compared to Q1 last year?" They know where to find the data, they know how to query it correctly, they know which tables to use and which joins are valid, and they know how to check their result for plausibility.

This milestone requires:

**Paired work with a senior team member for the first two weeks**: not supervision, but collaborative work where the new hire is doing the work and the senior team member is available to answer questions in real time. The senior team member explains decisions as they are made — "we use this table rather than that one because...", "we always add this filter because...", "this calculation is defined this way because of the incident we had in Q3 last year." Context that is obvious to an experienced team member is invisible to a new hire without it.

**A defined onboarding project**: a bounded, real project (not a toy project) of appropriate scope that the new hire owns from scoping to delivery. Real work with real stakes, but scoped to something completable in 3–4 weeks without deep context. The onboarding project validates that the new hire can apply their knowledge in context and surfaces gaps in their understanding in a low-risk setting.

**Documentation expectations from day one**: the new hire documents everything they discover that is not already documented. Every undocumented convention they encounter, every gap in the data model documentation they notice, every process they figure out that is not written down. This is a direct contribution to the team and accelerates their own understanding — writing documentation forces the kind of clarity that reading someone else's documentation does not.

The 60-Day Milestone: Domain Understanding

By day 60, the new hire should understand not just the technical systems but the business domain — what the business is, how it makes money, what the critical metrics are and why they matter, and who the key stakeholders are.

**Stakeholder introductions**: schedule the new hire to meet with key stakeholders in their first 60 days — not just data team stakeholders, but the business users they will be serving. A 30-minute call with the VP of Sales, the Head of Finance, or the Head of Operations gives the new hire context that no amount of documentation provides. Understanding the questions these stakeholders actually have — not the questions they submit as tickets, but the ones they care about — shapes how the new hire thinks about analytical problems.

**Deep dive on business metrics**: a structured session (or series of sessions) on how key business metrics are calculated, why they are calculated that way, where they have been controversial, and what common misinterpretations exist. "Revenue" at most organisations has multiple valid definitions that are correct in different contexts. A new hire who does not know this will use the wrong definition in the wrong context.

**Exposure to past incidents**: reviewing past data quality incidents — what went wrong, how it was detected, how it was resolved — gives a new hire a practical understanding of failure modes that they cannot develop from documentation alone.

The 90-Day Milestone: Autonomous Contribution

By day 90, the new hire should be contributing autonomously to the team's backlog without requiring significant guidance on scope or approach.

This milestone is defined differently depending on the role:

For a **data engineer**: owns a complete pipeline from ingestion through transformation, with all tests passing, documentation written, and the pipeline operating reliably in production.

For an **analytics engineer**: owns a complete data model domain (a set of related dbt models), with tests, documentation, and governance in place.

For an **analyst or BI developer**: owns a complete dashboard or analytical project from requirements through delivery, with stakeholder acceptance and documented sources.

The 90-day milestone is where the onboarding investment pays off. A new hire who has been well-supported through the first 90 days is not just productive — they are productive with judgment. They make decisions consistent with the team's standards without constant supervision because they have absorbed the context that informs those decisions.

What Onboarding Failure Looks Like

**Week one without system access**: the new hire spends their first day waiting for accounts to be created. Signal sent: the team is not organised enough to have expected their arrival.

**No onboarding project**: the new hire picks up random tickets from the backlog without context. They produce technically correct output that misses the point, because they do not understand the business context the ticket lives in.

**No documentation culture**: the new hire asks questions and receives verbal answers. The knowledge lives in conversations rather than in writing. Six months later, another new hire asks the same questions.

**Sink or swim**: the new hire is expected to be independently productive in week two. They produce work that requires significant rework. They feel unsuccessful. Some leave.

Our data engineering practice helps organisations build data team processes and structure — contact us if you are scaling a data team and need support with team processes and structure.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.