Career ladder template

Data analyst career ladder template

Five levels from Junior to Principal Analyst, across seven competencies from framing questions to changing decisions.

Free plan · No credit card required

This career ladder is written for companies of roughly 20 to 200 people where analysts sit close to the business: a handful of analysts, sometimes only one, answer questions from product, marketing, sales and leadership, often on a data stack they also help to build. It describes five levels, from someone learning to write reliable queries to someone who decides how the whole company measures itself. Its top level, Principal Data Analyst, is an individual-contributor level; leading the analytics team is a separate job.

Each level is defined by what an analyst does and how far their work reaches, not by the tools they know or their years of experience. Read a row of the competency matrix from left to right to see one expectation grow; read a level's section to see everything expected at that level. Use it to explain what the next level means, to run self-assessments and check-ins, and to make promotion cases comparable.

Adapt it before you publish it. Replace the generic wording with your own stack and your own metrics, drop the levels you do not need yet, and decide where analytics engineering ends and analysis begins at your company.

The levels at a glance

Junior Data Analyst
Answers well-defined questions with reliable queries and clear charts, with review from a more experienced analyst.
Scope
Individual requests and recurring reports for one team, usually scoped by someone else.
Data Analyst
Owns analyses end to end, from a vague question to a recommendation, and is the go-to analyst for one area.
Scope
One business area, such as onboarding, pricing or the sales funnel, and its dashboards and recurring questions.
Senior Data Analyst
Leads the analyses behind important decisions and raises the quality of analysis around them.
Scope
Several business areas or one major company initiative, and the metric definitions they depend on.
Lead Data Analyst
Shapes how the company uses data across functions and sets the standards other analysts work to.
Scope
Analytics across several functions, including shared metrics, data models and the analytics roadmap.
Principal Data Analyst
Decides how the company measures itself and answers for the trust leadership places in its numbers.
Scope
The company's core metrics, its approach to experimentation and analytics strategy for the next few years.

Competency matrix

Each row is a competency and each column a level. Read a row from left to right to see how the expectation grows.

What each competency means

Problem framing: Turning a stakeholder's question into one that data can answer and a decision can follow from.
Querying and data modelling: Getting correct data out of the warehouse and shaping it so that others can reuse it.
Statistical rigour and experimentation: Drawing conclusions that hold up, and knowing how sure the company can be about them.
Data quality and metric definitions: Making sure the numbers are right, mean the same thing everywhere and are trusted.
Communicating insights: Explaining what the data says so that people understand it and act on it.
Business impact and partnership: Understanding how the business works and making sure analysis changes what people do.
Mentoring and team growth: Helping other analysts and data users improve, and making the team stronger.

