Analytics careers: facts, examples and trends

Job titles in analytics are close to meaningless across companies. The same title covers wildly different work depending on team size, industry, and how mature the data function is. Two people with identical titles at different employers may share almost no daily tasks.

So this page ignores titles and describes the work. If you can recognize which kind of work you want, you can read past whatever a posting calls it.

Note on pay: this page contains no salary figures, because any number here would be stale, unsourced, and geographically meaningless. Compensation varies by market, industry, company stage, and seniority band far more than by title. Get your numbers from postings that publish ranges in your own market, from recruiters who place in your specific segment, and from people doing the actual job at the kind of company you are targeting. For a description of duties and outlook built on a consistent method rather than on commentary, an occupational reference such as the entry for data scientists is a better starting point than any article.

What to take away

• Look down the "failure looks like" row before choosing.
• Postings are written by committee and describe a wish, not a job.
• Nobody is impressed by an analysis of a famous public dataset that thousands of people have already analyzed.
• The team is one person and the mandate covers infrastructure, modeling, analysis, and stakeholder management.

Five kinds of work behind the titles

Serving the business directly. You sit with a function (sales, marketing, product, operations, finance), and answer its questions. Most of your time goes to understanding what someone actually needs, finding whether the data can answer it, and explaining the result to someone who will not read your SQL. The technical work is real but rarely exotic. The differentiating skill is turning a vague request into a question with an answer, and then getting someone to act on it. If you dislike ambiguity or meetings, this is a hard fit.

Building the modeled layer. You take raw source tables and turn them into clean, tested, documented models that everyone else builds on. Your day is transformation code, tests, reviews, and conversations about what a field means. It is software engineering applied to data, with the review discipline that implies. The satisfaction is structural, you make other people's work faster, and the frustration is that your best work is invisible when it goes well.

Moving and keeping data. You own ingestion, storage, orchestration, and the infrastructure everything else runs on. More time in code and configuration, less in meetings, more on-call. Your failures are loud and time-sensitive. This work rewards people who like systems and can hold a distributed pipeline in their head.

Statistical and modeling work. Experiment design, causal questions, forecasting, segmentation, predictive models. Less of this exists than people expect, and in many companies it is a fraction of a job rather than a whole one. Where it is a whole job, most of the day is still data preparation and stakeholder alignment: the modeling itself is a minority of the time.

Building and maintaining the delivery layer. Dashboards, semantic models, self-service enablement, training people to find their own answers. It looks like tool work from outside and is mostly product work: understanding users, designing for how they actually behave, and retiring things.

Most real jobs are two or three of these mixed. Ask which mix during interviews, because the posting will not tell you.

What actually differs between them

Axis	Business-facing	Modeled layer	Infrastructure	Statistical	Delivery
Main input	A person's question	Someone else's raw tables	Source systems and schedules	A decision with uncertainty	A user's workflow
Main output	An answer someone acts on	Reliable models others build on	Data that arrives on time	An estimate with its limits	A view people use unaided
Feedback speed	Fast, you see the decision	Slow, quality shows up later	Immediate when it breaks	Slow, outcomes take time	Medium, usage tells you
Ambiguity level	High	Medium	Low to medium	High	Medium
Failure looks like	A confident wrong answer	Silent logic drift	An outage or missing data	A model nobody uses	A dashboard nobody opens
Skill that compounds	Framing and persuasion	Software discipline	Systems thinking	Statistical judgment	Product sense

Look down the "failure looks like" row before choosing. You will spend your career preventing that specific thing, so pick one whose prevention you find interesting rather than tedious.

Moving between them

These moves are common and each has a specific bridge.

Business-facing to modeled layer. The bridge is engineering practice, not SQL: you can already write SQL. Learn version control properly, get your work reviewed by an engineer, and start writing tests for the logic you already produce. Volunteer to move a piece of dashboard logic upstream into a shared model. That single project is the portfolio piece.

Modeled layer to infrastructure. The bridge is operational responsibility. Take on the orchestration for the models you own, then the on-call for them. Learn how the storage layer actually charges and performs. The transition is mostly about accepting pager duty and getting comfortable with failures that wake you up.

Business-facing to statistical work. The bridge is experiment design, which you can practice inside your current role. Design a proper holdout for something your team is about to launch, write the analysis plan before the data exists, and follow through when the result is inconvenient. Doing this once well is worth more than a course.

