Deutsch

Your First 30/60/90 Days as a New Data Analyst

It's 9:47 AM on day 3. You've barely figured out your VPN. A Slack message lands from someone whose name you don't recognize: "hey welcome! quick one — can you pull MRR by segment for the board deck tomorrow? just need it sliced by ARR band and acquisition channel. thx!"

How you answer that message decides your next 12 months.

If you say yes and run the query, you've just signed the contract. You are now the Ad-Hoc Pull Person. You will spend 40 hours a week on "quick ones" and ship zero strategic work. By day 91, when your manager asks what you accomplished, you'll have a Slack archive instead of a story.

If you say no, you're the new analyst who blocked the board deck. Also bad.

There's a third path. This guide is that path.

Why analysts need a 30/60/90 frame more than anyone else

Engineers get a backlog. PMs get a roadmap. Designers get a Figma file already in motion. Analysts walk into a job where every stakeholder thinks they're the priority, the previous analyst left no documentation, and the company TV is showing dashboards that haven't been touched in eight months. Half are wrong. Nobody knows which half.

Without a frame, you become a SQL vending machine. With one, you become someone who killed 30 broken dashboards, shipped one canonical revenue model, and walked into the H2 planning meeting with an analytics roadmap your VP hadn't asked for but suddenly needed.

The frame is simple: audit, then ship one thing, then own a metric. Three months. One job per month. Don't skip ahead.

Days 1-30: Audit, don't build

The biggest mistake I see new analysts make is opening a SQL editor on day 4 and trying to "fix" something. You don't know what's broken yet. You don't know what's load-bearing. You don't know which "broken" dashboard is actually the only thing the CFO trusts.

Month one is reconnaissance. You write almost no queries. You take a lot of notes.

Week 1: Dashboard inventory

Pull a list of every dashboard, report, and saved query in your BI tool (Looker, Mode, Tableau, Metabase, whatever you inherited). For each one, capture five fields:

  • Name
  • Owner (or "unknown")
  • Last view count (last 60 days)
  • Last edit date
  • Status (live / suspect / dead)

Dead means: zero views in 60 days, OR last-edited by someone who left the company more than six months ago. In a typical mid-size SaaS, you'll find 60-70% of dashboards are dead. At my last company we had 312 dashboards. After the audit, 47 were actually used. The rest were ghost ships.

Don't delete anything yet. Just list them.

Week 2: Schema tour and the canonical revenue fight

