Career paths & upskilling

# Career paths and upskilling

In 2021, a mid-sized fintech in Amsterdam lost four of its seven senior data engineers inside a single quarter. Exit interviews revealed something uncomfortable: none of them left for money. They left because the company had spent eighteen months turning them into world-class Spark and dbt practitioners, and then offered them nowhere to go but "senior engineer, again." A competitor two tram stops away offered a staff-level track, a platform-lead role, and a clear line of sight to principal. The fintech had, in effect, run a free training academy for its rival.

This is the central risk of data talent that no compensation band alone can fix. Data skills compound fast and depreciate faster; the half-life of a specific tooling skill is now roughly two to three years. If your people's growth curve flattens before their skill curve does, they will find the growth elsewhere. Your job as CDO is to make sure the steepest part of their career happens inside your walls.

The twin-ladder architecture (and why most cdos get it wrong)

The default failure mode is treating management as the only promotion. A brilliant ML engineer gets "rewarded" with a team of six, stops writing code, discovers she hates one-on-ones, and either quietly disengages or leaves. You have simultaneously lost your best builder and gained a mediocre manager.

The fix, a dual-track ladder, is well known in software but chronically under-built in data organizations, because data teams are younger and their level definitions are fuzzier. Your task is to construct two parallel tracks that reach the same seniority, comp, and status, so that a Principal Data Scientist and a Director of Data Engineering are genuine peers, not a real leader and a consolation prize.

Here is the discipline most CDOs miss: the tracks must diverge on *scope of impact*, not on *headcount managed*. A common, defensible framing:

| Level | IC Track (impact via craft) | Management Track (impact via people) |

|-------|----------------------------|--------------------------------------|

| L4 | Senior, owns a system | Team Lead, owns a squad's delivery |

| L5 | Staff, owns a domain, sets patterns others follow | Manager, owns a team's health and roadmap |

| L6 | Principal, shifts the org's technical trajectory | Director, owns a function and its strategy |

| L7 | Distinguished, external authority, sets industry-facing direction | Sr. Director / VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.View full definition →, owns multi-team outcomes |

The operational test for each IC level is a single question: *"Whose work changes because this person exists?"* At Staff, the answer is a domain. At Principal, it's the whole data org. If you can't answer that question concretely for a candidate, they are not at that level, regardless of tenure or how much you fear losing them.

The reason data orgs botch this is calibration drift. Titles get handed out to counter offers, and within two years your "Staff" engineers span a two-level range of actual impact. Guard against this with written, behavior-anchored rubrics and a calibration committee that reviews every promotion across teams. The rubric should describe observable outcomes ("independently decomposed an ambiguous business problem into a modeling approach and defended the trade-offs to non-technical stakeholders"), not proficiencies ("knows XGBoost").

The specialist problem data introduces

Software career frameworks assume relatively fungible engineers. Data organizations don't have that luxury, an analytics engineer, an ML platform engineer, a data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.View full definition → specialist, and a research scientist have genuinely different value curves. Rather than forcing one rubric onto all of them, define role families with shared *level definitions* but *family-specific evidence*. The L5 bar is the same conceptual altitude for everyone; what an L5 analytics engineer does to clear it differs from what an L5 research scientist does. This lets someone move laterally across families without resetting their level, which is itself a retention tool, because it turns "I'm bored of pipelines" into an internal transfer instead of a resignation.

Skills mapping: from guesswork to a capability ledger

You cannot build upskilling on vibes. Most data leaders "know" their team's gaps anecdotally, which means they over-invest in whatever failed most recently and under-invest in slow-building strategic gaps. Replace this with a capability inventory: a living mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → of the skills your data strategy requires over the next 18 months, scored against what your team actually has.

Build it in three passes:

1. Derive required capabilities from strategy, not from job titles. If your roadmap includes real-time feature serving and you have zero streaming expertise, that gap is now a line item, regardless of what your current org chart says people do.

2. Assess current state honestly. Self-assessment inflates; manager assessment is biased by recency. The most reliable signal is *demonstrated* work, who has actually shipped the thing, supplemented by peer input.

