On paper my career reads as a straight line into data leadership. It was not one. It was a finance degree, a family office, a masters where I learned to code, four months embedded with software developers, a year and a half of econometrics research, and then a job where all of it turned out to be the prerequisite.

I want to write down how that actually went, because the version where somebody decides to "move into data" and takes a bootcamp is not what happened.

Where it started

A bachelor's in finance, then investment management at a family office. That is where I learned to think about capital, risk and the difference between a number that is correct and a number that is useful. No code. Spreadsheets and judgment.

Then I moved to Canada for an MSc in Finance, and that is where the coding started. Not as a career plan. Econometrics coursework needed Python, so I learned Python.

Learning it fast enough to teach it

I picked it up quickly, and quickly enough that I ended up teaching it. I was a TA during the econometrics phase of the program, which meant standing in front of people and explaining loops, dataframes and regression output to students who had exactly the background I had arrived with.

Teaching is where the learning actually consolidated. You cannot bluff a room. If your mental model has a hole in it, somebody asks the question that finds the hole, and you go and fill it before the next session.

Four months with people who build software

Then I interned at PSP Investments as a quant developer, and for the first time I was working alongside actual developers rather than analysts.

That is where I picked up the things nobody teaches you in a finance program: how applications are structured, what data engineering means as a discipline rather than a buzzword, how solutions architecture decisions get made and what they cost when they are made badly. Four months, and it reframed how I thought about everything I had built until then.

A year and a half in research

After that, a research role at HEC Montréal doing advanced econometrics alongside NLP and machine learning work.

Research teaches a specific kind of rigour. You are not shipping, you are defending. Every assumption gets examined, every result has to survive somebody asking why it should be believed. That habit is uncomfortable and it is the reason I am slow to trust a dashboard, including my own.

Building the thing from zero

Then Gestion Zagora, where there was no data function at all.

What exists now: pipelines, a warehouse, KPI frameworks, monthly valuation pipelines, reporting the business actually runs on, CRM and ERP integrations through their APIs, and a set of internal applications. We automated workflows that used to be manual, and rebuilt several of them so that compliance is enforced as the work happens rather than audited afterwards. A lot of that was about collection: making the data clean where it enters the business, instead of cleaning it downstream forever.

The stack ended up broad because the problems were. Python, BigQuery and CloudSQL on one side, React, TypeScript and Firebase on the other, because the answer to a reporting problem is sometimes a pipeline and sometimes an application.

I started alone. There are five of us now.

What the detour actually bought

None of it was wasted.

The family office is why I can sit with a finance stakeholder and know what they are really asking. The masters is why I can write the code. Teaching is why I can explain a technical decision to somebody without the background. PSP is why I know how an application should be put together. Research is why I check whether a number is defensible before I publish it.

None of it was planned. It turns out a data function inside a property business needs all five at once.

I did not get there by being passably good at each. I got there by refusing to leave any of them half learned, and by giving up a great deal of sleep for several years running.

The teaching never actually stopped

The team is finance, software engineering, math and computer science graduates. I have real overlap with each of them and identical training with none.

The part I did not expect is how much of the job is still teaching. I sit with the computer science graduates and work through how to build a pipeline, how to think in system design, how to reason about solution architecture. They can out-code me on a given afternoon. What I can give them is the shape of the problem, and why one structure survives contact with next year while another does not.

It is the econometrics TA role again, in a different room, with higher stakes.

The other half of the job is the reverse. Following the engineer, the statistician and the finance analyst closely enough to notice when their answers disagree, and knowing which one the business should act on.

What I would tell someone on a similar path

Stop apologising for the detour. The years that look like a diversion on a CV are usually the ones that make you useful later.

The syntax, the tools, the specific stack: you will pick those up. Judgment about which problem is worth solving takes longer, and it tends to come from having stood somewhere else first.