Three years ago, I was sure I wanted to be a machine learning engineer. I liked the elegance of it — define a loss function, minimise it, watch accuracy go up. Clean problems with clean metrics.
Then I started working, and the clean problems disappeared.
The first crack
At Tsinghua, I built speech recognition models. I got accuracy from 77% to 92%. Fifteen percentage points. Months of work. Loss function tuning, data augmentation, architecture experiments.
At the end, I wrote a report. My supervisor read it, said "good work," and the model went into a shared folder. I don't know if anyone ever used it downstream. The accuracy improvement was real. The impact was unclear.
This isn't a complaint about academia — research has its own logic and its own value. But it made me notice something: I was more interested in what happened after the model was done than in building the model itself.
The second crack
At Lenovo, I built dashboards. Strategy dashboards, supply chain dashboards, digital transformation dashboards. The technical work was straightforward — Tableau, Power BI, some SQL. Nothing that would impress anyone at a machine learning conference.
But these dashboards were in front of senior management every week. I sat in meetings where someone pointed at my chart and said "based on this, we should..." and then a decision happened. A real decision, with budget attached to it.
I was doing less sophisticated technical work and having more impact. That was uncomfortable to admit.
The pattern
At Airbus, the pattern became impossible to ignore. The sophisticated pipeline work was necessary but invisible. The "simple" visualisation work — the charts, the slide decks, the one-page summaries — was what actually moved things.
I started to see my career options as a spectrum:
- Left side: Build better models. Optimise inference. Publish papers. The technical depth is impressive and the impact is indirect.
- Right side: Sit closer to decisions. Translate data into action. The technical work is simpler but the impact is direct.
I found myself consistently drifting right.
Why finance
Once I realised I wanted to be closer to the decision end of the data pipeline, the question became: which decisions? Which industry puts the most weight on data-driven reasoning, moves the most capital based on quantitative analysis, and has the highest cost of getting it wrong?
Finance is the obvious answer.
Not because I want to be a quant. The full-stack quant researcher path — Bayesian statistics, stochastic calculus, HFT infrastructure — is a fine career, but it's the left side of the spectrum in a different domain. I'm more interested in the translation layer:
- How does a risk team turn model output into position limits?
- How does an analyst turn financial data into a narrative that moves a stock price?
- How does a bank's back office turn regulatory data into compliance decisions?
These are data-to-decision problems with real stakes, real feedback loops, and real consequences for getting the translation wrong.
The TUM decision
This is why I'm doing a Management & Data Science master's at TUM instead of a pure ML or CS program. I don't need to learn more about neural architectures. I need to learn about how organisations make decisions with data — the management side, the strategy side, the financial modelling side.
It's an unusual path for someone who started in AI. Most of my classmates from the Tsinghua lab are going deeper into ML research. I'm going sideways — deliberately. Because I think the most interesting unsolved problems in data aren't about better models. They're about better bridges between models and the humans who have to act on them.
What I'm doing about it
Talk is cheap. Here's what I'm actually doing to make this transition:
- Reading annual reports. Not to become a financial analyst, but to understand how companies narrate their own data. (I wrote about this.)
- Building fintech tools. Small things — FX dashboards, DCF calculators, market data scrapers. The kind of tools that force me to engage with financial data structures and conventions. Available on my site as I finish them.
- Targeting internships at the intersection. Data roles in banks, asset managers, or fintech companies. Not "data scientist" roles where I'd be building recommendation engines — roles where the output is a decision, not a prediction.
I'm not sure this will work. The finance industry isn't exactly looking for people whose main qualification is "built a Databricks pipeline at an aircraft factory." But I think the combination of real data engineering experience, an understanding of how data moves through organisations, and a deliberate focus on the decision layer is a more interesting story than "I know PyTorch."
At worst, I'll end up as a data engineer at a bank who reads too many annual reports. There are worse fates.