Why I move between fields on purpose

In short: each new field breaks a different assumption I didn't know I was making, and that's the fastest way I've found to get better at the job. The tools carry over. The instincts don't, and rebuilding them is the point.

People sometimes read my CV and ask what my specialty is. Biomedical engineering, brain-computer interfaces, hospital machine learning, consumer devices, voice. It looks like I couldn't decide. I did decide. I move on purpose, and I want to explain why, because I think more engineers should do it and fewer should apologise for it.

The path so far

1. 2016 to 2020, biomedical engineeringA bachelor's in Tabriz. Medical image enhancement, signal processing, and a stint inside a hospital building a COVID-19 scan classifier.
2. 2021 to 2022, brain-computer interfacesA master's at INRS in Montreal on motor imagery BCI, trained with multisensory virtual reality.
3. Alongside the master's, a research consortiumMachine learning engineer in a research consortium across several institutions. Federated learning, so the data never had to leave each site.
4. Early 2023, a companion for patientsA voice companion for people with dementia, with better speech recognition and a calmer voice.
5. 2023 to 2024, a large hardware companyHuman-computer interaction research on consumer hardware. Prototypes and demos.
6. 2024 to 2025, back to the hospital networkLeading machine learning for precision medicine in a mental health department.
7. 2025, a medical AI companyClinical audio models. Pipelines, models in production, cloud deployment.

Health is the thread. Most of my work has been there, where being wrong has a cost and nobody cares how clever the architecture is. But inside that thread I keep changing the kind of signal, the kind of user and the kind of constraint.

What each move broke

Every field has rules everyone inside it takes for granted. You only notice them when you arrive from somewhere that had different ones.

The consortium: data doesn't travel

I came in thinking the hard part of machine learning was the model. In a consortium spread across several institutions, the hard part was that the data could not be put in one place. Every site had its own rules, its own formats, its own reasons to say no. Federated learning wasn't a research curiosity there. It was the only way the project could exist. I learned to design around the paperwork before the math.

The hardware company: the demo is the product

Then I went to consumer devices, and almost everything flipped. Nobody asked about p-values. People asked whether it felt instant, whether it worked on the device in someone's hand, and whether the demo would survive a room full of people. I worked on cutting latency on device prototypes, by about a fifth on one project, and learned that a slightly worse model that answers right away beats a better one that makes you wait. That lesson would have been invisible to me in a hospital, where nobody was timing anything.

The patient companion: the user doesn't speak like the test set

Building a voice companion for people with dementia broke a different assumption. Speech recognition that works fine on my voice did not work fine on theirs. Pauses are longer, sentences restart, the room is noisy. The engineering was mostly about listening better and answering in a voice that felt calm. Interaction went up by more than half, and that gain came from improving the speech pieces, not from anything clever in the chat model.

Voice as a medical signal

Now the recording is the data itself. A recording is a measurement, and the microphone, the room and the phone codec all leak into it. My biosignal training from the BCI years matters more here than anything I learned about language models.

The tools carry over. The instincts have to be rebuilt each time.

What carries over, and what doesn't

Python, PyTorch, scikit-learn, Docker, a cloud account, a way of structuring a pipeline. All of that moves with me untouched. I could set up the same project skeleton in any of these places on day one.

What doesn't move is judgement. Which number to trust. Which shortcut is safe here and fatal there. In the hospital, a leaky train and test split is a scandal. On a hardware prototype, a hard-coded threshold that makes the demo work is fine for a week. Each field taught me a different list of things to be paranoid about, and the lists add up. I now carry the hospital's paranoia about data and the hardware team's paranoia about latency into every project, including the ones that only ask for one of them.

The cost is real

I won't pretend it's free. Every move puts me back near the bottom of a learning curve. For the first months I ask questions that people in the field find obvious. I'm slower than the person who has been there ten years, and I have to be fine with that.

It also makes the CV harder to read. Recruiters like a straight line. I've had to get better at telling the story in one sentence: I build AI that people actually use, mostly in health, and I go where the hard version of the problem is.

What I get back is worth it. When a project goes wrong, I usually have seen the failure before, just wearing different clothes. A drifting sensor in a wearable and a new microphone in a clinic are the same bug.

If you're thinking about a move

• Keep one thread. Mine is health. A move that changes the signal, the user and the domain all at once is a restart, not a step.
• Write down what surprised you in your first month. Those surprises are the assumptions you just found. They're the most valuable thing you'll learn there, and you forget them fast.
• Bring one habit from the old place and test it on the new one. Most won't fit. The one that does is your edge.
• Ask the oldest person on the team what they wish newcomers knew. Then listen, and don't argue for a month.