I Modelled My Career as a Star Schema. Here's What It Revealed.

I spend my days designing Star Schemas for other organisations' data. Fact tables at the centre, dimensions on the outside, clean foreign keys, no many-to-many relationships without a bridge table.

Then someone asked me to describe my career trajectory and I gave them a rambling 8-minute answer that touched on Nepal, university, three different job titles, and something about Kafka.

I am a data modeller who cannot model his own data. That seemed like a problem worth fixing.

The model

Fact table: fact_experience. Each row is one measurable outcome from one role. Columns: role_key, organisation_key, skill_key, date_key, outcome (text), impact_metric (numeric where possible), impact_unit.

Dimension: dim_role. Title, organisation, industry, employment type, start date, end date.

Dimension: dim_skill. Skill name, category (governance/modelling/BA/BI/compliance), proficiency level.

Dimension: dim_organisation. Name, sector, size, location.

What the model revealed

When I queried my own fact table — "show me outcome rows grouped by skill category" — a pattern I hadn't articulated clearly before became obvious.

Every role I've had has produced outcomes in one of two modes: build a trusted source of truth (governance, modelling, catalogues) or make someone's decision faster (dashboards, reports, analyses). The roles where I was most effective were the ones where I did both in the same project.

The roles where I felt directionless were the ones where I was only doing one.

That's a join condition I didn't know I had.

The uncomfortable finding

My fact table has a lot of rows in "BI & Reporting" and a lot in "Data Governance." It has almost nothing in "Data Engineering." I've been describing myself as a "data professional" without noticing that half the data professional job ads I was applying to wanted someone who builds pipelines — and that's not my grain.

The model helped me be specific about what I'm good at instead of broad about everything. That's what a good model does: it removes ambiguity by forcing you to define your grain.

My grain is: outcomes in data governance and BI delivery, within organisations where stakeholder trust in data is the bottleneck. That's a lot more useful than "data professional."