30-60-90 day plan for data analysts
On this page
- Three stages of a data analyst's ramp
- The 30-60-90 day plan
- Reconciling metrics: the most useful first assignment
- Reviewing a new analyst's SQL
- What "on track" looks like
- A filled example
- Turning requests into questions
- What the hiring manager owes the new analyst
- Adapting the plan
- Questions people ask
The risk with a new data analyst is not that they cannot write SQL. It is that they write SQL that runs, returns a plausible number, and is wrong, because they joined on the wrong key or used a different definition of "active customer" than the finance team. A 30-60-90 day plan for a data analyst should be built around catching that early, then moving the analyst from answering requests to answering questions that change decisions.
For the general version of this template across roles, see the 30-60-90 day plan template for new hires. This page is for the analytics lead or business manager who has just hired an analyst.
Three stages of a data analyst's ramp
- Trust the data. Know where the numbers come from, how each key metric is defined, and where the known data quality problems are.
- Be trusted with requests. Deliver correct, reviewed answers to stakeholder questions, on time, with the caveats stated.
- Change a decision. Take a vague business question, turn it into an analysis, and present a recommendation someone acts on.
Most analyst plans skip the first stage because it produces nothing a stakeholder sees. It is also the stage that prevents the embarrassing number in a leadership meeting in month three.
The 30-60-90 day plan
30-60-90 day plan — [Name], Data Analyst, [team or business area]
Manager: [name] Start date: [date] Code reviewer: [name]
Stack: [warehouse, e.g. Snowflake / BigQuery / Redshift / Postgres]
[transformation, e.g. dbt] [BI, e.g. Looker / Tableau / Power BI]
DAYS 1-30 — Learn the data and the definitions
Goals:
- Access to the warehouse, BI tool, git repo and data catalog by end of week one
- Read the definitions for the area's [5-8] key metrics and the models behind them
- Reproduce each key metric from source tables and reconcile it to the
production dashboard; explain any difference
- Answer [3-5] small ad hoc requests, SQL reviewed before sending
- Meet the main stakeholders and ask what decisions they make with data
Deliverables by day 30:
- A metrics notebook: definition, source tables, query and reconciliation
result for each key metric
- A data issues list: gaps, duplicates, broken fields and stale tables found
DAYS 31-60 — Own the request queue and one recurring report
Goals:
- Handle the area's request queue with agreed turnaround times
- Take over one recurring report or dashboard: its refresh, its accuracy,
and the questions it generates
- Scope one larger analysis with a stakeholder, starting from the decision
it is meant to inform
- Fix or escalate at least two items from the data issues list
Deliverables by day 60:
- A request log with turnaround times and no reworked answers
- A written analysis plan: question, decision, data, method, timeline
DAYS 61-90 — Deliver an analysis that changes something
Goals:
- Complete the scoped analysis and present it with a recommendation
- Build or rebuild one dashboard the stakeholder uses weekly, with
definitions visible on the dashboard itself
- Review a teammate's SQL or model change
Deliverables by day 90:
- The analysis deck or memo, and the decision it informed
- A dashboard with documented definitions and an owner
Check-ins: weekly 1:1; formal reviews at day 30, 60 and 90.Reconciling metrics: the most useful first assignment
Asking a new analyst to reproduce the business's key numbers from raw tables sounds like busywork. It is the opposite. To get monthly recurring revenue or weekly active users to match the dashboard, the analyst has to find the right tables, learn how refunds, trials, internal accounts and test users are handled, and understand the transformation logic between raw events and the number the CEO sees. When the numbers do not match, and some usually do not, the analyst has found either a gap in their understanding or a real bug in production reporting. Both are worth knowing in the first month.
At the day-30 check-in, ask the analyst to walk through one reconciliation that did not match at first. How they chased down the difference tells you more about their rigor than any finished query.
Reviewing a new analyst's SQL
Review focuses on the errors that produce believable wrong answers, not on style:
- Join fan-out. Joining a customer table to an orders table and then summing a customer-level field multiplies it. Ask how the analyst checked row counts before and after each join.
- Filters and definitions. Are test accounts, internal users, refunds and cancelled orders handled the way the official definition says?
- Time zones and date boundaries. Does "last week" mean the same thing here as in the finance report?
- Nulls. Does a count or average silently drop rows where a field is empty?
- Reproducibility. Is the query in the repo or a saved notebook, or only in the analyst's scratch tab?
By day 60, an analyst's review requests should come back with fewer correctness comments and more questions about approach. That shift is the clearest signal that stage one is done.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Key metrics reproduced and reconciled, with differences explained; reviewed answers need minor edits; a real data issue found | Still waiting on access; queries copied from old dashboards without understanding them; no stakeholder conversations yet |
| Day 60 | Requests delivered on time with caveats stated; the recurring report runs without the manager; the analysis plan starts from a decision | Answers reworked after stakeholders spot errors; the analysis plan is "explore the data and see" |
| Day 90 | The analysis led to a decision or a clear "do not do this"; the dashboard is used weekly | A long deck with many charts and no recommendation; a dashboard nobody opens |
A filled example
Analyst: Kenji Watanabe (invented), data analyst supporting the marketing and growth team at a subscription meal-kit company.
Day 30: Reproduced six marketing metrics. Customer acquisition cost matched. Trial-to-paid conversion did not: the dashboard counted customers who paused before their first charge as converted. He documented the difference, and the analytics lead confirmed the dashboard was wrong.
Day 60: Ran the growth team's request queue with a two-business-day turnaround and no reworked answers. Took over the weekly channel performance report. Scoped an analysis with the growth lead: should the team keep paying for a referral bonus, given its cost per retained customer?
Day 90: Found that referred customers retained better than paid-social customers but that the bonus size could be cut without a visible drop in referral volume, based on an earlier period when the bonus had been lower. The growth lead ran a test with a smaller bonus. Kenji rebuilt the channel dashboard with definitions shown under each chart.
Turning requests into questions
The difference between an analyst who stays in the request queue and one who grows is a single habit: asking what decision the numbers are for. "Pull last quarter's churn by plan" becomes more useful once the analyst knows the requester is deciding whether to retire a plan, because the answer then needs churn by tenure, not just by plan. Build this into the day 31-60 phase explicitly. For every request, the analyst writes one line on the decision it supports; if they cannot, they ask. Within a few weeks stakeholders start bringing questions instead of pull requests, which is what the day-90 analysis needs.
What the hiring manager owes the new analyst
- Warehouse, BI and repo access in week one. An analyst without access spends the first month reading documentation that may be out of date.
- A named reviewer for SQL and a turnaround expectation for reviews.
- The official metric definitions, or honesty that they do not exist yet.
- Introductions to the stakeholders the analyst will serve, framed as "bring your questions here."
- Protection from an unmanaged request flood in the first 30 days, so the reconciliation work actually happens.
Adapting the plan
- Analyst embedded in a business team without a data team: there may be no reviewer. Arrange a peer review with an analyst elsewhere in the company, or budget a few hours of review from a contractor, rather than skipping review.
- Junior or first analyst role: extend stage one to 45 days and treat an owned recurring report, not a strategic analysis, as a strong day-90 result.
- Heavy data engineering needs: if the reconciliation reveals broken pipelines, the analyst should log and escalate them, not quietly fix them in their own queries. The data engineer phone screen questions help if the real gap is engineering capacity.
If you are still hiring, the data analyst phone screen questions test for the rigor and stakeholder habits this plan depends on. At day 90, the new hire 90-day review template gives a structure for the formal conversation.
Questions people ask
What should a data analyst deliver in the first 30 days?
Reproductions of the business's key metrics from raw tables, matching the numbers in the existing dashboards or explaining exactly why they differ, plus a few small ad hoc requests answered with reviewed SQL. That proves access, data literacy and an understanding of the definitions before the analyst is trusted with bigger questions.
Should a new analyst's SQL be reviewed?
Yes, at least for the first 60 days and for anything that goes to leadership. Code review catches join mistakes and definition errors that produce plausible but wrong numbers, and it teaches the team's conventions faster than documentation.
How do I judge a data analyst whose analysis did not change anything?
Look at whether the question was worth answering and whether the analyst framed the answer around a decision. A sound analysis that nobody acted on is often a stakeholder or scoping problem, which is partly the manager's to fix, but an analyst who never asks what decision the work supports needs coaching on that.
Does this plan work for analytics engineers or data scientists?
The first 30 days carry over. An analytics engineer's day 60 and 90 should center on models and tests in the transformation layer rather than analyses, and a data scientist's on a model or experiment taken from question to evaluation.