Crash course / Foundations
What a data team is actually for
The job is not producing numbers. It is reducing the number of decisions that get made badly, and almost everything else follows from that.
Most people arrive at data work through a tool. They learn some SQL, or pandas, or a BI product, and then look for problems shaped like the tool. That works for about eighteen months, and then it stops, because the constraint stops being "can I compute this" and becomes "should anyone care".
So before the tooling, the frame.
The job is decision support, not number production#
A data team exists to make the organisation's decisions less wrong. That is the whole thing. Every artefact you produce — a table, a dashboard, a model, a one-line Slack answer — is only worth what it changes about a decision someone was going to make anyway.
This sounds obvious and it changes everything about how you work:
- A dashboard nobody opens is not a neutral outcome. It cost you two weeks and now it needs maintaining forever.
- An analysis that arrives after the decision was made has a value of exactly zero, no matter how good it is.
- A model that is 4% more accurate but that nobody trusts enough to act on is worth less than the crude one they use.
The four things people actually ask for#
Almost every request in this job is one of four questions wearing different clothes.
What happened? Descriptive. Revenue was down 6% last month. This is the easiest to compute and the easiest to get subtly wrong, because it depends entirely on definitions nobody wrote down.
Why did it happen? Diagnostic, and much harder than it looks. It is a causal question being asked casually. Most of the time the honest answer is "here are three things that moved at the same time, and here is how we could tell them apart".
What will happen? Predictive. Forecasting, propensity, risk. This is where models live, and where the gap between an offline metric and a business outcome is widest.
What should we do? Prescriptive. The hardest and the most valuable. It requires the previous three plus an understanding of what the organisation can actually act on.
Notice that the difficulty ordering is also, roughly, the value ordering — and that most junior work sits entirely in the first bucket. That is fine. The point is knowing which bucket you are in, because the standard of evidence differs enormously between them. A descriptive answer needs correct SQL. A causal answer needs a design.
The titles, briefly#
You will see these used inconsistently everywhere, including here. The rough shape:
| Title | Owns | Typical day |
|---|---|---|
| Data engineer | Getting data from where it is to where it can be used | Pipelines, schemas, orchestration, the 3am page |
| Analytics engineer | Turning raw tables into trustworthy models | Dimensional modelling, tests, documentation |
| Data analyst | Answering questions with the modelled data | SQL, charts, stakeholder conversations |
| Data scientist | Questions that need statistics or modelling | Experiments, models, causal inference |
| ML engineer | Models that run unattended in production | Serving, features, monitoring, retraining |
The boundaries are fake and they move by company. What matters is that the whole chain exists somewhere, and that you know which parts of it you are currently standing on. A great analysis on top of a broken pipeline is a broken analysis.
What you are optimising#
If you take one thing from this module, take this: your output is not analysis, it is trust. An organisation with a data team it trusts moves faster than one with a better data team it does not. Trust is built by being right, being consistent, saying "I do not know" out loud, and never — not once — quietly changing a definition without telling anyone.
The rest of this course is mostly mechanics in service of that.