Data Analyst: expectations by competency and level
Competency	Junior Data Analyst	Data Analyst	Senior Data Analyst	Lead Data Analyst	Principal Data Analyst
Problem framing	Restates each request in writing before starting, confirms the time period, segment and definition being asked about, and asks what decision the answer will inform.	Turns vague questions such as “why is churn up?” into a short analysis plan with hypotheses, and pushes back when a request would not change any decision.	Reframes stakeholders' questions around the decision that actually needs making, and proposes analyses nobody asked for when they would change a priority.	Sets the analytics agenda with function leads each quarter, choosing the few questions most worth answering and explaining what will not be analysed and why.	Identifies the questions the leadership team should be asking about the business, and makes sure the company has the data to answer them before they become urgent.
Querying and data modelling	Writes readable SQL with joins, aggregations and window functions, checks row counts and duplicates before trusting a result, and asks for review on unfamiliar tables.	Knows the tables in their area and their quirks, builds reusable models or views instead of copying queries, and documents the logic behind each dashboard they own.	Designs the data models for a business area so that common questions need simple queries, reviews other analysts' logic, and works with engineers to fix tracking at the source.	Defines modelling conventions across the analytics codebase, decides what belongs in shared models versus one-off analysis, and plans the work to retire fragile pipelines.	Shapes the overall data architecture with engineering leadership, choosing where analytics should invest so that the most important questions stay cheap and fast to answer.
Statistical rigour and experimentation	Compares like with like, notes sample sizes and seasonality in every result, and flags when a difference might be noise rather than presenting it as a finding.	Analyses A/B tests from start to finish, including sample size, run time and guardrail metrics, and explains confidence and uncertainty in plain words.	Chooses a defensible method when a randomised test is impossible — difference-in-differences against a comparable segment, an interrupted time series or a matched comparison — and states its assumptions and limits openly.	Sets the company's experimentation standards — when to test, how long to run, how to call a result — and reviews high-stakes analyses before they reach leadership.	Decides how the company handles evidence in its biggest decisions, balancing rigour against speed, and is the final reviewer for analyses that change strategy.
Data quality and metric definitions	Reconciles new numbers against an existing source before sharing them, and reports broken data or suspicious drops to the owner on the same day.	Owns the accuracy of the dashboards in their area, adds simple checks that catch broken data before stakeholders do, and writes down every metric definition they introduce.	Resolves conflicting versions of the same metric between teams, agrees one definition with the people who use it, and retires the reports that contradict it.	Runs the company's metric catalogue and the process for changing a definition, and makes data incidents visible with an owner and a fix.	Answers for the trustworthiness of the numbers reported to leadership, investors or the board, and builds the controls that keep them consistent as the company grows.
Communicating insights	Presents results with a clear chart, a one-line takeaway and the caveats that matter, and keeps dashboards labelled so that others can read them without help.	Writes short analysis summaries that lead with the answer and the recommendation, adjusts detail to the audience, and builds dashboards that answer a specific set of questions.	Tells the story behind complex analyses to senior stakeholders, handles challenges to the numbers calmly, and turns findings into proposals the team can act on.	Presents to leadership regularly, sets the standard for how analyses are written up across the company, and makes sure important findings reach everyone they affect.	Shapes how the company talks about its performance, from leadership reviews to investor updates, so that everyone reads the same numbers the same way.
Business impact and partnership	Learns how the team they support makes money or delivers value, and follows up after a request to find out whether the answer was used.	Is a trusted partner for one team, joins its planning, and can name decisions in the last quarter that changed because of their work.	Influences priorities across several teams, connects analyses to revenue, cost or retention, and stops work that is no longer worth doing.	Partners with function leads on goals and targets, and makes sure analytics capacity goes where it will change the most important decisions.	Works with the leadership team on strategy and planning, and can point to company-level decisions in the last year — pricing, market entry, major investments — that changed because of analytics work.
Mentoring and team growth	Asks for feedback on their queries and write-ups, applies it, and shares useful tricks and gotchas with the team.	Reviews other analysts' work with specific comments, helps new joiners learn the data in their area, and answers colleagues' data questions patiently.	Mentors junior analysts, runs code and analysis reviews, and teaches non-analysts to answer simple questions themselves with self-serve tools.	Grows several analysts towards the next level, shapes hiring and interviews for the analytics team, and builds the onboarding and documentation new analysts rely on.	Builds the company's data culture, develops future analytics leaders and makes the case for how the data team should be structured as the company grows.

Scroll the table sideways to see every level.

Download as CSV Opens in Excel, Google Sheets or Numbers.

Junior Data Analyst: what is expected

Answers well-defined questions with reliable queries and clear charts, with review from a more experienced analyst. Individual requests and recurring reports for one team, usually scoped by someone else.

