Data Analyst

The data analyst is the person who looks at what happened and makes it visible. Revenue went up — where? Customers left — which ones? A campaign ran — did it work? The work is translation: taking raw numbers from databases and turning them into charts, dashboards, and narrative explanations that people who do not speak SQL can use to make decisions. The primary pull is Revelation — the data already contains the answer; the analyst's job is to find it and make it legible.

Most of the daily work is not insight. It is query-writing, data cleaning, dashboard maintenance, and responding to stakeholder requests. The analyst who imagines the job is a series of revelatory discoveries will find that the ratio of revelation to plumbing is low. The satisfaction comes in a different register: the well-built dashboard that a team uses every morning without thinking about how it got there, the quarterly report that changed how an executive understood their business, the anomaly in the data that nobody else noticed. The work accumulates rather than arrives.

The analyst's relationship with stakeholders is the most important and least discussed dimension of the role. An analyst who can pull perfect data but cannot explain what it means to someone who does not think in numbers is not yet doing the full job. The communication layer — the slide, the narrative, the one-sentence summary that makes a VP nod — is where the Explanation gradient enters, and it is often the thing that determines career trajectory more than technical skill.

The gap between what "data analyst" sounds like and what the work actually involves is one of the widest in any entry-level knowledge-work role. The image is insight and discovery. The reality is that a large share of working hours go to data cleaning, pipeline debugging, and reconciling numbers that do not match across systems. Data quality issues — missing values, inconsistent formats, upstream changes that break your queries — are the texture of the work, and the ability to tolerate this without losing interest in the underlying question is what separates people who last in the role from those who don't.

The other thing nobody tells you is that your analysis can be technically correct and organisationally irrelevant. An analyst who produces a finding that challenges a decision already made is in a politically delicate position. The field's self-image emphasises data-driven decision-making; the operational reality is that decisions are often made first and the data is consulted afterward. The analysts who navigate this best are the ones who understand organisational context as well as they understand the data.

AI tools are compressing the entry-level end of this role. Natural-language-to-SQL, automated dashboarding, and AI-assisted data exploration are making it possible for non-analysts to do work that previously required a dedicated analyst. This does not eliminate the role, but it moves the value upward — toward interpretation, context, and the judgment about what questions to ask, which are harder to automate.

There is no single credentialing gate. Entry paths include quantitative undergraduate degrees (statistics, economics, mathematics, computer science), data analytics bootcamps, and self-taught portfolios. Many analysts enter from adjacent roles — business operations, finance, marketing — after picking up SQL and BI tools on the job. What employers consistently look for: SQL proficiency, comfort with a BI tool (Tableau, Looker, Power BI), basic statistical literacy, and the ability to communicate findings to non-technical audiences. A portfolio of projects matters more than a specific credential in most hiring contexts.