3. Compute the gap and its risk. A gap that only one person can currently cover is a *bus-factor* risk, not just a skills gap. These deserve priority because they threaten both delivery and retention (that one person knows they're irreplaceable and will eventually leverage it).

A lightweight structured version keeps this honest and lets you track movement over time:

capability: streaming_feature_pipelines
strategic_priority: high        # tied to Q3 real-time personalization initiative
required_by: 2025-09
current_coverage:
  proficient: 1                 # bus-factor risk: single point of failure
  working: 2
  none: 8
gap_type: depth_and_breadth
mitigation:
  - internal_cohort_training    # build breadth
  - external_hire_senior        # de-risk the single point of failure
  - project_based_stretch       # 2 "working" -> "proficient" via live project

The output of this exercise is a portfolio decision, not a training wishlist. For each gap you choose among build (upskill existing people), buy (hire), or borrow (contractors/partners for transient needs). The judgement: *buy for capabilities you lack entirely and need fast; build for capabilities that are strategic and durable; borrow for capabilities that are urgent but temporary.* Building the durable ones internally is also your strongest retention lever, because it visibly signals investment in people's futures.

Upskilling that actually changes behavior

Here is the brutal truth about corporate training: the standard playbook, buy licenses to an online course platform, announce it in an all-hands, celebrate the completion rate, produces almost no capability change. Completion is not competence. People finish videos and forget them within weeks because there is no forcing function to apply the skill.

Effective upskilling is engineered around application under real stakes. The strongest mechanisms, in rough order of impact:

Project-based stretch assignments. The single most powerful growth lever is deliberately assigning someone slightly beyond their current level, with a senior person as a safety net. This is how "working proficiency" becomes "proficient" in the ledger above. The CDO's role is to protect the space for productive failure, if a stretch assignment failing gets someone punished, no one will ever take one again.

Internal cohorts over individual courses. When five engineers learn streaming together, over six weeks, applying it to an actual internal problem, they build both the skill and a peer network that persists. Cohorts also create internal experts who then teach the next cohort, a compounding effect a course license never delivers.

Guilds and internal mobility. A "modeling guild" or "data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → guild" that meets biweekly to share patterns spreads tacit knowledge that no curriculum captures. Pair this with a genuine internal transfer policy: people should be able to move between teams to acquire new skills without it being treated as disloyalty. Google's 20% time is the famous version; the durable principle is *sanctioned exploration*.

The 70-20-10 allocation as a budgeting discipline. Roughly 70% of growth from on-the-job work, 20% from others (mentoring, coaching, reviews), 10% from formal training. Most training budgets invert this, pouring money into the 10% and neglecting the 70%. When you review your L&D spend, ask whether it's actually buying the 70, or just the 10 with a nice dashboard.

Make growth legible and measurable

Growth that isn't visible doesn't retain anyone. Two practical instruments:

• Individual growth plans tied to the ladder, reviewed quarterly, that name the *specific* next-level behaviors the person is working toward and the *specific* work that will demonstrate them. Vague development plans ("improve communication") are worthless; anchored ones ("lead the design review for the migration, present trade-offs to the steering group") are actionable.
• A leading indicator you actually track: internal promotion rate and internal mobility rate. If nearly all your senior hires come from outside, your career paths are broken regardless of what the framework document says. A healthy data org fills a meaningful share of senior roles internally, that ratio is your career-path system's report card.

Retention economics: the case you make to the CFO

None of this survives a budget cycle unless you can defend it in the language of the finance function. The argument is not "training is good." The argument is that the fully-loaded cost of replacing a senior data engineer, recruiting fees, months of vacancy, ramp time to productivity, and the delivery slippage in between, commonly runs to 1.5-2x their annual salary, before you count the lost institutional knowledge and the morale hit to those who stay. Against that, an upskilling and career-path investment of a fraction of one salary per head is straightforward arithmetic.

Frame it as a portfolio hedge, not a perk. Every capability you build internally reduces your dependence on a brutal external hiring market where you compete with Big Tech comp bands you cannot match. You will rarely win data talent on pay alone. You win, and keep, them on trajectory: the credible promise that they will be materially more capable and more senior in two years than they would be anywhere else.

There is one non-negotiable that CDOs routinely underestimate: the manager is the delivery mechanism for all of this. A world-class ladder and a rich training budget mean nothing if a team lead can't run a useful growth conversation or refuses to sponsor a stretch assignment. Most data managers were promoted for technical excellence and have never been taught to develop people. Your highest-leverage upskilling investment may not be in your engineers at all, it's in teaching your managers how to grow them. Make "developed people who got promoted" an explicit criterion in your managers' own evaluations, and you align the whole system.

The uncomfortable corollary: if you build great career paths, some people will still leave, and that's acceptable. A person who leaves as a promoted, well-developed alumnus becomes a source of referrals, a future boomerang hire, and a reputation multiplier in a small talent market. The goal was never zero attrition. It was to never again be the free academy that trains people *because* it gave them nowhere to grow.

Key Takeaways

• Build a genuine dual-track ladder where IC and management levels are true peers in comp and status. Differentiate IC levels by *scope of impact*, "whose work changes because this person exists?", not by headcount managed, and defend the levels with a calibration committee to prevent title inflation.
• Replace anecdotal skill knowledge with a capability ledger derived from your strategy. Score gaps by strategic priority and bus-factor risk, then make explicit build/buy/borrow decisions rather than defaulting to hiring or to a training platform.
• Engineer upskilling around application under real stakes, stretch assignments, internal cohorts, and guilds, not course completions. Audit your L&D spend against 70-20-10; most budgets over-fund the 10% and starve the on-the-job 70%.
• Track internal promotion and mobility rates as the report card for your career-path system. If senior roles are filled almost entirely from outside, your paths are broken no matter what the framework document claims.
• Invest first in teaching your managers to develop people, and make finance the argument in replacement-cost terms. The manager is the delivery mechanism for every career-path mechanism you build; without capable managers, the rest is theater.