Bahasa Melayu

Path From Data Scientist to Senior DS and Lead: An 18-36 Month Map

You've been a data scientist for two or three years. Your notebooks are clean. Your AUC is up. You shipped the churn model that the VP of Growth still references in QBRs. Last cycle, two peers got promoted past you and the feedback came back as some version of "more impact" or "more ownership." You went home and read the rubric again. It didn't say anything new.

Here's what's actually happening: you're a model owner in a company that needs business-outcome owners, and the gap between those two jobs is wider than most ladders make it look. The people who level up in 18 to 36 months figured this out. The people who stall keep optimizing the thing that got them to mid-level in the first place (better models, cleaner code, sharper plots) and wonder why the rubric never seems to apply to them.

This guide is the map I wish I'd had when I was stuck at DS. What changes at Senior. What changes at Lead. What capabilities you actually need to build between bands. And the comp deltas, because pretending money isn't part of this is one of the more annoying lies the industry tells.

Why this matters now (and why waiting is expensive)

The comp gap between bands is real, and it's bigger than it was three years ago. A DS to Senior DS jump is typically $40-60K in total comp. Senior to Lead is another $50-90K. Compounded across the rest of your career, the cost of stalling for 18 extra months at one band is somewhere between "a down payment on a house" and "two of them."

The other thing that's expensive: waiting for promotion to happen to you. The "just do great work and you'll get noticed" narrative is, in my experience, mostly a coping mechanism for people who don't want to do the political work of asking. Promotion is a process. Processes have inputs. Most companies will not initiate that process for you because the manager who'd benefit from you staying mid-level is the same one writing your review.

The DSes who climb fast aren't necessarily smarter. They've decoded what each band rewards and they aim at it on purpose.

What changes at Senior DS

The DS job is "ship models against tickets." The Senior DS job is "be the ML point of contact for one business domain."

Concretely, here's what shifts:

You own a domain area. Pricing. Churn. Marketplace matching. Fraud. Forecasting. You pick one (or it picks you), and within six months you should know its business metric the way the GM does. If you're the pricing DS and you can't tell me what last quarter's net price realization was, you're not actually the pricing DS yet, you're just a DS who works on pricing tickets.

You mentor at least one IC. Not "answer questions in Slack." Mentor. Take a junior DS through one project end-to-end, including the parts that are hard to write down: when to push back on a PM, how to tell if a model is too hard to be worth it, how to read a stakeholder's room.

You're in PM planning, not just receiving tickets. Senior DSes show up in roadmap meetings. They argue for ML projects, against ML projects, and for non-ML solutions when ML is the wrong tool. If your ML work is being scoped without you in the room, you're working at DS level no matter what your title says.

You write the spec, not just the code. A model spec answers the questions a PM and a VP will ask before the model exists: what's the business metric, what's the kill criteria, what's the worst-case decision the model could make, what's the rollback plan. You write it. You defend it. You revise it. The code follows.

When I went from DS to Senior, the first thing that broke was my standup updates. They were still about model metrics. My new manager pulled me aside and said, gently, "I don't need to hear about AUC. Tell me what changed for the business this week." That was the entire promotion in one sentence.

What changes at Lead DS

The Senior DS job is "own a domain." The Lead DS job is mostly not modeling at all. This is the part nobody tells you, and it's where a lot of strong Senior DSes either bounce off the role or grind into burnout pretending they can do both.

You own a 6-12 month ML roadmap. Quarterly outcomes, prioritized bets, kill dates. You write it, you sell it to the VP, and you live with the bets that fail. You will defend dead projects in front of finance. Get used to it.

You manage 2-4 DSes. 1:1s every week, performance reviews, PIPs when they're warranted, hiring loops. The first time you have to give a Senior DS a "needs improvement" rating, you'll understand why management is not just IC work plus extra meetings.

You defend headcount and tooling budget. You will spend whole afternoons in front of a finance partner explaining why the team needs another DS, why the feature store can't be a Postgres table, why the GPU bill went up. You will lose some of these arguments. Your team will watch how you take the loss.