Anything to delivery. The bridge is user research. Watch people use what you built, in silence, without helping. Then rebuild it. Delivery work is judged on adoption, and adoption comes from that loop.

Individual contributor to management. This is a change of profession, not a promotion. Your output becomes other people's output; your day becomes hiring, prioritization, unblocking, and protecting the team from thrash. The tell for whether you will like it: do you get more satisfaction from a colleague's good week than from your own good analysis? Try it as a lead first if your company allows, and treat going back as a normal outcome rather than a failure.

Into the field from outside. People arriving from finance, operations, research, or support have a real advantage: they know a domain and its questions. The gap is technical fluency, and it is a smaller gap than the reverse. Start by being the person on your current team who answers data questions, then move.

How to read a posting

Postings are written by committee and describe a wish, not a job. Useful signals:

• A long tool list usually means nobody has decided what the role does. It may also mean one overloaded person is being replaced by a list.
• Both "build the data warehouse" and "partner with executives" means one person doing two jobs. Sometimes that is a great early-career opportunity; sometimes it is a role designed to fail.
• Vague seniority (no scope described, no mention of who the role works with), usually means the level is negotiable, which cuts both ways.
• Named business problems rather than named technologies is the best signal on a posting. It means someone knows what they want done.

Questions worth asking in an interview

These separate a functioning data team from a struggling one faster than anything on a company's careers page:

• "Walk me through the last analysis that changed a decision." If they cannot produce one, the function is decorative. The specificity of the answer tells you almost everything.
• "Who decides what I work on, and how does something get onto that list?" No answer means you will be a ticket queue.
• "What happens when a stakeholder disagrees with a number?" Listen for whether definitions and ownership exist, or whether it turns into a negotiation each time.
• "How much of the week goes to ad-hoc requests versus planned work?" Any split is workable; not knowing the split is not.
• "Who owns the data pipelines, and where does this role sit relative to them?" Determines whether you will spend your time analyzing or firefighting.
• "What does someone in this role do in their second year?" Reveals whether there is a growth path or a fixed slot.

Ask the same questions of two different interviewers. Divergent answers are more informative than either answer alone.

What to build if you are trying to move

Nobody is impressed by an analysis of a famous public dataset that thousands of people have already analyzed. What actually persuades:

• Work with a real stakeholder. Even unpaid, even small: a local organization, a team at your current employer, a project with a real decision attached. The evidence you want is "someone changed what they did because of this."
• Work you can explain end to end. Where the data came from, what you had to clean and why, what you decided not to conclude. Explaining the limits convinces experienced interviewers more than a good result does.
• Work in your target domain. Domain knowledge transfers between employers better than tool knowledge, and it is the thing a career-changer already has.

One project with real depth beats five tutorials. Interviewers probe for depth immediately, and breadth without it is obvious within two questions.

Signs a role is mis-scoped before you take it

• The team is one person and the mandate covers infrastructure, modeling, analysis, and stakeholder management. This is survivable and educational, but know that you are signing up for triage, not craft.
• Nobody can name the role's stakeholders.
• The role reports somewhere with no interest in the answers: data functions buried under a team that does not use data tend to starve.
• The previous person left quickly and nobody will say why.
• Success is defined as "build dashboards" rather than as anything that changes.

Related reading on this site

Certifications come up constantly in this conversation; see analytics certifications for how to judge whether one is worth your time. For the daily craft that most of these roles share, see data analysis. The technical grounding every one of these roles rests on is in analytics foundations, the function most of them sit inside is described in business intelligence, the tooling questions that dominate early careers are in buying analytics tooling, and the definitional work that senior roles gravitate toward is in data governance.

Common questions

Do I need a specific degree?

Teams vary enormously in how much they weight this, and the weight tends to drop as you accumulate demonstrable work. Quantitative research roles are the most likely to hold a formal expectation. Ask directly during a first conversation rather than guessing.

Is SQL still the core skill?

For everything except pure infrastructure work, yes: it is the common language across all of these roles. Depth in it, including window functions and query performance, pays back more than breadth across tools.

Should I specialize or stay general?

Generalists do well in small teams, where the variety is the job. Specialists do well in large ones, where the depth is the job. Neither is a permanent choice, and moving between company sizes is the most common way people switch.

How do I know when to leave?

When you have stopped learning and the constraint is the organization rather than your effort: no appetite for the questions you can answer, no path to more scope, no interest in changing either. Those conditions rarely improve by waiting.