Problem framing: Restates each request in writing before starting, confirms the time period, segment and definition being asked about, and asks what decision the answer will inform.
Querying and data modelling: Writes readable SQL with joins, aggregations and window functions, checks row counts and duplicates before trusting a result, and asks for review on unfamiliar tables.
Statistical rigour and experimentation: Compares like with like, notes sample sizes and seasonality in every result, and flags when a difference might be noise rather than presenting it as a finding.
Data quality and metric definitions: Reconciles new numbers against an existing source before sharing them, and reports broken data or suspicious drops to the owner on the same day.
Communicating insights: Presents results with a clear chart, a one-line takeaway and the caveats that matter, and keeps dashboards labelled so that others can read them without help.
Business impact and partnership: Learns how the team they support makes money or delivers value, and follows up after a request to find out whether the answer was used.
Mentoring and team growth: Asks for feedback on their queries and write-ups, applies it, and shares useful tricks and gotchas with the team.

Data Analyst: what is expected

Owns analyses end to end, from a vague question to a recommendation, and is the go-to analyst for one area. One business area, such as onboarding, pricing or the sales funnel, and its dashboards and recurring questions.

Problem framing: Turns vague questions such as “why is churn up?” into a short analysis plan with hypotheses, and pushes back when a request would not change any decision.
Querying and data modelling: Knows the tables in their area and their quirks, builds reusable models or views instead of copying queries, and documents the logic behind each dashboard they own.
Statistical rigour and experimentation: Analyses A/B tests from start to finish, including sample size, run time and guardrail metrics, and explains confidence and uncertainty in plain words.
Data quality and metric definitions: Owns the accuracy of the dashboards in their area, adds simple checks that catch broken data before stakeholders do, and writes down every metric definition they introduce.
Communicating insights: Writes short analysis summaries that lead with the answer and the recommendation, adjusts detail to the audience, and builds dashboards that answer a specific set of questions.
Business impact and partnership: Is a trusted partner for one team, joins its planning, and can name decisions in the last quarter that changed because of their work.
Mentoring and team growth: Reviews other analysts' work with specific comments, helps new joiners learn the data in their area, and answers colleagues' data questions patiently.

Senior Data Analyst: what is expected

Leads the analyses behind important decisions and raises the quality of analysis around them. Several business areas or one major company initiative, and the metric definitions they depend on.

Problem framing: Reframes stakeholders' questions around the decision that actually needs making, and proposes analyses nobody asked for when they would change a priority.
Querying and data modelling: Designs the data models for a business area so that common questions need simple queries, reviews other analysts' logic, and works with engineers to fix tracking at the source.
Statistical rigour and experimentation: Chooses a defensible method when a randomised test is impossible — difference-in-differences against a comparable segment, an interrupted time series or a matched comparison — and states its assumptions and limits openly.
Data quality and metric definitions: Resolves conflicting versions of the same metric between teams, agrees one definition with the people who use it, and retires the reports that contradict it.
Communicating insights: Tells the story behind complex analyses to senior stakeholders, handles challenges to the numbers calmly, and turns findings into proposals the team can act on.
Business impact and partnership: Influences priorities across several teams, connects analyses to revenue, cost or retention, and stops work that is no longer worth doing.
Mentoring and team growth: Mentors junior analysts, runs code and analysis reviews, and teaches non-analysts to answer simple questions themselves with self-serve tools.

Lead Data Analyst: what is expected

Shapes how the company uses data across functions and sets the standards other analysts work to. Analytics across several functions, including shared metrics, data models and the analytics roadmap.

Problem framing: Sets the analytics agenda with function leads each quarter, choosing the few questions most worth answering and explaining what will not be analysed and why.
Querying and data modelling: Defines modelling conventions across the analytics codebase, decides what belongs in shared models versus one-off analysis, and plans the work to retire fragile pipelines.
Statistical rigour and experimentation: Sets the company's experimentation standards — when to test, how long to run, how to call a result — and reviews high-stakes analyses before they reach leadership.
Data quality and metric definitions: Runs the company's metric catalogue and the process for changing a definition, and makes data incidents visible with an owner and a fix.
Communicating insights: Presents to leadership regularly, sets the standard for how analyses are written up across the company, and makes sure important findings reach everyone they affect.
Business impact and partnership: Partners with function leads on goals and targets, and makes sure analytics capacity goes where it will change the most important decisions.
Mentoring and team growth: Grows several analysts towards the next level, shapes hiring and interviews for the analytics team, and builds the onboarding and documentation new analysts rely on.

