Sure, there are many sides to ML. One is the data science bit, curating data, picking a good model. Adjacent to this is research into new models or training methods.
The other side is deploying it efficiently, and that becomes a more routine software engineering problem. Fundamentally you have some code that you want to run as fast as possible on the cheapest hardware you can feasibly use. Large companies like Google have the luxury of splitting this out into several distinct roles - from pure researchers (people publishing papers), to people who train models for business purposes (eg the Google Lens, computational photography, Translate), to people who optimise the ML library code underneath, to people who build out the end user application with the ML model as a black box service.
Most of those people don't need to know much ML, but the exposure can help you transition into a more ML focused role.
The other side is deploying it efficiently, and that becomes a more routine software engineering problem. Fundamentally you have some code that you want to run as fast as possible on the cheapest hardware you can feasibly use. Large companies like Google have the luxury of splitting this out into several distinct roles - from pure researchers (people publishing papers), to people who train models for business purposes (eg the Google Lens, computational photography, Translate), to people who optimise the ML library code underneath, to people who build out the end user application with the ML model as a black box service.
Most of those people don't need to know much ML, but the exposure can help you transition into a more ML focused role.