You translate exec strategy into ML bets. When the CEO says "we need to be AI-first by Q3," that's a statement, not a plan. You turn it into three concrete bets, each with kill criteria, each with a Senior DS who owns it. Then you protect those bets from the dozen drive-by requests that will hit your team between now and Q3.

The honest truth: when I went from Senior to Lead, the first thing that broke was my laptop, because I stopped opening my IDE and the auto-update queue piled up for three weeks. If you got into data science because you love modeling, the Lead job will feel like a bait-and-switch. If you got into it because you love watching data make a business move, the Lead job is the one where you actually get to do that.

The four capabilities you build between bands

Titles are an output. The input is capability. These four are the ones that, in my experience, every promotion committee actually evaluates, even when the rubric doesn't list them this clearly.

1. Problem framing

Turning "we want to use ML for X" into a measurable, scoped, killable project. This includes the most important skill of all, which is knowing when not to use ML. A Senior DS who tells the VP, "we don't need a model for this, a sorted dashboard solves 80% of it for free," will be remembered. A Senior DS who quietly builds the model anyway because it was on the roadmap will not.

The artifact: a one-pager with the business metric, the baseline, the target, the kill criteria, and a "what we're explicitly not solving" section.

2. Productization

Shipping a model that survives a year in prod. This means monitoring, retraining triggers, drift detection, an on-call rotation that includes you, a rollback path, and a postmortem template you've actually used. A model that wins offline and dies in prod is not a Senior DS deliverable, it's a science fair project.

The artifact: a "model in production" doc that an oncall engineer who isn't on your team can use at 2 a.m. to decide whether to roll back.

3. Exec narrative

Explaining a model's business impact to a non-technical VP in three slides, with a number they trust. The number is the hard part. "We saw a 4% lift" is not trustworthy. "We saw a 4% lift in this segment, here's the holdout, here's the dollar value at current volume, here's the assumption we're making about cannibalization" is trustworthy. The exec narrative is where most strong Senior DSes look like Lead DSes early.

The artifact: a three-slide template — what we did, what changed, what we recommend next — that you can fill in for any project in 30 minutes.

4. Hiring

Writing a JD, running a loop, calibrating a panel, closing a candidate against a competing offer. You don't need to manage to do this. Senior DSes who can run a hiring loop are noticed; Senior DSes who can't are stuck. By the time you're competing for Lead, you should have already closed at least one candidate. (If you need a starting point for the JD, the Data Scientist Job Description Template is the companion piece to this guide.)

The artifact: a debrief doc you can run from, with calibrated rubrics for each interview stage and a "what would change my mind" question for the final round.

Comp reality (US, 2026 ranges)

Real numbers, not "competitive comp" hand-waving. These reflect mid-market to large tech employers in the US, base + bonus + new-hire equity, vested annually.

Band Base Total comp
Data Scientist $130-180K $150-220K
Senior Data Scientist $170-230K $210-310K
Lead Data Scientist $200-280K $260-400K

A few things that move these numbers:

  • FAANG-tier public companies: add 30-40% in equity at Senior and above. Lead DS at one of those can clear $500K total in a good stock year.
  • Series B/C startups: usually 10-15% lower base, equity is the lottery ticket. Don't take the lottery ticket as cash. Underwrite it at zero and decide if the cash alone is acceptable.
  • Geo: these are SF/NYC/Seattle anchors. Most major US cities are now within 5-10% of these. Fully remote companies tend to anchor to a national average that's 10-15% below.
  • Movement since 2024: ranges are up 8-12% across the board. If your last benchmark was levels.fyi from 2024, your number is stale.

If you're benchmarking against an offer right now, the gap between the bottom of the Senior band and the top of the DS band is the negotiation zone. Most companies will fight you on it. Most candidates fold. Don't.

The model-tinkerer trap

This is the single most common reason mid-level DSes stall, and it's worth naming directly because the symptoms are subtle.