Now you read. Open the dbt repo (or your warehouse if there's no dbt). Find the five tables you'll touch every week (usually some flavor of accounts, subscriptions, events, users, and one revenue table). Read the model definitions. Read the column comments. Read the macros.

You will, with statistical certainty, discover that your company has multiple definitions of revenue. At one company I worked at, we had 14 versions of revenue living in the warehouse. ARR booked. ARR billed. ARR forecast. Net new ARR. Gross retained ARR. Each one was correct for some purpose and wrong for another. Finance used one. Sales used another. The CEO had a Google Sheet with a third.

This is normal. It is also your most important week-2 task. Pick a meeting with your finance counterpart. Ask: "Which of these is the source of truth for the board?" Get an answer in writing. Not a Slack message, a doc. That conversation is the foundation everything else rests on.

If finance can't tell you, that's a finding. Note it.

Week 3: Stakeholder syncs (listen, don't pitch)

Sit in on five meetings: revenue ops, customer success, marketing, product, finance. You are not there to present. You are not there to "introduce yourself." You are there to listen for the recurring questions.

The pattern you're looking for: the same question asked by three different teams in three different ways. That's your week-5 dashboard.

Examples of what I've heard in week-3 syncs:

  • RevOps lead: "We never know which segment our pipeline is actually concentrated in."
  • CS director: "I wish I could see expansion ARR by industry without exporting to a sheet."
  • CMO: "Marketing-sourced pipeline by segment is in five different places."

That's the same question three times. That's the dashboard you build in month two.

Bring a notebook. Don't open your laptop. Don't volunteer to "pull something quick." When asked, say: "I'm in audit mode for the next two weeks. Let's add it to the intake form once it's live." (More on the intake form in a minute.)

Week 4: The kill list

Now you propose deprecating the dead dashboards. This is where new analysts get scared and skip ahead. Don't.

Go back to your inventory. For each dead dashboard, find the original creator (or the team it lived on) and ask: "This hasn't been viewed in X days. Are you OK with me archiving it?" 80% of the time the answer is "oh god yes, I forgot it existed." 15% of the time the answer is "actually keep it, I use it monthly." 5% of the time you'll learn something important about the business.

Get sign-off in writing. A Slack thread is fine. Then archive, don't delete. Most BI tools let you archive with a one-click restore. You want a paper trail.

Here's the script that worked for me:

Hey [name], I'm doing a dashboard cleanup as part of onboarding. The "[dashboard name]" hasn't had a view in 73 days and was last edited by [person who left]. I'd like to archive it (reversible, not deleting). OK with you? If you'd rather keep it, no problem, just want to confirm someone owns it.

Send this in batches of 10. Do not chase responses. Silence after 5 business days = archive. Document everything.

By the end of week 4, you've usually killed 40-150 dashboards. That's your first deliverable. It's also the only deliverable you'll get to claim that didn't require a single line of SQL, which is exactly the point.

Days 31-60: Ship one thing, set the SLA

Month two is where the work shows up. But you only get to do three things. Ship one dashboard. Publish an SLA. Build one dbt model. That's it. Resist the urge to do more.

Ship the one dashboard everyone asked for

Remember the question from week 3 that three teams asked? Build that dashboard. Just that one.

The discipline here is brutal. People will ask for "while you're at it, can you also add…" and the answer is no. Not because their request is bad, but because every "while you're at it" turns into the Ad-Hoc Pull Person trap with extra steps. Ship the one thing. Make it good. Ship it.

A "good" first dashboard means:

  • One question, answered clearly. Not five questions.
  • The metric definition is the canonical one you fought about in week 2, and the dashboard footer says so. ("Revenue defined per [link to dbt model]. Last reviewed with Finance on [date].")
  • Three filters max. Segment, date range, one team-specific cut.
  • A one-paragraph "How to read this" at the top.
  • An owner (you) and a "questions?" Slack channel.

That last bullet is non-negotiable. Every dashboard without an owner becomes a ghost ship in 18 months. You're going to be the analyst who breaks that pattern.

Publish the ad-hoc SLA

This is the moment you stop being a SQL vending machine. You publish a single page (a Notion doc, a Confluence page, whatever your company uses) that says:

Ad-hoc data requests intake

  1. Submit via [form / #data-requests channel]. Slack DMs to me will get redirected here.
  2. Three required fields: what you need, when you need it, what decision it informs.
  3. SLA: requests under 4 hours of work, same day or next morning. Requests over 4 hours, triaged into next sprint.
  4. Anything tagged "board deck" or "exec review" gets bumped to the front of the queue.

Three required fields. Not seven. Not a 14-question intake form. The third field (what decision it informs) is the one that does the magic. Half the requests die on it because the requester realizes they don't actually need the data, they were just curious. The other half come in tighter because the requester had to think first.

Get your manager to send the announcement, not you. "Hi team, [your name] is now owning analytics intake. Please use the form going forward." That sentence is worth a hundred Slack DMs you don't have to absorb.

The SLA isn't about saying no. It's about making "next sprint" a normal answer instead of a fight.

Build one dbt model

The dbt model is the canonical revenue definition you fought about in week 2. Just that one. Not a metrics layer. Not a semantic refactor. One model.

Name it fct_revenue_canonical or whatever your repo's convention is. Write the documentation block. Add tests. Get it reviewed. Merge it. Update your week-5 dashboard to source from it.

This is your "I belong here" moment. The first time someone in a meeting says "wait, which revenue number are we using?" and a teammate answers "the canonical one, it's the dbt model [your name] shipped" — that's the moment you stop being the new analyst and start being the analyst.

Do not, under any circumstances, try to refactor the rest of the warehouse in month two. The graveyard of new analysts is paved with people who tried to "rebuild everything" in week 6 and broke a board report in week 8. Ship one model. Move on.

Days 61-90: Own a metric, pitch the plan

Month three is where you stop being measured by tickets closed and start being measured by what you own.

Adopt time-to-insight as your metric

Pick one team-level metric and own it. The strongest one for analysts is time-to-insight: median hours from "request submitted" to "data answer delivered." Some teams call it first-response-to-data-question. Same idea.

Measure it from your intake form (you have one now). Establish a baseline in week 9. Set a target for week 12. Mine was: median 6 hours, target under 4.

Why this metric and not, say, "dashboard adoption" or "queries run"? Because time-to-insight is the one your stakeholders feel. They don't notice when adoption goes up. They notice when their question gets answered before lunch instead of next Tuesday.

Report it weekly in your team's standup. Three numbers: median, p90, count. That's it.

The 90-day report

Around day 85, write your manager a one-page report. Four sections, in this order:

Killed. Number of dashboards archived, with a list. Total estimated load saved on the warehouse if you can measure it.

Shipped. The one dashboard. The one dbt model. The intake form with two months of throughput data.

Broken. What you found that's still wrong. Be specific. "The MRR-by-segment model double-counts trial conversions in the EMEA region. Affects 4 dashboards. Fix is a 1-week project." Don't soft-pedal. Your manager wants the list.

Next. Two strategic projects, one platform investment, one staffing ask if relevant. Concrete. With rough timelines.

One page. No more. Send it as a doc, then walk through it in your 1:1.

The H2 plan pitch

The 90-day report is the warm-up. The pitch is what comes next. In the same 1:1, you say: "I want to own the H2 analytics plan. Here's the rough shape: two strategic projects (X and Y), one platform investment (a metrics layer / reverse ETL / experimentation framework), and one staffing decision (do we hire a second IC or a senior to lead?). I'll have a full doc by [date]."

This is the moment that distinguishes the analyst who stays an IC for five years from the one who's running a team in 18 months. Most analysts wait for their manager to plan for them. You're going to plan for your manager.

You will get pushback. The plan will get edited. Two of your projects will get killed. That's fine. The pitch is the act, not the artifact.

The pitfalls (these will tempt you, don't fall in)

Saying yes to every ad-hoc in month 1. I said it at the top, I'll say it again. The ad-hoc treadmill is a one-way door. You say yes in week 1, you're still saying yes in year 2.

Rebuilding the warehouse in week 2. You don't understand the business yet. The "obviously broken" model is load-bearing for someone you haven't met. Audit first.

Going silent for 60 days, then dropping a 40-page audit. Nobody asked for the audit. They asked for evidence you exist. Ship the kill list in week 4. Publish the SLA in week 6. Show up.

Shipping a dashboard with the wrong revenue definition. You skipped the finance reconciliation in week 2. Now your dashboard contradicts the board deck. Trust burned. Hard to rebuild. Don't.

Templates you'll actually use

Dashboard inventory spreadsheet. Six columns: name, owner, last viewed (date), last edited (date), status (live/suspect/dead), kill-or-keep decision. One row per dashboard. Sort by last-viewed ascending, and the dead ones float to the top.

Stakeholder sync question list. Five questions, in order: (1) What decisions did you make last quarter that you wished you had better data for? (2) What number do you check every morning? (3) What dashboard do you actually use, vs. what dashboard exists for you? (4) What question do you keep getting from your boss that you can't answer fast? (5) If I could give you one new view into the business, what would it be? Notice none of them are "what do you need from me." That question gets you a wishlist. These questions get you the truth.

Ad-hoc intake form. Three fields. Request. Deadline. Decision it informs. That's it.

90-day report. One page. Killed. Shipped. Broken. Next. Bullets, not paragraphs.

What "successful" looks like at day 90

By day 90, the dashboard count in your BI tool is down, not up. There's one canonical dbt model for the metric your company used to fight about. Stakeholders use the intake form instead of DMing you. Your manager has a written H2 plan from you, not the other way around. And somewhere on the company TV, the dashboards still say the same number on a Tuesday as they do on a Friday.

You're not the Ad-Hoc Pull Person. You're the analyst.

That's the job.

Learn More