Brag document template for data scientists
Data scientists are evaluated on decisions changed rather than analyses completed, and on whether their work survived contact with the people who had to act on it. This is what to capture so the impact is legible at review time.
What this role is judged on
- Decisions changed as a direct result of your analysis
- Rigor that held up under challenge, including stated uncertainty
- Durability of the data assets you built for others
- Translation of ambiguous business questions into answerable ones
- Models or metrics adopted into a recurring process
What this role is measured on
There is a hard line in this role between an analysis that ran and an analysis that changed something, and every evaluation conversation is really about which side of it your year sits on. A beautifully executed study that arrived after the decision was made, or that nobody could act on, counts for very little regardless of its technical quality. The unit of impact is the decision.
Rigor is the second axis, and it is judged by whether your work held up when someone pushed on it. Stating uncertainty honestly, running the sensitivity check nobody asked for, and being explicit about what your data cannot tell you all read as strength here, because the failure mode this role guards against is confident wrongness at scale.
Durable data assets are the third axis and the most undervalued. A cleaned, documented, trusted table that ten people now build on is a larger contribution than most one-off studies, and it compounds. So does a metric definition that ended an argument about whose number was right.
Question translation is the fourth. The business rarely arrives with an answerable question; it arrives with "why is retention bad". Turning that into a specific, tractable, falsifiable question is a substantial part of the work and is invisible in the final deliverable unless you narrate it.
Wins that read well for this role
- "Showed that
explained almost none of the variance in , redirecting away from a roadmap item that would not have worked." - "Built
now used by , replacing with one agreed definition." - "Shipped the model behind
, which changed and moved by ." - "Reframed
into , which was answerable in instead of the open-ended investigation originally scoped." - "Called out that the experiment was underpowered before launch and specified the sample needed, avoiding a result that would have been read as real."
Common undersell
The characteristic undersell in this role is describing method instead of consequence. A self-review that lists the models fitted, the pipelines built, and the dashboards produced is describing the inputs, and the reader has to do the work of inferring whether any of it mattered. Lead with the decision that changed and put the method underneath it.
The second undersell is invisible prevention. Stopping a bad launch, catching a broken metric before it drove a quarter of decisions, or refusing to over-claim from thin data all produce no artifact and are among the highest-value things you do. Write them down as counterfactuals: what would have happened otherwise, and how you know.
The third is treating enablement work as overhead. Every hour that other people no longer spend arguing about whose number is correct is your output, and it is worth stating with the number of people it applies to.
Capture each of these when the decision happens, while you still remember what the alternative was, and let the record build itself over the year.