You're in the trap if:

  • Your standup updates are about model metrics, not business metrics.
  • Your manager forwards exec questions to you instead of trusting your answer.
  • You haven't talked to a PM unprompted in the last month.
  • You can name your model's AUC but not the dollar value of a 1% lift on the metric it serves.
  • You spend evenings reading papers but can't remember the last time you read a finance memo from your CFO.
  • The phrase "but the model is better" appears in your performance self-review.

Climbing out is straightforward, just not easy:

  1. Pick one business metric. Just one. Net revenue retention, gross margin, take rate, bad-debt ratio. Pick the one closest to your current work.
  2. Spend two weeks talking to the people who own it. PM, GM, finance partner. Ask what moves it, what's tried to move it before, what they'd kill to move it.
  3. Write a one-page kill-criteria doc proposing what your team could ship against that metric and what would mean it didn't work.
  4. Present it to your skip-level. Not your manager. Your skip-level. (Tell your manager first. Don't ambush them.)
  5. Ship against it.

The first time you do this, it will feel like you're skipping the line. You're not. You're just doing the work the next band was always going to ask you for.

The 18-36 month plan

A real timeline, not a fantasy one. Compress where you can; don't pretend you're compressing when you're skipping.

Months 0-6: Pick your domain. Get fluent in its business metric. Read every postmortem and project doc tied to it. Stop volunteering for "interesting" model work outside your domain. It's the most expensive form of distraction at this band.

Months 6-12: Own one prod model end-to-end. From spec to monitoring to the postmortem when it breaks (and it will break). Mentor one new DS through their first ship. (First ML Model in Production: A Survival Guide is a useful companion here.)

Months 12-18: Run a hiring loop. Present model results to a VP unaccompanied by your manager. Then ask for the Senior DS title with evidence: the spec, the model in prod, the mentee's promo, the VP-facing deck.

Months 18-24: As Senior DS, write the team's roadmap proposal even if no one asked. It will get edited or ignored the first time. Write the next one anyway. Roadmap-writing is the most visible Lead-track signal at this band.

Months 24-36: Manage one or two DSes informally, then formally. Defend a budget line. Take the Lead title, and if your company doesn't have one, the next move is to leave for one that does, with a clean Lead offer, not a "Senior DS but we'll consider Lead later" promise.

Common pitfalls

Treating Lead DS as "Senior DS plus two years." It's a different job. Mostly not coding. If you don't want that job, that's information, not failure.

Chasing the IC track at companies that don't actually have one. A lot of companies will tell you they have a Principal/Staff DS track. Far fewer have actually promoted someone to it in the last 18 months. Ask for examples by name. If they can't give you any, it doesn't exist for you.

Staying at a company that caps DS at Senior to avoid management overhead. This is a real pattern at Series B startups. The "we'll figure out a Lead role when we need it" line means there isn't one. You can wait, or you can leave.

Benchmarking comp against last year's levels.fyi. Ranges have moved 8-12% since 2024. Your number is older than you think.

Confusing modeling skill with seniority. I know Senior DSes who are weaker modelers than the DSes they manage. They got promoted because they framed problems better, shipped more reliably, and wrote things down. Those are the inputs the rubric actually rewards.

A note on the IC track

If you love modeling and you're good at it, the most honest career move may be staying Senior DS at a company with a real IC ladder, and that's a strategy, not a failure. Lead, Staff, Principal, and Distinguished DS roles exist at companies that take ML seriously, and the comp at the top of those ladders matches or beats the management track. The trap is staying Senior at a company that quietly caps you there, not the IC track itself. Pick the company first, the title second.

Measuring success

You're tracking right when:

  • You can name the business metric your work moves and the dollar value of a 1% lift.
  • Your PM brings you problems before solutions, not tickets after them.
  • You've mentored at least one DS through a real ship in the last six months.
  • You've been in a hiring loop in the last quarter.
  • Your skip-level knows your name and what you're working on without your manager prompting them.

If most of those are true, you're already operating at the next band. The title is paperwork.

Learn more