How to Get Promoted in a Data Team

Getting promoted in a data team is less about working longer hours and more about producing evidence of a particular kind. Most promotion processes ask one question: is this person already doing the work of the next level? Understanding that changes what you work on and how you talk about it.

How a documented promotion process works

GitLab publishes its promotion process in its public handbook, and it is a useful model of how many companies think, whether they write it down or not (GitLab: promotions and transfers):

• Performance first. Promotions reflect current performance, not just potential. You should already be consistently operating at the level described for the next role.
• Time in role. Team members typically become eligible for the next level in their job family after twelve months in their current role.
• A written case. Every in-line promotion needs a promotion document that sets out the evidence.
• Self-ownership. Team members are encouraged to own their promotion document, working with their manager.

Two consequences follow. First, a promotion is mostly recognition of something that has already happened; you have to grow into the next level before the title arrives. Second, evidence has to be written down. Your manager argues your case to people who do not see your daily work.

What changes between levels

Job ladders describe each level, and reading yours is the single most useful step towards promotion. GitLab's public data science ladder, for example, moves from intermediate to senior, staff and principal, with experience expectations rising at each step (GitLab: data science job family). Across most data ladders, the shift from level to level follows the same pattern:

The common thread is scope: how big a problem you own, how much ambiguity you handle, and how many people your work affects.

Build the evidence

1. Agree the target

Ask your manager directly: "What would you need to see from me to make a strong case for the next level within a year?" Get specific examples, and write them down. Revisit them each quarter.

2. Work on things that matter to the business

Promotion cases are built on impact: a decision changed, revenue or cost affected, time saved, risk reduced. Choose and shape projects with a clear business result, and measure it.

3. Show the next level's behaviours

• Take ambiguous problems and turn them into clear plans.
• Influence without authority: persuade a product team to change a metric definition, or align two teams on a shared data source.
• Make others better: review work carefully, mentor a new joiner, write documentation people actually use.
• Improve the system, not just your own output: an automated check, a reusable model, a better process.

4. Keep an evidence log

Once a week, write two or three lines: what you did, the result, who it affected. When the promotion cycle arrives, you will have specific, dated examples rather than vague memories. This log becomes the core of your promotion document.

5. Make your work visible

Present results at team meetings, share short written summaries with stakeholders, and make sure people outside your team know what you delivered. Visibility is not self-promotion; it is how decision makers learn about your impact.

Writing the promotion case

Structure it against the next level's description:

1. Summary: in two or three sentences, why you are operating at the next level.
2. Impact: three to five examples with measurable results.
3. Scope and complexity: the hardest problems you owned and the ambiguity you handled.
4. Influence and leadership: mentoring, cross-team work, improvements to how the team works.
5. Feedback: short quotes from stakeholders or peers, with permission.

If the answer is "not yet"

A deferred promotion is common and not a verdict on your career. Ask for the specific gaps, in writing if possible, and agree what evidence would close them by the next cycle. Then treat those gaps as your plan for the next six months, review progress monthly with your manager, and keep adding to your evidence log. People who respond to a "not yet" with a clear plan and visible progress give themselves the best chance in the following cycle, and give their managers a much easier case to make.

Common blockers

• Invisible impact: great work that nobody outside your manager knows about.
• Only executing tasks: excellent delivery of what others defined, without shaping what gets done.
• No business link: technically impressive work that nobody uses.
• Waiting to be noticed instead of asking what the bar is.
• No room on the team. Sometimes the next level is not available where you are. Then the choice is between waiting, a lateral move, or a new employer; when to stay and when to switch can help.

For the full path from analyst to lead, see analyst to scientist to lead, and for the longer horizon, planning a 5-year career in data.

Skills that help analysts and scientists take on bigger scope are part of the Data Science course.

Sources

• Promotions and Transfers (The GitLab Handbook) — GitLab
• Data Science job family (GitLab Handbook) — GitLab