You've read the job description and most of it is familiar. The gap is the part you can't size from the outside: how much of it is new skill, and how much is work you already do under a different name.
Here is the accounting, in the order the stages depend on each other.
What you already have
If you write transformation code, you have the Model stage in draft. Every metric you have defined in dbt, a BI semantic model, or a stored procedure was a modeling decision. What's missing is the discipline around it: one definition per concept, a named owner, and a binding to specific physical assets rather than a name that happens to match.
If you work in git with review and CI, you have the operating instincts for Version. Applying them to definitions is a change of object, and the object is smaller and slower moving than code.
If you have run a production system, you already think in blast radius. Verify is that instinct pointed at definitions instead of services.
Most people entering this role are two capabilities short, not five. Naming which two is the exercise.
Learn these first, in this order
1. Read the estate you already have
Before any tool, trace one metric from a report back to its source by hand. Every hop, five notes: is there harvested metadata, does it go to column level, was the lineage parsed or observed, how current is it, who owns the definition.
Budget an hour, expect three. This is the single highest-return afternoon available to you, and it teaches the five dimensions faster than reading about them.
2. Read code you did not write
Column-level lineage comes from parsing transformation logic. In a real estate that logic lives in SQL you inherited, a stored procedure from 2019, an Informatica PowerCenter mapping, an SSIS package, sometimes a COBOL copy book.
You do not need to write in those technologies. You need to read one well enough to answer what a number is, which filters applied, and which join path it traveled. Pick the one carrying your most-reported metric and get comfortable.
3. One BI semantic model, deeply
Power BI, Tableau, Looker, or MicroStrategy. It matters less which than that you know how a metric is expressed, where the definition physically lives, and what happens to it in a migration.
This is the skill that makes the Compile stage legible. Without it, compilation is a word rather than something you can reason about.
4. Governance vocabulary, enough to hold a room
What an auditor means by evidence. What lineage means in a regulated reporting context. Why a change record with a timestamp fails the question that gets asked.
Skip the certifications. You need the vocabulary, not the framework fluency, and the fastest way in is to sit in one audit response and take notes.
5. Explaining it without technology
The scarce half of the role. You will spend real time in front of finance, risk, and audit, and a sentence containing a tool name loses that room.
Practice on a colleague outside data. Explain why two reports show different revenue and what you would do about it, using no architecture. Most strong engineers cannot do this on the first attempt, and it improves quickly with deliberate practice.
What to skip
A second transformation framework. Diminishing returns once you know one well. Breadth across source technologies beats depth in a second framework.
Catalog product certifications. They test tool operation, and the tool changes every few years while the judgment does not.
Deep data quality tooling. Adjacent discipline, different job. Metadata quality describes the estate; data quality describes the values inside it. Conflating them costs a quarter.
Prompt engineering. Useful to understand, out of scope to own. Your side of that seam is the governed definition.
A ninety-day plan for one person
Month one: trace three metrics by hand and score them. You now have a number, a gap list, and a working knowledge of your own estate that no course provides.
Month two: pick one dark source and read its transformation logic until you can answer which column produces the number. Depth on one beats a survey of six.
Month three: put one definition under version control with a change history, and run one change through a lower environment and back out again. Small scope, whole loop.
At the end you have done all five stages once. That is the qualification, and it is more persuasive in an interview than any certificate.
Where this leads
The leveling in the job description runs three deep, and the tell between the first and second is the denominator: an engineer says coverage improved, a senior says it went from 61% to 84% and can name what is still dark.
You get there by doing the trace often enough that the number is always current. Start with one metric this week.
Written by the team at MetaKarta and released under CC BY 4.0: free to use, adapt, and republish with attribution.