Principal Data Analyst: what is expected

Decides how the company measures itself and answers for the trust leadership places in its numbers. The company's core metrics, its approach to experimentation and analytics strategy for the next few years.

Problem framing: Identifies the questions the leadership team should be asking about the business, and makes sure the company has the data to answer them before they become urgent.
Querying and data modelling: Shapes the overall data architecture with engineering leadership, choosing where analytics should invest so that the most important questions stay cheap and fast to answer.
Statistical rigour and experimentation: Decides how the company handles evidence in its biggest decisions, balancing rigour against speed, and is the final reviewer for analyses that change strategy.
Data quality and metric definitions: Answers for the trustworthiness of the numbers reported to leadership, investors or the board, and builds the controls that keep them consistent as the company grows.
Communicating insights: Shapes how the company talks about its performance, from leadership reviews to investor updates, so that everyone reads the same numbers the same way.
Business impact and partnership: Works with the leadership team on strategy and planning, and can point to company-level decisions in the last year — pricing, market entry, major investments — that changed because of analytics work.
Mentoring and team growth: Builds the company's data culture, develops future analytics leaders and makes the case for how the data team should be structured as the company grows.

How to adapt this ladder

Size it to your analytics team
With one or two analysts you probably need three levels, not five. Leave out Lead and Principal until someone is genuinely setting standards across functions, and add them when that work exists rather than as a reward. In most companies of this size the Principal scope belongs to a Head of Data or Analytics; use the level only if you want a senior IC alongside that person.
Decide where analytics engineering sits
If you have analytics engineers or data engineers who own the models, make the Querying and data modelling row lighter and the Problem framing row heavier. If your analysts own the whole stack, keep the row as it is and name your tools in it.
Reflect whether analysts are embedded or central
Embedded analysts are judged mostly by the decisions of the team they sit with; a central team is judged more by shared metrics and standards. Weight the Business impact and Data quality rows to match how your team is actually organised.
Collect evidence from real analyses
Ask analysts to link the write-ups, dashboards and models behind each claim in their self-assessment, plus the decision each one informed. It turns check-ins into a discussion of real work instead of a list of tools learned.

FAQ

Questions about this ladder

What is the difference between a data analyst and a data scientist on a career ladder?

A data analyst helps people make decisions by finding, checking and explaining what the data says. A data scientist mostly builds statistical or machine-learning models that become part of the product or of operations. In smaller companies the roles overlap, but they grow in different directions, so give them separate ladders or separate tracks. In some companies “data scientist” is simply the title for analysts who focus on experimentation.

How many levels should a data analyst career ladder have?

For a company of 20 to 200 people, three to five. Most small teams need Junior, Data Analyst and Senior; Lead and Principal only make sense once analytics serves several functions and someone is setting standards for all of them.

Does a senior data analyst need Python, or is SQL enough?

This ladder deliberately does not tie levels to languages. Many excellent senior analysts work mostly in SQL and a BI tool. What separates the levels is the quality of the questions, the rigour of the analysis and the decisions it changes — add a tool requirement only if your team truly cannot work without it.

How do you show a data analyst's impact when making a promotion case?

Point to decisions, not dashboards. For each competency of the target level, list two or three analyses with the question, the method, the recommendation and what happened next. A stakeholder confirming that a decision changed is stronger evidence than the number of reports built.

Can a data analyst keep growing without becoming head of analytics?

Yes. Lead and Principal are individual-contributor levels: they grow in scope and influence over how the company uses data, without managing people. Managing the analytics team is a separate job with its own ladder, and moving into it should be a change of track rather than the only way up.

Build this career ladder in LadderKit — free

Set up its levels and skills for your team, assess people against them in check-ins, and keep promotion decisions consistent.

Start free See the live demo No signup